MySQLのバックアップ運⽤について⾊々

2015/02/27

⽇本MySQLユーザ会 yoku0825OSC 2014 Tokyo/Spring

＼こんにちは／

yoku0825@とある企業のDBAオラクれない-ポスグれない-マイエスキューエる-

家に帰ると妻の夫-せがれの⽗-娘の⽗-

Twitter: @yoku0825Blog: ⽇々の覚書

1/58

バックアップを運⽤するおはなし

2/58

前提条件

バックアップが取得できなければいけないバックアップ取得はサービスに影響を与えてはいけない-バックアップ取得にかかる時間は現実的でなければいけない

-

バックアップファイルは保管されなくてはいけない-

バックアップはリストアできなければいけないリストアにかかる時間は現実的でなければいけない-

3/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(スキーマに制約)XtraBackup

増分バックアップ 更新量に依存 ほぼ間違いなく必要 cp, rsync, mysqlbinlog

11/58

というわけで差分バックアップはあまり使わない

12/58

フルバックアップの選択肢

コマンド エンジン アプリ影響 ⽅式 サイズ

tar, rsync MyISAM ×停⽌またはロック

物理 ⼤きめ

tar, rsync InnoDB ×mysqld停⽌

物理 ⼤きめ

LVMスナップショット

MyISAMInnoDB

△性能劣化がひどい

物理 ⼤きめ

mysqldump MyISAM ×ロック

論理 ⼩さめ

mysqldump InnoDB ○ 論理 ⼩さめ

XtraBackup MyISAM ×ロック

物理 ⼤きめ

XtraBackup InnoDB ○ 物理+論理 ⼤きめ

13/58

フルリストアのしやすさ

コマンド エンジン リストアのしやすさ 時間

tar, rsync MyISAMInnoDB

簡単 短い

mysqldump MyISAMInnoDB

簡単 超⻑い

XtraBackup MyISAMInnoDB

慣れるまで⾯倒 やや短い

14/58

増分バックアップ

バックアップscp, rsynなどでコピー-MySQL 5.6からは–raw –stop-neverでリアルタイムバックアップもできる

-

リストアmysqlbinlogでデコード-

15/58

ここまでのまとめ

フルバックアップと増分バックアップが両⽅必要フルバックアップの頻度が⼗分なら差分バックアップは要らない

-

16/58

ここまでのまとめ

ファイルコピーの特徴バックアップもリストアも速くて楽ちん-容量はやや⼤きめ。制御⽤のファイルやインデックスの中⾝など全て保管。

-

取得時のインパクトがでかい-

17/58

ここまでのまとめ

mysqldumpの特徴バックアップはやや遅めくらいだがリストアが超重いバックアップもリストアもシングルスレッド。派⽣: MyDumper

-

容量は⼩さめ。制御⽤の構造とかインデックスの中⾝は要らないから。テキストなら圧縮と相性が良い。

-

フルスキャンによる性能劣化はある-

18/58

ここまでのまとめ

XtraBackupの特徴ホットな物理バックアップ、しかもマルチスレッド-慣れるまで難しいものの、慣れれば夢のソリューション-ただしMyISAMが混じるとロックが必要-最新版はMySQL 5.1 InnoDB Plugin以降のサポート-MySQL Enterprise Backup(商⽤版MySQLのユーティリティー)がもっと便利なことできる

-

19/58

安全に運⽤するために

バックアップ専⽤スレーブを作るリストアのケースを整理するクラッシュはするものとして織り込むモニタリングは⼤事

20/58

こんな感じ

21/58

マスター

22/58

スレーブ

23/58

バッチ

24/58

バックアップ

25/58

アーカイブサーバー

26/58

マスター - バックアップサーバー間は非同期レプリケ

ーション27/58

バックアップサーバーで

innobackupex28/58

アーカイブサーバーに転送

29/58

シンプルにできること

それっぽく⾔うと「疎結合に作る」ということ分離することで、コスト(スペック)⾯も運⽤⾯も柔軟性が上がるマスターに求められる要件とバックアップに求められる要件は違う

-

分離されたバックアップサーバーは⽌められる-データをロールバックする必要のないリストアなら、⽌めてrsyncで話が済む

30/58

シンプルにできてないこと

マスターとスレーブのスキーマを変えている場合は、それ⽤の⼿順も必要(ままある)マスターにブラックホールがあると⼼が⿊くなっちゃう-バッチ⽤サーバーには専⽤ユーザーがいたり、インデックスが追加されてたり

-

サービス系にはHandlerSocketがいるけどバックアップ⽤にはいないとか

-

環境の差異の吸収も⾃動化したい（できてない）-

