Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
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
Prochain SlideShare
Chargement dans…5
×

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

30 824 vues

Publié le

2015/02/27 OSC 2015 Tokyo/Spring

Publié dans : Technologie
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

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

×