คำสั่ง Backup Percona MongoDB ง่ายมากเลยครับ ขั้นแรกให้เข้า mongo shell ก่อน แล้วใช้คำสั่งตามด้านล่าง

use admin
db.runCommand({backupStart:"/my/backup/data/path"})

โดยแก้ไขส่วนของ /my/backup/data/path เป็น path ที่เราต้องการเซฟ backup ไว้เท่านี้ก็เรียบร้อย ง่ายสุดๆ สั่ง Backup ระหว่างใช้งานโดยไม่กระทบกับผู้ใช้งานปัจจุบันได้เลยครับ แต่ถ้าหากต้องการรันผ่าน linux shell ตรงๆ โดยไม่ต้องเข้า Mongo shell ก่อนก็สั่งดังนี้ได้เลยครับ

mongo --eval "db = db.getSiblingDB('admin'); db.runCommand({backupStart:\"/my/backup/data/path\"});"
tar -cv -C /my/backup/data path | pbzip2 -cv > my_backup.tar.gz2

เพียงเท่านี้ก็จะสามารถตั้ง cron สั่ง backup รายวันได้ทันที แก้ไขตำแหน่งไฟล์ที่ backup ได้ตามสะดวก และสั่ง pbzip2 ให้รวมเป็นไฟล์เดียวเล็กๆ เรียบร้อย

สำหรับวิธี Restore ไม่มีอะไรซับซ้อน ไฟล์ที่เรา backup มานั่นแหละคือ data ของฐานข้อมูล mongodb เต็มๆ สิ่งที่ต้องทำมีเพียง stop mongodb ที่รันอยู่แล้วลบไฟล์ database mongodb ทั้งหมดออกไป (ตัวทั่วไปมักจะอยู่ที่ /var/lib/mongodb) แล้วเอาไฟล์ที่เรา backup ไว้ไปใส่แทน แล้วแก้ owner ของไฟล์เป็น mongod ผ่านคำสั่ง chown แล้วสั่ง start mongodb ขึ้นมาอีกรอบเป็นอันเรียบร้อย ง่ายมากๆ

• use db1 – ใช้งาน database db1 หรือสร้าง database ใหม่
• show dbs – แสดงรายชื่อ database ทั้งหมด
• db.getCollectionNames() – แสดง collection (ตาราง) ทั้งหมด
• db.createCollection(“users”) – สร้าง collection ชื่อ users
• db.users.drop() – ลบ collection users
• db.createCollection(“new”, {capped:true, size:1073741824}); – สร้าง capped collection ขนาด 1073741824 bytes
• db.logMoney.find({time:{$gte: new Date(2013,2,5)}}); – query date มากกว่าเท่ากับวันที่ๆ กำหนด
• db.logMoney.ensureIndex({‘time’:1},{background:true}) – new index field time โดย background ไว้สั่งให้ทำโดยไม่ lock collection
• db.logMoney.getIndexes()  - ดู Index ทั้งหมดขณะนั้น
• db.logMoney.find({time:{$gt:new Date()}}) – query ระบุเวลา สามารถใช้ร่วมกับ mongodump ได้
• db.logMoney.aggregate({$match:{time:{$gt:new Date(2013,1,1)},chng:{$lt:0}}},{$group:{_id:{usrId:1, }, count:{$sum:1}, sumAll:{$sum:”$chng”}}}) – ตัวอย่างการใช้งาน query ลักษณะเดียวกับ GROUP BY ใน MySQL
  (SELECT *, COUNT(*) as count,  SUM(chng) as sumAll FROM logMoney WHERE time > “2013-01-01″ AND chng < 0  GROUP BY usrId)

วิธีทำ Replication

ก่อนอื่น MongoDB แนะนำว่าควรมีเครื่องในวงอย่างน้อย 3 เครื่องครับ (แต่เราอาจจะใช้ 2 เครื่อง แล้วใช้อีกเครื่องเป็น Arbiter หรือตัวหลอกแทนได้) ขั้นตอนมีดังนี้