マスターとスレーブのバージョンが違う…だと…︓(︔ﾞﾟʼωﾟʼ)︓

31/58

均⼀化への道

ブラックホールを使って稼ぎ出したDisk容量、今なら1万円で買えるよ、みたいな⽌められる時が技術的負債の繰り上げ返済チャンス。

泥臭く頑張るしかないと思ってやってる

32/58

必要なスペック(1)

マスター, スレーブサービスに必要なだけ-VMなサーバーもある-基本はSSD, メモリーは⼤めにメモリーが⼩さいとInnoDB圧縮かけた時に死ぬ

-

マスターの性能がスレーブの性能より⾼いとたまに死ぬマスターはマルチスレッドで更新かかるけどスレーブはシングルスレッド(SQLスレッドのみ)

-

クラッシュしたらデータは捨てる と割り切れば、パラメータを危険側に倒すこともできる

-

33/58

必要なスペック(2)

バッチサーバーないサービスもある-基本的にはユーザートラフィックなし-いざという時にサービスに⼊れられる程度のスペックのマシンに複数インスタンス相乗り

-

サービスレイヤーがシングルマスターな時はあった⽅がいざという時の備えに

-

34/58

必要なスペック(3)

バックアップサーバーインスタンス相乗り-速度よりも容量マター

RAID5 SATAとかでもOK全く遅延してはいけないわけではないので、バックアップ取る時に追いついていれば基本OK

-

パラメーターはとにかく安全側に倒す。-

35/58

必要なスペック(4)

アーカイブサーバー容量だけが正義と⾔いたいけど、ファイル転送や圧縮伸⻑にはそれなりにメモリーもCPUも使う

-

バックアップサーバーからXtraBackup(または.tar.gz)でフルバックアップを2世代保存それ以降の世代はテープやDC外に転送して削除

-

バイナリーログを貯めるのもここ(rsyncかmysqlbinlog)-

36/58

リストアのケースを整理

スレーブの新規作成最新のデータに戻せればOK-基本、そこまで急がない-

クラッシュからの復旧(MyISAM, 羃等でないSQL, サーバーが上がらない, Diskの⼆重障害…)最新のデータに戻せればOK-基本急ぐ-

ほとんどの場合この2パターン

37/58

最新のデータに戻せればOKな場合

バックアップサーバー⽌める基本、その⽌めた時点のデータが⼿に⼊る-

rsync所要時間= ファイルの転送にかかる時間-

新しいサーバーとバックアップサーバー上げる⼗数分あればだいたい追いつく-

バックアップサーバーがあればそもそもリストアですらない

38/58

リストアのケースを整理

データのロールバック(ロールフォワードリカバリー)ロールバック時点から1世代前のフルバックアップからのリストア + ロールバック時点までのbinlog適⽤

-

⾯倒 + 時間かかる上に⼤概急ぐ-原因はだいたい「やらかした」もしくはおもむろに「過去のスナップショット⾒たい」とか、事前に予測のつかない理由

-

最低限の準備だけしてあとはその時考える

39/58

データのロールバック地点

少なくとも急ぐやつは、かなりのケースが過去数時間以内へのロールバック体験上、99%以上は過去24時間まで考慮すればフォローできるデイリーのフルバックアップ2世代(フルバックアップ取得直前へのロールバックを最悪ケースとして)アワリーのbinlogバックアップをフルバックアップの世代と合わせて

-

それより過去へのロールバックは急がないケースがほとんどだし頻度も滅多にないので、DC外やmysqldumpで容量節約

DC外に保持しているのも⼊れると90⽇前までリストアできるポリシー

-

40/58

クラッシュはするものとして考える

ハードウェアクラッシュは避けようがない体感ではハングアップの⽅が多いけど-

Mroongaさんとか⼼が⿊くなっちゃうこともあるそれに⽐べればInnoDBはホント落ちない

Assertも数年に1回レベル-

他にも不測の事態はいくらでもやってくる2か所同時障害とか考えたくないけど

2か所同時に落ちてもいいように…はつらい-けれど、2か所同時に落ちた時にどうすればいいかは考えておく

-

41/58

クラッシュしたら

データを全て消してバックアップサーバーからコピーした⽅がいい場合クラッシュアンセーフなストレージエンジン

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

クラッシュするんだから

InnoDBを安全に使っておくトランザクションのサポート= 確実なクラッシュリカバリーの保証

-

マスターはinnodb̲flush̲log̲at̲trx̲commit= 1-skip-innodb-doublewriteは毎回作り直す覚悟が必要-

43/58

クラッシュするんだから

