Downloaded 21 times
Uploaded byyoku0825
How to backup your mroonga database?
2014/09/03 ConoHa presents - Groonga "How-To" talks
More Related Content
Similar to How to backup your mroonga database?
![[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015c27mysqlrakuten-150617022225-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
How to backup your mroonga database?
- 1. How to backupyour Mroonga database? 2014/09/03 yoku0825 Groonga "How-To" Talks
- 2. I'm yoku0825 ●とある企業のDBA ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● この自己紹介を何日か前にご覧いただいた、と いう方がいてびっくり。
- 3.
- 4.
- 5.
- 6.
- 7. MySQL的3層モデル Parser, Optimizer,Executor Storage Engine File Format
- 8. MySQL的3層モデル Parser, Optimizer,Executor MyISAM InnoDB .MYD .MYI ibdata1 ib_logfile .ibd HEAP Memory Mroonga .mrn
- 9. MySQL的3層モデル Parser, Optimizer,Executor MyISAM InnoDB .MYD .MYI ibdata1 ib_logfile .ibd HEAP Memory Mroonga .mrn Meta Data Lock, Query Cache Lock
- 10. MySQL的3層モデル Parser, Optimizer,Executor MyISAM InnoDB .MYD .MYI ibdata1 ib_logfile .ibd HEAP Memory Mroonga .mrn Table Lock, Next-key Lock
- 11. MySQL的3層モデル Parser, Optimizer,Executor MyISAM InnoDB .MYD .MYI ibdata1 ib_logfile .ibd HEAP Memory Mroonga .mrn ファイルそのものはロック機構を持たない (ファイルシステムによるロックは除く)
- 12.
- 13. MySQL的3層モデル ストレージエンジンレイヤーではロックを持たず .mrnファイル(libgroonga.so)側にロック機構がある Parser, Optimizer, Executor MyISAM InnoDB .MYD .MYI ibdata1 ib_logfile .ibd HEAP Memory Mroonga .mrn
- 14. MySQLはMroongaのロックを ロックとして認識していない lock_wait_timeout変数じゃなくて mroonga_lock_timeout変数が 必要なのはこのため
- 15.
- 16.
- 17.
- 18. 選択肢 ● 整合性だいじ ● MySQL止めて(またはFLUSH TABLES WITH READ LOCKしながら)ファイルバックアップ ● mysqldump (ストレージモードならlock-all-tables, ラッパーモードでInnoDBならsingle-transaction) ● ただしこれらもgroongaサーバーやgroongaコマン ドからの更新にはノーガード。。 ● 気にしなくてOK(または更新が来ないことが保 証されている場合) ● groonga /data/mysql/tweets.mrn dump ● grndump /data/mysql/tweets.mrn
- 19. 後日註 ● ファイルバックアップ以外はmysqld起動した まま、INSERTクエリーとSELECTクエリーを投 げ続けた状態で計っています ● 環境はCentOS 6.5 on ConoHaのいちばん安い やつです ● https://www.conoha.jp/pricing ● 正直コアが足りずにサチってます
- 20. ファイルバックアップ # du-sh mysql/ 2.3G mysql/ # time tar czf mysql.tar.gz mysql/* real 1m51.565s user 1m35.005s sys 0m3.134s # ll -h mysql.tar.gz -rw-r--r-- 1 root root 360M Sep 2 18:04 mysql.tar.gz # time tar xzf mysql.tar.gz real 0m24.025s user 0m14.640s sys 0m3.670s
- 21. ファイルバックアップ(20G) # du-sh mysql/ 23G mysql/ # time tar czf mysql.tar.gz mysql/* real 25m47.765s user 24m9.010s sys 0m29.462s # ll -h mysql.tar.gz -rw-r--r-- 1 root root 5.7G Sep 3 16:33 mysql.tar.gz # time tar xzf mysql.tar.gz real 4m33.880s user 2m41.009s sys 0m32.507s
- 22. ファイルバックアップ ● メリット ● 特にスレーブ止めて取ったバックアップは解凍する だけですぐSTART SLVAEできる ● リストアは最速 ● デメリット ● マスターにリストアする場合はリレーログとか消さ ないといけない ● オフライン(少なくとも更新は止める必要がある) ● 余談 ● ラッパーモードならXtraBackupで取ったのをリス トアしてからALTER TABLE .. ENABLE KEYSでいけ るかと思ったけど無理だった。
- 23. mysqldump # timemysqldump --lock-all-tables tweets | gzip -c > mysqldump.sql.gz real 1m10.968s user 1m1.596s sys 0m0.892s # ll -h mysqldump.sql.gz -rw-r--r-- 1 root root 235M Sep 2 18:28 mysqldump.sql.gz # time zcat mysqldump.sql.gz | mysql tweets real 2m40.087s user 0m11.373s sys 0m0.647s
- 24. mysqldump(20G) # timemysqldump --lock-all-tables tweets | gzip -c > mysqldump.sql.gz real 6m26.385s user 5m51.441s sys 0m4.802s # ll -h mysqldump.sql.gz -rw-r--r-- 1 root root 1.4G Sep 3 15:24 mysqldump.sql.gz # time zcat mysqldump.sql.gz | mysql tweets real 15m6.047s user 1m4.754s sys 0m3.739s
- 25. mysqldump ● メリット ● バックアップもリストアもわかりやすい ● 圧縮すれば結構容量が稼げる ● デメリット ● (ストレージモードの場合)更新は止まる – ラッパーモードはバックアップの視点ではかなり優秀。 ● 折角のMroongaの機能をかなり制限してしまうのであまりやり たくない。。 ● あとはトランザクションの扱いでこんな不整合があるのがイヤ – http://yoku0825.blogspot.jp/2014/04/mroongainnodb.html ● バックアップもリストアも遅め
- 26. groonga dump #time groonga /data/mysql/tweets.mrn dump | gzip -c > groonga.dump.gz real 1m35.061s user 1m12.553s sys 0m3.239s # ll -h groonga.dump.gz -rw-r--r-- 1 root root 244M Sep 2 18:46 groonga.dump.gz # time zcat groonga.dump.gz | groonga /data/mysql/tweets.mrn real 0m45.772s user 0m36.010s sys 0m1.897s
- 27. grndump # timegrndump /data/mysql/tweets.mrn | gzip -c > grndump.dump.gz real 3m41.721s user 3m23.788s sys 0m2.912s # ll -h grndump.dump.gz -rw-r--r-- 1 root root 243M Sep 2 18:55 grndump.dump.gz # time zcat grndump.dump.gz | groonga /data/mysql/tweets.mrn real 0m45.361s user 0m35.381s sys 0m1.789s
- 28. grndump(20G) # timegrndump /data/mysql/tweets.mrn | gzip -c > grndump.dump.gz real 21m7.326s user 19m34.971s sys 0m15.467s # ll -h grndump.dump.gz -rw-r--r-- 1 root root 1.4G Sep 3 15:03 grndump.dump.gz # time zcat grndump.dump.gz | groonga /data/mysql/tweets.mrn real 4m25.299s user 3m25.894s sys 0m9.969s
- 29. groonga dump/grndump ●メリット ● 圧縮すれば結構容量が稼げる ● リストアが想像以上に速い ● デメリット ● 整合性に対してノーガード ● バックアップは(特にgrndumpは)時間がかかる – groonga dumpとgrndumpの使い分けはこちらが詳しい http://qiita.com/orangain/items/6abb3e3b4e0353419fd e – 追記: I/OじゃなくてCPUバウンドしてる状態なので、 ちゃんとした環境でやればもっと速くなるはず – grndumpに--lock-all-tablesオプションつけてみた https://gist.github.com/yoku0825/305f18ff3ec52eee5a 50
- 30.