1. Edit /etc/mongodb.conf ด้วยโปรแกรมที่ถนัด
2. กำหนด replSet = <ชื่อกลุ่มที่ต้องการ> ในที่นี้ผมตั้งว่า rs0
3. restart mongodb
4. ทำข้อ 1-3 ใหม่กับเครื่องที่จะเป็น Slave ทุกเครื่อง
5. เข้าเครื่องที่จะให้เป็น Master (สมมติว่า ip ภายในของเครื่อง master คือ 10.0.0.1) แล้วพิมพ์ mongo 10.0.0.1 (สำคัญมาก ห้ามลืมพิมพ์ ip หรือพิมพ์ผิดเด็ดขาด ไม่อย่างนั้นจะใช้ไม่ได้)
6. ถ้าหน้าจอปรากฏดังนี้แสดงว่าทำได้ถูกต้อง
   
mongo 10.0.0.1
MongoDB shell version: 2.2.2
connecting to: 10.0.0.1/test
rs0:PRIMARY>
7. สั่ง rs.initiate()
8. สั่ง rs.add(“10.0.0.2″) (สมมติเครื่อง slave ip 10.0.0.2) และเครื่อง slave เครื่องอื่นๆ
9. เสร็จ!

สรุปคำสั่ง replication ที่ใช้บ่อย

• rs.initiate() – เริ่ม replica set
• rs.status() – status replica set
• rs.add(“ip”) – เพิ่ม secondary node
• rs.addArb(“ip”) – เพิ่ม secondary node แบบตัวหลอกเพื่อโหวตตอน fail-over เท่านั้น ไม่มีข้อมูลจริง
• rs.stepDown() – ถอนตัวจากการเป็น master
• db.printReplicationInfo() – เช็คว่า oplog มีอายุกี่วัน

วิธี Backup MongoDB

เทียบเท่า mysqldump นั่นเอง ตัวอย่างนั้นใช้ dump เฉพาะตารางที่กำหนด และ query ในช่วงเวลาที่กำหนด ดังนี้

mongodump –host –port –db <ชื่อ database> –collection <ชื่อ collection> -q ‘{“time”:{“$gte”:{“$date”:1360627200000}}}’

วิธี Restore MongoDB

mongorestore

ขอให้สนุกกับ MongoDB

ก่อนอื่นต้องอธิบายก่อนว่า Percona Server คือ MySQL เวอร์ชั่นปรับปรุงนั่นเอง โดยทางทีมพัฒนาได้นำเอา InnoDB Engine ไปพัฒนาและปรับปรุงประสิทธิภาพหลายๆ อย่าง และใส่ฟีเจอร์เด็ดๆ เพิ่มเข้ามามากมายจนสุดท้ายออกมาเป็น Percona Server ซึ่งเจ้านี่มีความเข้ากันได้กับ InnoDB Engine ตัวเดิมของ MySQL 100% ครับ ใช้แทน MySQL ได้ทุกประการ รวมไปถึง Tools ต่างๆ ที่เคยใช้กับ MySQL ได้ก็จะใช้กับ Percona Server ได้เช่นกัน (แม้จะเป็น MyISAM ก็สามารถใช้งานได้ปกติไม่มีปัญหาใดๆ ครับ แค่ performance จะยังคงเหมือน MySQL ไม่ได้ถูกปรับปรุงขึ้นตามด้วย)