なるべくスレーブで重複実⾏されても痛みが少ないSQLを選ぶトランザクションを使ってSELECTして値を得てからその値でUPDATE

-

MySQL 5.6以降ならrelay̲log̲recovery= 1 && relay̲log̲info̲repository= TABLEでクラッシュセーフスレーブに(クラッシュしてもレプリケーションが正しく再開される)

-

44/58

クラッシュしたあとは

スレーブ, マスターの整合性チェック必須pt-table-checksumというツールが便利オンラインのままマスターとスレーブのデータの不整合をチェックできるデータが読めなければエラるので、⼀応破損チェックにもなるpt-table-checksum

-

45/58

クラッシュしたあとは

マスターのsync̲binlog != 1 だと、スレーブのmaster̲log̲positionが先に進んでしまうとかどっちを⽣かす︖-log̲slave̲updatesしてればスレーブを⽣かせるんだけどさ。。

GTID有効ならlog̲slave̲updates必須なので、⼀意に選択できる。

-

⾃動昇格に任せるという⼿もある(DurabilityよりもConsistencyとAvailabilityを取る)

-

46/58

モニタリングは⼤事

バックアップはちゃんと取れてるのかリストアできないバックアップとか笑えない

innobackupexの出⼒をチェックして通報-

バックアップ取る時点でレプリケーションが遅れすぎていないか多少は許容するといっても、バックアップ⽇時とデータの時間がズレてるとリストアしにくいサービス系でやってるのと同じ仕組みでSeconds̲behind̲masterを監視(閾値がユルイ)

-

47/58

モニタリングは⼤事

レプリケーションに不整合は起きていないのかリストアできたとしても、間違ったデータじゃ意味がない

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

ここまでのまとめ

バックアップ専⽤スレーブを作るリストアのケースを整理するクラッシュはするものとして織り込むもとのサーバーにリストアできるとは限らないモニタリングは⼤事

49/58

その他ちょこちょこしたこ

と50/58

バックアップのサイズも⼤事

300GBのdatadirを物理バックアップするとだいたい45GB(bzip2圧縮)それを100DBぶん取ると1世代で4.5TB-何世代保管する︖-圧縮, 転送, 解凍のための時間を織り込まないといけないパラレルでアーカイブしてから転送する︖ パラレル転送してからアーカイブする︖

-

51/58

バックアップのサイズも⼤事

mysqldumpの⽅がサイズが⼩さいのは制御ファイル(ib̲logfile*とかundoセグメントとか)はバックアップに含まれない

-

インデックスはバックアップに含まれない(DDLとデータから再作成できるから)

-

BLOBをふんだんに盛り込んでなければ圧縮が効きやすい-FacebookはmysqldumpをHDFSに保管してるって聞いた(単に容量がでかすぎるかららしい)

-

52/58

どこに保管するのか

データセンターに1PB詰め込んでも怒られないファイルサーバーがあるといいなウチにはないかつてはテープに詰め込んでたけどS3をはじめとするクラウドストレージ︖転送前に暗号化案件。それ、mysqlbackupとinnobackupexならできるよ

-

53/58

もとのサーバーにリストアできるとは限らない

主にハードウェアクラッシュで上がってこないパターンクラウドなら楽ちんベアメタルクラウドも結構ラク

-

ベアメタルでも、ウチの環境は結構融通が利いてる(世間⼀般的なことはわからないけれども)

-

最後の⼿段、バッチレイヤーのサービスレイヤーへの接続何があってもバックアップサーバーだけはサービスレイヤーには晒さない

-

54/58

最近の事情

直近のバックアップはデータセンター, 48時間以上過去のバックアップは外部テープドライブに詰められるテープの総容量を超えたので外部転送に

DC内完結では問題にならなかった帯域の問題

-

バックアップは⾃動化されているが、リストアは⼿作業DC内で完結する作業だけでも継続的リストアテストしたい(それが9割以上だし)

-

DCに残ってないフルバックアップからPITRするためのバイナリーログがDCに残ってたりする

-

55/58

直観的なヒント

⽌めて物理バックアップ => mysqldump => XtraBackup => 混合、と推移していくものかなと思う。次のステップに進むべき時にはたぶん⾃然とわかる⽌めて物理バックアップで⾜りている時期にはXtraBackupのドキュメント読んでもきっと⾯⽩くもなんともないmysqldumpでリストアが無理だろうってなった時にはXtraBackupの機能はきっとわかる順当にやってきてれば、XtraBackupだけでつらくなってきた時に他の選択肢をきっと思いつく

-

56/58

夢のようなソリューションがあったら教えてくださ

い57/58

Any Question?

58/58