Transcript

• 1. MySQLのバックアップ運⽤について ⾊々 2015/02/27 ⽇本MySQLユーザ会 yoku0825 OSC 2014 Tokyo/Spring
• 2. ＼こんにちは／ yoku0825@とある企業のDBA オラクれない- ポスグれない- マイエスキューエる- 家に帰ると 妻の夫- せがれの⽗- 娘の⽗- Twitter: @yoku0825 Blog: ⽇々の覚書 1/58
• 3. バックアップ を運⽤するお はなし 2/58
• 4. 前提条件 バックアップが取得できなければいけない バックアップ取得はサービスに影響を与えてはいけない- バックアップ取得にかかる時間は現実的でなければいけ ない - バックアップファイルは保管されなくてはいけない- バックアップはリストアできなければいけない リストアにかかる時間は現実的でなければいけない- 3/58
• 5. バックアップ 取得の選択肢 4/58
• 6. バックアップ ステップ的なもの フルバックアップ- 差分バックアップ- 増分バックアップ- 範囲的なもの 全体バックアップ- 部分バックアップ ⼀貫性の問題で、全体バックアップ以外は使いにくい - 5/58
• 7. リストアステップ (最新の)フルバックアップの戻し (最新の)差分バックアップの戻し (↑でリストアした時点からリストア時点までの)増 分バックアップの戻し 6/58
• 8. ステップ的なもの 7/58
• 9. たとえば1/4 のデータを復 元するなら 8/58
• 10. 1/1のフル + 1/2の増分 + 1/3の増分 + 1/4の増分 9/58
• 11. あるいは1/1のフル + 1/3の差分 + 1/4の増 分 10/58
• 12. ステップ的なもの サイズ 使いどころ コマンド例 フルバックアップ でかい 必ず必要 tar, rsync, mysqldump, XtraBackup 差分バックアップ ⼩さい フルバックアップの 間隔が短ければ要ら ない mysqldump(スキー マに制約) XtraBackup 増分バックアップ 更新量に依存 ほぼ間違いなく必要 cp, rsync, mysqlbinlog 11/58
• 13. というわけで差分 バックアップはあ まり使わない 12/58
• 14. フルバックアップの選択肢 コマンド エンジン アプリ影響 ⽅式 サイズ tar, rsync MyISAM × 停⽌またはロッ ク 物理 ⼤きめ tar, rsync InnoDB × mysqld停⽌ 物理 ⼤きめ LVMスナップ ショット MyISAM InnoDB △ 性能劣化がひど い 物理 ⼤きめ mysqldump MyISAM × ロック 論理 ⼩さめ mysqldump InnoDB ○ 論理 ⼩さめ XtraBackup MyISAM × ロック 物理 ⼤きめ XtraBackup InnoDB ○ 物理+論理 ⼤きめ 13/58
• 15. フルリストアのしやすさ コマンド エンジン リストアのしやすさ 時間 tar, rsync MyISAM InnoDB 簡単 短い mysqldump MyISAM InnoDB 簡単 超⻑い XtraBackup MyISAM InnoDB 慣れるまで⾯倒 やや短い 14/58
• 16. 増分バックアップ バックアップ scp, rsynなどでコピー- MySQL 5.6からは–raw –stop-neverでリアルタイムバ ックアップもできる - リストア mysqlbinlogでデコード- 15/58
• 17. ここまでのまとめ フルバックアップと増分バックアップが両⽅必要 フルバックアップの頻度が⼗分なら差分バックアップは 要らない - 16/58
• 18. ここまでのまとめ ファイルコピーの特徴 バックアップもリストアも速くて楽ちん- 容量はやや⼤きめ。制御⽤のファイルやインデックスの 中⾝など全て保管。 - 取得時のインパクトがでかい- 17/58
• 19. ここまでのまとめ mysqldumpの特徴 バックアップはやや遅めくらいだがリストアが超重い バックアップもリストアもシングルスレッド。 派⽣: MyDumper - 容量は⼩さめ。制御⽤の構造とかインデックスの中⾝は 要らないから。 テキストなら圧縮と相性が良い。 - フルスキャンによる性能劣化はある- 18/58
• 20. ここまでのまとめ XtraBackupの特徴 ホットな物理バックアップ、しかもマルチスレッド- 慣れるまで難しいものの、慣れれば夢のソリューション- ただしMyISAMが混じるとロックが必要- 最新版はMySQL 5.1 InnoDB Plugin以降のサポート- MySQL Enterprise Backup(商⽤版MySQLのユーティリ ティー)がもっと便利なことできる - 19/58
• 21. 安全に運⽤するために バックアップ専⽤スレーブを作る リストアのケースを整理する クラッシュはするものとして織り込む モニタリングは⼤事 20/58
• 22. こんな感じ 21/58
• 23. マスター 22/58
• 24. スレーブ 23/58
• 25. バッチ 24/58
• 26. バックアップ 25/58
• 27. アーカイブサーバー 26/58
• 28. マスター - バック アップサーバー間 は非同期レプリケ ーション 27/58
• 29. バックアップサ ーバーで innobackupex 28/58
• 30. アーカイブサ ーバーに転送 29/58
• 31. シンプルにできること それっぽく⾔うと「疎結合に作る」ということ 分離することで、コスト(スペック)⾯も運⽤⾯も柔 軟性が上がる マスターに求められる要件とバックアップに求められる 要件は違う - 分離されたバックアップサーバーは⽌められる- データをロールバックする必要のないリストアな ら、⽌めてrsyncで話が済む 30/58
• 32. シンプルにできてないこと マスターとスレーブのスキーマを変えている場合 は、それ⽤の⼿順も必要(ままある) マスターにブラックホールがあると⼼が⿊くなっちゃう- バッチ⽤サーバーには専⽤ユーザーがいたり、インデッ クスが追加されてたり - サービス系にはHandlerSocketがいるけどバックアップ ⽤にはいないとか - 環境の差異の吸収も⾃動化したい（できてない）- マスターとスレーブのバージョンが違う…だと…︓ (︔ﾞﾟʼωﾟʼ)︓ 31/58
• 33. 均⼀化への道 ブラックホールを使って稼ぎ出したDisk容量、今 なら1万円で買えるよ、みたいな ⽌められる時が技術的負債の繰り上げ返済チャン ス。 泥臭く頑張るしかないと思ってやってる 32/58
• 34. 必要なスペック(1) マスター, スレーブ サービスに必要なだけ- VMなサーバーもある- 基本はSSD, メモリーは⼤めに メモリーが⼩さいとInnoDB圧縮かけた時に死ぬ - マスターの性能がスレーブの性能より⾼いとたまに死ぬ マスターはマルチスレッドで更新かかるけどスレーブはシングルスレッド(SQLスレッ ドのみ) - クラッシュしたらデータは捨てる と割り切れば、パラメ ータを危険側に倒すこともできる - 33/58
• 35. 必要なスペック(2) バッチサーバー ないサービスもある- 基本的にはユーザートラフィックなし- いざという時にサービスに⼊れられる程度のスペックの マシンに複数インスタンス相乗り - サービスレイヤーがシングルマスターな時はあった⽅が いざという時の備えに - 34/58
• 36. 必要なスペック(3) バックアップサーバー インスタンス相乗り- 速度よりも容量マター RAID5 SATAとかでもOK 全く遅延してはいけないわけではないので、バックアップ取る時に追いついていれば 基本OK - パラメーターはとにかく安全側に倒す。- 35/58
• 37. 必要なスペック(4) アーカイブサーバー 容量だけが正義と⾔いたいけど、ファイル転送や圧縮伸 ⻑にはそれなりにメモリーもCPUも使う - バックアップサーバーからXtraBackup(または.tar.gz)で フルバックアップを2世代保存 それ以降の世代はテープやDC外に転送して削除 - バイナリーログを貯めるのもここ(rsyncかmysqlbinlog)- 36/58
• 38. リストアのケースを整理 スレーブの新規作成 最新のデータに戻せればOK- 基本、そこまで急がない- クラッシュからの復旧(MyISAM, 羃等でないSQL, サーバーが上がらない, Diskの⼆重障害…) 最新のデータに戻せればOK- 基本急ぐ- ほとんどの場合この2パターン 37/58
• 39. 最新のデータに戻せればOKな場合 バックアップサーバー⽌める 基本、その⽌めた時点のデータが⼿に⼊る- rsync 所要時間= ファイルの転送にかかる時間- 新しいサーバーとバックアップサーバー上げる ⼗数分あればだいたい追いつく- バックアップサーバーがあればそもそもリストアです らない 38/58
• 40. リストアのケースを整理 データのロールバック(ロールフォワードリカバリ ー) ロールバック時点から1世代前のフルバックアップからの リストア + ロールバック時点までのbinlog適⽤ - ⾯倒 + 時間かかる上に⼤概急ぐ- 原因はだいたい「やらかした」 もしくはおもむろに「過去のスナップショット⾒たい」とか、事前に予測のつかない 理由 - 最低限の準備だけしてあとはその時考える 39/58
• 41. データのロールバック地点 少なくとも急ぐやつは、かなりのケースが過去数時 間以内へのロールバック 体験上、99%以上は過去24時間まで考慮すればフォロー できる デイリーのフルバックアップ2世代(フルバックアップ取得直前へのロールバックを最 悪ケースとして) アワリーのbinlogバックアップをフルバックアップの世代と合わせて - それより過去へのロールバックは急がないケースが ほとんどだし頻度も滅多にないので、DC外や mysqldumpで容量節約 DC外に保持しているのも⼊れると90⽇前までリストアで きるポリシー - 40/58
• 42. クラッシュはするものとして考える ハードウェアクラッシュは避けようがない 体感ではハングアップの⽅が多いけど- Mroongaさんとか⼼が⿊くなっちゃうこともある それに⽐べればInnoDBはホント落ちない Assertも数年に1回レベル - 他にも不測の事態はいくらでもやってくる 2か所同時障害とか考えたくないけど 2か所同時に落ちてもいいように…はつらい- けれど、2か所同時に落ちた時にどうすればいいかは考え ておく - 41/58
• 43. クラッシュしたら データを全て消してバックアップサーバーからコピ ーした⽅がいい場合 クラッシュアンセーフなストレージエンジン MyISAM, Mroonga, その他 InnoDBでも innodb̲flush̲log̲at̲trx̲commit != 1なマスター skip-innodb-doublewrite 羃等でないSQLを使っているスレーブ sync̲master̲info, sync̲relay̲log̲infoを両⽅1にできないものとして考えてる UPDATE .. SET age= age + 1 は2回実⾏すると結果がズレる UPDATE .. SET age= 32 ならまだマシ binlog̲format= ROWならエラってくれるはず - 42/58
• 44. クラッシュするんだから InnoDBを安全に使っておく トランザクションのサポート= 確実なクラッシュリカバ リーの保証 - マスターはinnodb̲flush̲log̲at̲trx̲commit= 1- skip-innodb-doublewriteは毎回作り直す覚悟が必要- 43/58
• 45. クラッシュするんだから なるべくスレーブで重複実⾏されても痛みが少ない SQLを選ぶ トランザクションを使ってSELECTして値を得てからその 値でUPDATE - MySQL 5.6以降ならrelay̲log̲recovery= 1 && relay̲log̲info̲repository= TABLEでクラッシュセーフ スレーブに(クラッシュしてもレプリケーションが正しく 再開される) - 44/58
• 46. クラッシュしたあとは スレーブ, マスターの整合性チェック必須 pt-table-checksumというツールが便利 オンラインのままマスターとスレーブのデータの不整合をチェックできる データが読めなければエラるので、⼀応破損チェックにもなる pt-table-checksum - 45/58
• 47. クラッシュしたあとは マスターのsync̲binlog != 1 だと、スレーブの master̲log̲positionが先に進んでしまうとか どっちを⽣かす︖- log̲slave̲updatesしてればスレーブを⽣かせるんだけ どさ。。 GTID有効ならlog̲slave̲updates必須なので、⼀意に選択できる。 - ⾃動昇格に任せるという⼿もある(Durabilityよりも ConsistencyとAvailabilityを取る) - 46/58
• 48. モニタリングは⼤事 バックアップはちゃんと取れてるのか リストアできないバックアップとか笑えない innobackupexの出⼒をチェックして通報 - バックアップ取る時点でレプリケーションが遅れすぎて いないか 多少は許容するといっても、バックアップ⽇時とデータの時間がズレてるとリストア しにくい サービス系でやってるのと同じ仕組みでSeconds̲behind̲masterを監視(閾値がユ ルイ) - 47/58
• 49. モニタリングは⼤事 レプリケーションに不整合は起きていないのか リストアできたとしても、間違ったデータじゃ意味がな い binlog̲format= STATEMENT && sysdate-is-nowしてない状態でsysdateとか (実話) 非決定性クエリーに関してはエラーログに吐いてくれる。 binlog̲format= ROWで Error: 1032(HA̲ERR̲KEY̲NOT̲FOUND) で⽌まって くれた⽅がマシ(感じ⽅には個⼈差があります) マスターからバックアップするのが⼀番確実ではある バックアップサーバーに直接UPDATE⽂を投げられたことがあってだな。。 read-only付け忘れるとか Super̲priv良くない pt-table-checksumが簡単だけど、テーブルサイズが⼤きくなってくるとなかなかつ らいものもある。。 - 48/58
• 50. ここまでのまとめ バックアップ専⽤スレーブを作る リストアのケースを整理する クラッシュはするものとして織り込む もとのサーバーにリストアできるとは限らない モニタリングは⼤事 49/58
• 51. その他ちょこ ちょこしたこ と 50/58
• 52. バックアップのサイズも⼤事 300GBのdatadirを物理バックアップするとだいた い45GB(bzip2圧縮) それを100DBぶん取ると1世代で4.5TB- 何世代保管する︖- 圧縮, 転送, 解凍のための時間を織り込まないといけない パラレルでアーカイブしてから転送する︖ パラレル転送してからアーカイブする︖ - 51/58
• 53. バックアップのサイズも⼤事 mysqldumpの⽅がサイズが⼩さいのは 制御ファイル(ib̲logfile*とかundoセグメントとか)はバ ックアップに含まれない - インデックスはバックアップに含まれない(DDLとデータ から再作成できるから) - BLOBをふんだんに盛り込んでなければ圧縮が効きやすい- FacebookはmysqldumpをHDFSに保管してるって聞い た(単に容量がでかすぎるかららしい) - 52/58
• 54. どこに保管するのか データセンターに1PB詰め込んでも怒られないファ イルサーバーがあるといいな ウチにはない かつてはテープに詰め込んでたけど S3をはじめとするクラウドストレージ︖ 転送前に暗号化案件。 それ、mysqlbackupとinnobackupexならできるよ - 53/58
• 55. もとのサーバーにリストアできるとは限らない 主にハードウェアクラッシュで上がってこないパタ ーン クラウドなら楽ちん ベアメタルクラウドも結構ラク - ベアメタルでも、ウチの環境は結構融通が利いてる(世間 ⼀般的なことはわからないけれども) - 最後の⼿段、バッチレイヤーのサービスレイヤーへの接 続 何があってもバックアップサーバーだけはサービスレイヤーには晒さない - 54/58
• 56. 最近の事情 直近のバックアップはデータセンター, 48時間以上 過去のバックアップは外部 テープドライブに詰められるテープの総容量を超えたの で外部転送に DC内完結では問題にならなかった帯域の問題 - バックアップは⾃動化されているが、リストアは⼿作業 DC内で完結する作業だけでも継続的リストアテストしたい(それが9割以上だし) - DCに残ってないフルバックアップからPITRするためのバ イナリーログがDCに残ってたりする - 55/58
• 57. 直観的なヒント ⽌めて物理バックアップ => mysqldump => XtraBackup => 混合、と推移していくものかなと 思う。 次のステップに進むべき時にはたぶん⾃然とわかる ⽌めて物理バックアップで⾜りている時期にはXtraBackupのドキュメント読んでもき っと⾯⽩くもなんともない mysqldumpでリストアが無理だろうってなった時にはXtraBackupの機能はきっとわ かる 順当にやってきてれば、XtraBackupだけでつらくなってきた時に他の選択肢をきっと 思いつく - 56/58
• 58. 夢のようなソリ ューションがあっ たら教えてくださ い 57/58
• 59. Any Question? 58/58