ส่วน Tools ที่เราจะใช้สำหรับ Backup จริงๆ ชื่อ XtraBackup ครับ ซึ่งเป็นทีมพัฒนาทีมเดียวกับ Percona Server (และ Percona Data Recovery Tool for InnoDB จากบทความที่แล้วด้วยเช่นกัน) เจ้าตัว Xtrabackup นี้จริงๆ ใช้งานกับ mysql ธรรมดาที่ไม่ใช่ Percona Server ก็ได้แต่จะมีความสามารถบางอย่างที่ทำไม่ได้หากไม่ได้ใช้ Percona Server ครับ เช่น การ Backup/Restore ฐานข้อมูลเฉพาะตารางบางตารางที่เราต้องการ (เพื่อประหยัดเวลา/cpu ของ server) เป็นต้น ซึ่ง Tools ตัวนี้จะช่วย Backup แบบไม่ต้องปิด server (ไม่ต้อง Lock Table ระหว่างทำการ backup) ได้เฉพาะตารางที่ใช้งานฐานข้อมูลชนิด InnoDB เท่านั้น (จริงๆ MyISAM ก็ใช้ Tools ตัวนี้ช่วย backup ได้ครับ แค่จะยังติด lock อยู่เหมือนเดิม) นอกจากนี้หากเราใช้งานฐานข้อมูลบน VPS หรือ Cloud ที่ให้พื้นที่ใช้งานน้อยๆ ยังสามารถ Backup เป็นแบบ Incremental หรือส่งไฟล์ Backup เป็น stream ไปเข้า server ตัวอื่นที่มีพื้นที่เยอะกว่าได้อีกด้วย! (Amazing ไหมละ!) ซึ่งการ Backup โดยที่ Server ยังคงให้บริการได้ปกติแบบนี้เราจะเรียกว่า Hot Backup ครับ ส่วนการ Backup ที่จำเป็นต้องปิด Server ระหว่าง Backup เราจะเรียกว่า Cold Backup เอาละหลังจากติดตั้งเสร็จแล้ว (และต้องมี account root ของ OS ด้วยนะครับ) ลองมาดูวิธีใช้งานกันดีกว่าครับ (ทุกขั้นต้อนต้องทำขณะเป็น root ครับ)

ขั้นตอนการ Backup

1. innobackupex –user=DBUSER –password=DBUSERPASS –no-lock –defaults-file=/path/to/my.cnf /path/to/BACKUP-DIR/
   แก้ dbuser/dbuserpass ให้เรียบร้อย และ path นี้เป็น dir สำหรับเก็บ backup ที่ได้ออกมา รอจนปรากฎคำว่า “innobackupex: completed OK!” ที่บรรทัดสุดท้าย แสดงว่าสำเร็จ (ถ้าโปรแกรมฟ้องว่าหา datadir ไม่พบให้ไปแก้ my.cnf เติม datadir เข้าไปครับ ทั่วไป default จะอยู่ที่ /var/lib/mysql แต่ถ้ามี datadir แล้วยังฟ้อง แสดงว่าหาไฟล์ my.cnf ไม่เจอ ตรวจสอบไฟล์ my.cnf ให้ดีว่า path ที่ระบุถูกต้องหรือไม่)
2. innobackupex –apply-log /path/to/BACKUP-DIR/xxx
   โดยที่ xxx คือ dir ที่โปรแกรมสร้างขึ้นซึ่งมักจะเป็นชื่อวันที่ + เวลาที่ backup รอจนปรากฎคำว่า “innobackupex: completed OK!” ที่บรรทัดสุดท้าย แสดงว่าสำเร็จ (ถ้าโปรแกรมฟ้องว่า ibbackup เลือก binary ไม่ถูก ให้เติม option –ibbackup ตามด้วยชื่อในหน้านี้โดยเลือกให้ถูกต้องตามที่เขียนไว้ครับ)

ขั้นตอนการ Restore

1. เมื่อต้องการ Restore Backup ที่เก็บไว้ ให้สั่ง “service mysql stop” ลบข้อมูลใน datadir ทิ้งให้ว่างเปล่า (หรือจะแค่เปลี่ยนชื่อ ป้องกันความผิดพลาดก็ได้ครับ) แล้วสั่ง
   innobackupex –copy-back –default-file=/path/to/my.cnf  /path/to/BACKUP-DIR/xxx
   รอจนปรากฎคำว่า “innobackupex: completed OK!” ที่บรรทัดสุดท้าย แสดงว่าสำเร็จ ถ้าขึ้นว่า “Original data directory ‘./’ is not empty! at /opt/local/bin/innobackupex” แสดงว่าหาไฟล์ my.cnf ไม่เจอ
2. chown -R mysql:mysql /var/lib/mysql
   เพื่อเปลี่ยน permission จาก root (user ที่เราใช้อยู่) เป็น mysql แล้วสั่ง “service mysql start” เป็นอันเสร็จ ง่ายไหมล่ะครับ หุหุ

ขั้นตอนการทำ Replication

