O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
MySQLのバックアップ運⽤について
⾊々
2015/02/27
⽇本MySQLユーザ会 yoku0825
OSC 2014 Tokyo/Spring
\こんにちは/
yoku0825@とある企業のDBA
オラクれない-
ポスグれない-
マイエスキューエる-
家に帰ると
妻の夫-
せがれの⽗-
娘の⽗-
Twitter: @yoku0825
Blog: ⽇々の覚書
1/58
バックアップ
を運⽤するお
はなし
2/58
前提条件
バックアップが取得できなければいけない
バックアップ取得はサービスに影響を与えてはいけない-
バックアップ取得にかかる時間は現実的でなければいけ
ない
-
バックアップファイルは保管されなくてはいけない-
バックアップはリストアできな...
バックアップ
取得の選択肢
4/58
バックアップ
ステップ的なもの
フルバックアップ-
差分バックアップ-
増分バックアップ-
範囲的なもの
全体バックアップ-
部分バックアップ
⼀貫性の問題で、全体バックアップ以外は使いにくい
-
5/58
リストアステップ
(最新の)フルバックアップの戻し
(最新の)差分バックアップの戻し
(↑でリストアした時点からリストア時点までの)増
分バックアップの戻し
6/58
ステップ的なもの
7/58
たとえば1/4
のデータを復
元するなら
8/58
1/1のフル + 1/2の増分 + 1/3の増分 +
1/4の増分
9/58
あるいは1/1のフル + 1/3の差分 + 1/4の増
分
10/58
ステップ的なもの
サイズ 使いどころ コマンド例
フルバックアップ でかい 必ず必要 tar, rsync,
mysqldump,
XtraBackup
差分バックアップ ⼩さい フルバックアップの
間隔が短ければ要ら
ない
mysqldump...
というわけで差分
バックアップはあ
まり使わない
12/58
フルバックアップの選択肢
コマンド エンジン アプリ影響 ⽅式 サイズ
tar, rsync MyISAM ×
停⽌またはロッ
ク
物理 ⼤きめ
tar, rsync InnoDB ×
mysqld停⽌
物理 ⼤きめ
LVMスナップ
ショット
...
フルリストアのしやすさ
コマンド エンジン リストアのしやすさ 時間
tar, rsync MyISAM
InnoDB
簡単 短い
mysqldump MyISAM
InnoDB
簡単 超⻑い
XtraBackup MyISAM
InnoDB
...
増分バックアップ
バックアップ
scp, rsynなどでコピー-
MySQL 5.6からは–raw –stop-neverでリアルタイムバ
ックアップもできる
-
リストア
mysqlbinlogでデコード-
15/58
ここまでのまとめ
フルバックアップと増分バックアップが両⽅必要
フルバックアップの頻度が⼗分なら差分バックアップは
要らない
-
16/58
ここまでのまとめ
ファイルコピーの特徴
バックアップもリストアも速くて楽ちん-
容量はやや⼤きめ。制御⽤のファイルやインデックスの
中⾝など全て保管。
-
取得時のインパクトがでかい-
17/58
ここまでのまとめ
mysqldumpの特徴
バックアップはやや遅めくらいだがリストアが超重い
バックアップもリストアもシングルスレッド。
派⽣: MyDumper
-
容量は⼩さめ。制御⽤の構造とかインデックスの中⾝は
要らないから。
テキスト...
ここまでのまとめ
XtraBackupの特徴
ホットな物理バックアップ、しかもマルチスレッド-
慣れるまで難しいものの、慣れれば夢のソリューション-
ただしMyISAMが混じるとロックが必要-
最新版はMySQL 5.1 InnoDB Plug...
安全に運⽤するために
バックアップ専⽤スレーブを作る
リストアのケースを整理する
クラッシュはするものとして織り込む
モニタリングは⼤事
20/58
こんな感じ
21/58
マスター
22/58
スレーブ
23/58
バッチ
24/58
バックアップ
25/58
アーカイブサーバー
26/58
マスター - バック
アップサーバー間
は非同期レプリケ
ーション
27/58
バックアップサ
ーバーで
innobackupex
28/58
アーカイブサ
ーバーに転送
29/58
シンプルにできること
それっぽく⾔うと「疎結合に作る」ということ
分離することで、コスト(スペック)⾯も運⽤⾯も柔
軟性が上がる
マスターに求められる要件とバックアップに求められる
要件は違う
-
分離されたバックアップサーバーは⽌められる-
...
シンプルにできてないこと
マスターとスレーブのスキーマを変えている場合
は、それ⽤の⼿順も必要(ままある)
マスターにブラックホールがあると⼼が⿊くなっちゃう-
バッチ⽤サーバーには専⽤ユーザーがいたり、インデッ
クスが追加されてたり
-
サー...
均⼀化への道
ブラックホールを使って稼ぎ出したDisk容量、今
なら1万円で買えるよ、みたいな
⽌められる時が技術的負債の繰り上げ返済チャン
ス。
泥臭く頑張るしかないと思ってやってる
32/58
必要なスペック(1)
マスター, スレーブ
サービスに必要なだけ-
VMなサーバーもある-
基本はSSD, メモリーは⼤めに
メモリーが⼩さいとInnoDB圧縮かけた時に死ぬ
-
マスターの性能がスレーブの性能より⾼いとたまに死ぬ
マスターはマ...
必要なスペック(2)
バッチサーバー
ないサービスもある-
基本的にはユーザートラフィックなし-
いざという時にサービスに⼊れられる程度のスペックの
マシンに複数インスタンス相乗り
-
サービスレイヤーがシングルマスターな時はあった⽅が
いざと...
必要なスペック(3)
バックアップサーバー
インスタンス相乗り-
速度よりも容量マター
RAID5 SATAとかでもOK
全く遅延してはいけないわけではないので、バックアップ取る時に追いついていれば
基本OK
-
パラメーターはとにかく安全側に...
必要なスペック(4)
アーカイブサーバー
容量だけが正義と⾔いたいけど、ファイル転送や圧縮伸
⻑にはそれなりにメモリーもCPUも使う
-
バックアップサーバーからXtraBackup(または.tar.gz)で
フルバックアップを2世代保存
それ...
リストアのケースを整理
スレーブの新規作成
最新のデータに戻せればOK-
基本、そこまで急がない-
クラッシュからの復旧(MyISAM, 羃等でないSQL,
サーバーが上がらない, Diskの⼆重障害…)
最新のデータに戻せればOK-
基本急ぐ...
最新のデータに戻せればOKな場合
バックアップサーバー⽌める
基本、その⽌めた時点のデータが⼿に⼊る-
rsync
所要時間= ファイルの転送にかかる時間-
新しいサーバーとバックアップサーバー上げる
⼗数分あればだいたい追いつく-
バックアッ...
リストアのケースを整理
データのロールバック(ロールフォワードリカバリ
ー)
ロールバック時点から1世代前のフルバックアップからの
リストア + ロールバック時点までのbinlog適⽤
-
⾯倒 + 時間かかる上に⼤概急ぐ-
原因はだいたい「や...
データのロールバック地点
少なくとも急ぐやつは、かなりのケースが過去数時
間以内へのロールバック
体験上、99%以上は過去24時間まで考慮すればフォロー
できる
デイリーのフルバックアップ2世代(フルバックアップ取得直前へのロールバックを最
悪...
クラッシュはするものとして考える
ハードウェアクラッシュは避けようがない
体感ではハングアップの⽅が多いけど-
Mroongaさんとか⼼が⿊くなっちゃうこともある
それに⽐べればInnoDBはホント落ちない
Assertも数年に1回レベル
-
...
クラッシュしたら
データを全て消してバックアップサーバーからコピ
ーした⽅がいい場合
クラッシュアンセーフなストレージエンジン
MyISAM, Mroonga, その他
InnoDBでも
innodb̲flush̲log̲at̲trx̲comm...
クラッシュするんだから
InnoDBを安全に使っておく
トランザクションのサポート= 確実なクラッシュリカバ
リーの保証
-
マスターはinnodb̲flush̲log̲at̲trx̲commit= 1-
skip-innodb-doublew...
クラッシュするんだから
なるべくスレーブで重複実⾏されても痛みが少ない
SQLを選ぶ
トランザクションを使ってSELECTして値を得てからその
値でUPDATE
-
MySQL 5.6以降ならrelay̲log̲recovery= 1 &&
r...
クラッシュしたあとは
スレーブ, マスターの整合性チェック必須
pt-table-checksumというツールが便利
オンラインのままマスターとスレーブのデータの不整合をチェックできる
データが読めなければエラるので、⼀応破損チェックにもなる
...
クラッシュしたあとは
マスターのsync̲binlog != 1 だと、スレーブの
master̲log̲positionが先に進んでしまうとか
どっちを⽣かす︖-
log̲slave̲updatesしてればスレーブを⽣かせるんだけ
どさ。。
...
モニタリングは⼤事
バックアップはちゃんと取れてるのか
リストアできないバックアップとか笑えない
innobackupexの出⼒をチェックして通報
-
バックアップ取る時点でレプリケーションが遅れすぎて
いないか
多少は許容するといっても、バッ...
モニタリングは⼤事
レプリケーションに不整合は起きていないのか
リストアできたとしても、間違ったデータじゃ意味がな
い
binlog̲format= STATEMENT && sysdate-is-nowしてない状態でsysdateとか
(実話...
ここまでのまとめ
バックアップ専⽤スレーブを作る
リストアのケースを整理する
クラッシュはするものとして織り込む
もとのサーバーにリストアできるとは限らない
モニタリングは⼤事
49/58
その他ちょこ
ちょこしたこ
と
50/58
バックアップのサイズも⼤事
300GBのdatadirを物理バックアップするとだいた
い45GB(bzip2圧縮)
それを100DBぶん取ると1世代で4.5TB-
何世代保管する︖-
圧縮, 転送, 解凍のための時間を織り込まないといけない
パ...
バックアップのサイズも⼤事
mysqldumpの⽅がサイズが⼩さいのは
制御ファイル(ib̲logfile*とかundoセグメントとか)はバ
ックアップに含まれない
-
インデックスはバックアップに含まれない(DDLとデータ
から再作成できるか...
どこに保管するのか
データセンターに1PB詰め込んでも怒られないファ
イルサーバーがあるといいな
ウチにはない
かつてはテープに詰め込んでたけど
S3をはじめとするクラウドストレージ︖
転送前に暗号化案件。
それ、mysqlbackupとinn...
もとのサーバーにリストアできるとは限らない
主にハードウェアクラッシュで上がってこないパタ
ーン
クラウドなら楽ちん
ベアメタルクラウドも結構ラク
-
ベアメタルでも、ウチの環境は結構融通が利いてる(世間
⼀般的なことはわからないけれども)
-...
最近の事情
直近のバックアップはデータセンター, 48時間以上
過去のバックアップは外部
テープドライブに詰められるテープの総容量を超えたの
で外部転送に
DC内完結では問題にならなかった帯域の問題
-
バックアップは⾃動化されているが、リスト...
直観的なヒント
⽌めて物理バックアップ => mysqldump =>
XtraBackup => 混合、と推移していくものかなと
思う。
次のステップに進むべき時にはたぶん⾃然とわかる
⽌めて物理バックアップで⾜りている時期にはXtraBac...
夢のようなソリ
ューションがあっ
たら教えてくださ
い
57/58
Any
Question?
58/58
Próximos SlideShares
Carregando em…5
×

MySQLのバックアップ運用について色々

30.536 visualizações

Publicada em

2015/02/27 OSC 2015 Tokyo/Spring

Publicada em: Tecnologia
  • Seja o primeiro a comentar

MySQLのバックアップ運用について色々

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

×