Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Más de yoku0825
Más de yoku0825 (20)
Último
Último (9)
MySQLのバックアップ運用について色々
- 1. MySQLのバックアップ運⽤について ⾊々 2015/02/27 ⽇本MySQLユーザ会 yoku0825 OSC 2014 Tokyo/Spring
- 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
- 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
- 18. ここまでのまとめ ファイルコピーの特徴 バックアップもリストアも速くて楽ちん- 容量はやや⼤きめ。制御⽤のファイルやインデックスの 中⾝など全て保管。 - 取得時のインパクトがでかい- 17/58
- 20. ここまでのまとめ XtraBackupの特徴 ホットな物理バックアップ、しかもマルチスレッド- 慣れるまで難しいものの、慣れれば夢のソリューション- ただしMyISAMが混じるとロックが必要- 最新版はMySQL 5.1 InnoDB Plugin以降のサポート- MySQL Enterprise Backup(商⽤版MySQLのユーティリ ティー)がもっと便利なことできる - 19/58
- 22. こんな感じ 21/58
- 23. マスター 22/58
- 24. スレーブ 23/58
- 25. バッチ 24/58
- 26. バックアップ 25/58
- 27. アーカイブサーバー 26/58
- 33. 均⼀化への道 ブラックホールを使って稼ぎ出したDisk容量、今 なら1万円で買えるよ、みたいな ⽌められる時が技術的負債の繰り上げ返済チャン ス。 泥臭く頑張るしかないと思ってやってる 32/58
- 34. 必要なスペック(1) マスター, スレーブ サービスに必要なだけ- VMなサーバーもある- 基本はSSD, メモリーは⼤めに メモリーが⼩さいとInnoDB圧縮かけた時に死ぬ - マスターの性能がスレーブの性能より⾼いとたまに死ぬ マスターはマルチスレッドで更新かかるけどスレーブはシングルスレッド(SQLスレッ ドのみ) - クラッシュしたらデータは捨てる と割り切れば、パラメ ータを危険側に倒すこともできる - 33/58
- 40. リストアのケースを整理 データのロールバック(ロールフォワードリカバリ ー) ロールバック時点から1世代前のフルバックアップからの リストア + ロールバック時点までのbinlog適⽤ - ⾯倒 + 時間かかる上に⼤概急ぐ- 原因はだいたい「やらかした」 もしくはおもむろに「過去のスナップショット⾒たい」とか、事前に予測のつかない 理由 - 最低限の準備だけしてあとはその時考える 39/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
- 45. クラッシュするんだから なるべくスレーブで重複実⾏されても痛みが少ない SQLを選ぶ トランザクションを使ってSELECTして値を得てからその 値でUPDATE - MySQL 5.6以降ならrelay̲log̲recovery= 1 && relay̲log̲info̲repository= TABLEでクラッシュセーフ スレーブに(クラッシュしてもレプリケーションが正しく 再開される) - 44/58
- 47. クラッシュしたあとは マスターのsync̲binlog != 1 だと、スレーブの master̲log̲positionが先に進んでしまうとか どっちを⽣かす︖- log̲slave̲updatesしてればスレーブを⽣かせるんだけ どさ。。 GTID有効ならlog̲slave̲updates必須なので、⼀意に選択できる。 - ⾃動昇格に任せるという⼿もある(Durabilityよりも ConsistencyとAvailabilityを取る) - 46/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
- 52. バックアップのサイズも⼤事 300GBのdatadirを物理バックアップするとだいた い45GB(bzip2圧縮) それを100DBぶん取ると1世代で4.5TB- 何世代保管する︖- 圧縮, 転送, 解凍のための時間を織り込まないといけない パラレルでアーカイブしてから転送する︖ パラレル転送してからアーカイブする︖ - 51/58
- 57. 直観的なヒント ⽌めて物理バックアップ => mysqldump => XtraBackup => 混合、と推移していくものかなと 思う。 次のステップに進むべき時にはたぶん⾃然とわかる ⽌めて物理バックアップで⾜りている時期にはXtraBackupのドキュメント読んでもき っと⾯⽩くもなんともない mysqldumpでリストアが無理だろうってなった時にはXtraBackupの機能はきっとわ かる 順当にやってきてれば、XtraBackupだけでつらくなってきた時に他の選択肢をきっと 思いつく - 56/58