อันนี้เป็นของแถมครับ โดยปกติแล้วเราจะทำ Replication กันเราจะต้อง Backup ข้อมูลจากเครื่อง Master และสั่ง Lock Table ไม่ให้มีการเปลี่ยนแปลงข้อมูลได้จนกว่าจะ Setup Replication เสร็จ แต่นี่ไม่ต้องครับ ตัว Master ยังคงให้บริการได้ปกติและเราสามารถเพิ่มจำนวน Slave กี่ตัวก็ได้ในขณะนั้นตามต้องการ โดยให้ทำตามขั้นตอน Backup จนจบขั้นตอนที่ 2 แล้วต่อด้วยขั้นตอนด้านล่างต่อครับ

1. หลังได้ไฟล์ Backup ชื่อ xxx (เป็นเวลา backup) แล้วสั่ง
   tar -zcvf db.tar.gz xxx
   ให้เรียบร้อย โดย xxx คือ dir ที่เก็บ backup ของเราเอาไว้ (ที่ชื่อเป็นวัน-เวลา backup นั่นแหละครับ) เพื่อเตรียมโยนไปยัง server อีกตัวที่ต้องการจะทำ Slave ครับ
2. โยนไฟล์ db.tar.gz ที่บีบอัดไว้ไปยังเครื่อง Slave ด้วย rsync, scp ตามแต่สะดวกครับ หรือใครไม่ได้ลงไว้ ก็ใช้ tools มาตรฐานเลยครับ ssh ด้วยคำสั่ง
   ssh USER@SLAVE_IP cat < “/path/to/db.sql.gz” “>” “/path/to/save”
   ก็แก้ไข USER, SLAVE_IP, path ตัวแรก (เครื่องที่มี backup ไว้), path ที่ต้องการจะส่งไปให้ (เครื่อง slave) ให้ถูกต้องแล้วส่งไฟล์ได้เลยครับ
3. โยนไฟล์ my.cnf จากเครื่อง Master ไปยังเครื่อง Slave ด้วยคำสั่งเดียวกันกับข้อ 2 ครับ
4. mysql -uroot -p เข้าในเครื่อง Master ไปสร้าง user สำหรับเครื่อง Slave ดังนี้ครับ
   GRANT REPLICATION SLAVE ON *.*  TO ‘repl’@'$slaveip’ IDENTIFIED BY ‘$slavepass’;
   repl คือ user mysql ส่วน $slaveip, $slavepass ก็ตามชื่อเลยครับ
5. login เข้าเครื่อง Slave แล้ว untar ด้วย
   tar -zxvf db.tar.gz
   ที่ตำแหน่งที่เราเก็บไฟล์ไว้ตามคำสั่งในข้อ 2
6. service mysql stop ที่เครื่อง slave
7. copy dir xxx ที่ได้จากการแกะ tar ไปที่ datadir ของเครื่อง Slave ทับไปเลย (หรือจะ mv เปลี่ยนชื่อ datadir เดิมเก็บไว้ก่อนก็ได้เช่นเดิมครับ)
8. แก้ไฟล์ my.cnf ที่เครื่อง slave โดยบรรทัด server-id แก้เป็น
   server-id=2
9. ถ้าใช้ ubuntu หรือ debian ให้แก้ไฟล์ /etc/mysql/debian.cnf ซึ่งจะมี user debian-sys-maint อยู่ในนั้นด้วยครับ โดยแก้ password ให้เป็น password เดียวกับเครื่อง Master ไม่อย่างนั้น startup script “service mysql stop/start/restart” จะพังครับ
10. chown -R mysql:mysql datadir
    โดย datadir แก้เป็นตำแหน่งที่เก็บข้อมูล database ตามต้องการครับ (default คือ /var/lib/mysql)
11. เปิดไฟล์ xtrabackup_binlog_info ที่อยู่ใน datadir ที่เราพึ่ง copy มาจะพบเลขลักษณะประมาณนี้
    TheMaster-bin.000001 481
    ของคุณจะเป็นเลขอื่นที่ไม่ซ้ำกันกับผมแน่ๆ ครับ เป็นเลขตำแหน่ง log สุดท้ายของ database ที่เราต้องการจะ replicate นั่นเอง
12. mysql -uroot -p
    เข้า mysql เครื่อง Slave ครับแล้วพิมพ์

    CHANGE MASTER TO
    MASTER_HOST='$masterip',
    MASTER_USER='repl',
    MASTER_PASSWORD='$slavepass',
    MASTER_LOG_FILE='TheMaster-bin.000001',
    MASTER_LOG_POS=481;
    START SLAVE;
    แก้ข้อมูลให้ถูกต้องโดยตามข้อมูลที่สร้างที่ผ่านมา

13. ลองสั่ง SHOW SLAVE STATUS \G โดยยังไม่ออกจาก MySQL Console หากพบบรรทัดเหล่านี้แสดงว่าสำเร็จแล้ว

             ...
             Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
             ...

เป็นไงบ้าง เจ๋งใช่ไหมละครับ ลองเก็บไปใช้กันดูนะครับ

1. Physical Backup - เป็นการ backup ข้อมูลโดยการ copy โครงสร้างข้อมูลมาทั้ง directory และ file ทั้งหมดนั่นเอง การ backup แบบนี้มีข้อดีคือสามารถ recovery คืนกลับได้รวดเร็ว และการ backup ก็ใช้เวลาน้อยกว่า Logical เนื่องจากเป็นเพียงการ copy file ธรรมดาๆ แต่มีข้อเสียคือการย้ายฐานข้อมูลจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่งซึ่งเป็นคนละ OS หรือเป็น mysql คนละเวอร์ชั่น จะไม่สามารถกระทำได้ โดยปกติมักใช้ mysqlhotcopy(MyISAM), ibbackup (InnoDB) เป็นเครื่องมือในการ backup
2. Logical Backup – เป็นการ backup ข้อมูลโดย export ข้อมูลทั้งหมดมาเป็นคำสั่ง SQL โดยมีการ CREATE TABLE และข้อมูลทั้งหมดใหม่ มีข้อดีคือสามารถโยกย้ายไปยังเครื่องอีกเครื่องอีกเครื่องหนึ่งได้ง่าย import ได้เลยทันที ไม่ว่าจะเป็น OS คนละตัวหรือไม่ก็ตาม โดยปกติแล้วมักใช้ mysqldump เป็นเครื่องมือในการ backup

ต่อไปเป็นรูปแบบการ backup แบ่งเป็น 4 แบบ

1. Full Backup - backup database ขณะนั้นทั้งหมดทุกตาราง ข้อมูลทุกชิ้น การ Recover จะทำได้เร็วกว่า incremental เนื่องจากมีไฟล์เพียงไฟล์เดียว
2. Incremental Backup – backup database เฉพาะการส่วนที่เปลี่ยนแปลง โดยการ backup แบบนี้ต้องมีไฟล์ full backup เป็นฐานก่อน จึงจะสามารถทำได้ การ Recover จะกินเวลามากกว่า Full Backup เนื่องจากต้อง recover ไฟล์ full backup ที่เป็นฐานก่อน แล้วจึงรัน recover ส่วนที่เปลี่ยนแปลง แต่หากมีการ backup บ่อยๆ และข้อมูลไม่มีการเปลี่ยนแปลงมากนัก วิธีนี้จะช่วยประหยัดพื้นที่ได้มากทีเดียว การ backup วิธีนี้จำเป็นต้องเปิดใช้งาน Binary Log
3. Snapshot Backup - เป็นการ backup แบบ Logical ซึ่งเป็นในลักษณะคล้ายไฟล์ image ที่ใช้ backup ไฟล์ทั่วไปในเครื่อง เป็นการรวมไฟล์ทั้งหมด ณ เวลาหนึ่งๆ โดยจำเป็นต้องใช้ความสามารถของ OS หรือ third party software เช่น Veritas, LVM, or ZFS และ snapshot บางตัวอย่าง LVM สามารถสั่ง mount ข้อมูลออกมาเพื่อใช้เปรียบเทียบกับตัว master ได้ทันอีกด้วย
4. Replication – เป็นการสร้าง database ขึ้นมาอีกตัวหนึ่งเรียกว่า slave ส่วน database ต้นฉบับจะเรียกว่า master โดย slave อาจอยู่ที่ server เดียวกับ master หรือคนละ server ก็ได้ มักใช้ Binary Log เข้าช่วยในการส่งข้อมูลการเปลี่ยนแปลงจาก master ไป slave เนื่องจากช่วยให้ค่อยๆ ส่งข้อมูลไปทีละน้อยๆ ได้ง่าย และหากต้องการ backup เป็นแบบ full หรือ incremental ต่อไปอาจ backup จากตัว slave ได้เลยโดยไม่จำเป็นต้องยุ่งกับตัว master ทำให้สะดวกต่อการใช้งานมาก อีกทั้งการสั่ง recover อาจ สั่งที่ตัว slave แล้วนำข้อมูลไปเปรียบเทียบกับ master ได้ทันที ค่อนข้างมีประสิทธิภาพดีมาก วิธีนี้อาจใช้คู่กับ Snapshot บางตัวได้อีกด้วย

สำหรับบทความนี้ จะสอนการ backup โดยใช้ mysqldump ไปจนถึง Incremental Backup ครับ จะไม่ครอบคลุมถึง Snapshot และ Replication

ขั้นตอนการ Backup แบบ Incremental (แก้ root และ password ในส่วนของ -u root -p password เป็น username, password ของคุณ)

1. Enable Binary Log ด้วยการแก้ไขไฟล์ /opt/local/etc/my.cnf (หากไม่พบ กรุณาตรวจสอบ OS ที่ใช้ และลองหาดูว่าได้ติดตั้งตัว config mysql หรือก็คือ my.cnf ไว้ที่ใด) โดยเพิ่มบรรทัด log-bin = /var/log/mysql/binary.log เข้าไปภายใต้ [mysqld] เป็นการระบุตำแหน่งที่จะให้จัดเก็บ Binary Log
2. สั่ง restart mysql แล้วตัว Mysql จะสร้างไฟล์ bin.000001 และไฟล์ใหม่ bin.000002 ให้ ณ ตำแหน่งที่ระบุไว้ในข้อ 1
3. Backup แบบ Full Back up โดยใช้คำสั่ง
   mysqldump –flush-logs –master-data planet -u root -p password my_db | gzip -9 > fulldb.sql.gz
   จำเป็นต้องมี –master-data เพื่อเพิ่ม header พิเศษว่าเริ่มนับจาก Binary Log ไฟล์ใด และ –flush-logs เพื่อสั่งให้ขึ้นไฟล์ Binary Log ไฟล์ใหม่
4. หากต้องการเก็บเป็นไฟล์ในรูป Logical (SQL Statement) ให้สั่ง
   cut_str=`echo “SHOW MASTER STATUS;” | mysql -u root -p password | grep bin`
   bin_file=${cut_str:0:10}
   mysqlbinlog $bin_file > logical.sql

   จะได้ไฟล์ logical.sql มา โดยคำสั่งส่วนนี้เป็นการสั่งให้แปลง Binary เป็น Logical เฉพาะไฟล์ Binary Log ไฟล์ล่าสุดเท่านั้น หากต้องการระบุไฟล์ Binary Log หลายๆ ไฟล์รวมกันอาจสั่งโดยตรงด้วยคำสั่ง

   mysqlbinlog  bin.000001 bin.000002 > logical.sql

5. สำหรับการ Recover สามารถสั่ง recover ด้วยจุดของเวลาได้เลยด้วยคำสั่ง

   mysqlbinlog --stop-datetime="2005-04-20 9:59:59" \
   /var/log/mysql/bin.123456 | mysql -u root -p password

หมายเหตุ : สามารถสั่ง
echo “FLUSH LOGS” | mysql -uroot -p
ที่ shell เพื่อแทนการสั่ง –flush-logs ของ mysqldump ได้ เพื่อขึ้นไฟล์ Binary Log ไฟล์ใหม่โดยไม่ทำ Full Backup

เอาล่ะ ขอให้โชคดีกับการ Backup MySQL กันทุกคนครับ

ข้อมูลเพิ่มเติม : http://dev.mysql.com/doc/refman/5.1/en/backup-and-recovery.html