mysql replicationの復旧方法

Contents


このページでは、mysql レプリケーション(replication) の復旧手順を示します。mysqld_multiを用いた簡単に構築できるサーバ構成で、mysql レプリケーション(replication) の復旧シナリオを数パターン示します。

読者の方にこのシナリオを読んで頂き、

  • replication復旧の難しさ
  • 唯一絶対の”正しい手順”は存在しない事

を感じ取って頂ければ幸いです。MySQL replication構成によって復旧手順は難しくも簡単にもなります。復旧作業を行なう際は、データロス期間vsダウンタイムのようなトレードオフを判断する必要があります。レプリケーションの復旧はDBAの単調作業ではなく、事業としての意思決定である事をご理解頂けると幸いです。

mysql レプリケーション 基本概念

mysql レプリケーション 基本概念 – binary log, relay log

mysql replicationの設定方法で説明した内容と重複しますが、MySQLのreplication (レプリケーション)を設定するには、以下4つのキーワードを抑える事が重要です。

  • Binary log ( バイナリログ)
  • Relay log ( リレーログ )
  • I/O thread
  • SQL thread

これら4つのキーワードについて、簡単なMySQL replication (レプリケーション) の動作を図示すると以下のようになります。

mysql_replication_002

MySQL replication ( レプリケーション ) の処理の概要を説明すると次のようになります。

  • Masterサーバに書き込まれた変更処理をBinary logに書き出します。
  • SlaveサーバのI/O threadはBinary logを読み取り、Relay logに変更内容を書き出します。
  • SlaveサーバのSQL threadはRelay logを読み取り、読み取った内容をデータベースに反映させます。

mysql レプリケーション 基本概念 – ログ ポジション

mysql レプリケーションの復旧作業を行なうには、バイナリログ(Binary log), リレーログ(relay log)がどこまで処理されたかを把握する事が大事です。mysqlの文脈で語られるポジションという用語は、ログがどこまで処理されたかを表す概念です。ポジションを確認するには、show master status, show master infoというコマンドを用います。

このページで示す復旧シナリオでは、ポジションの値を見て操作するシナリオは存在しません。しかし、想定外の壊れ方をした場合やreplication復旧手順として問題ないかどうかレビューする場合は、必須となる知識ですので、必ず会得しておきましょう。

mysql レプリケーション 基本概念 – ログ ポジション – show master status

Masterサーバにて、バイナリログがどのポジションまで出力されたのかを確認できるコマンドがshow master statusです。show master statusの出力例は以下のようになります。

mysql レプリケーション 基本概念 – ログ ポジション – show slave status ;

Slaveサーバのポジションの読み方はかなり複雑です。Master_Log_File, Read_Master_Log_Pos, Relay_Log_File, Relay_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Posの6つの用語の意味を正確に把握する必要があります。

ポジションを表示させるには、以下のように”show slave status”コマンドを使用して下さい。

各ポジションの意味は以下の通りです。

項目意味
Master_Log_FileI/O threadは、Masterサーバのバイナリログを読み取ります。今、バイナリログのどのファイルを読んでいるかを表します。
Read_Master_Log_PosI/O threadは、Masterサーバのバイナリログを読み取ります。今、バイナリログのどのポジションを読んでいるかを表します。
Relay_Log_FileSQL threadは、Slaveサーバのレプリケーションログを読み取ります。今、レプリケーションログのどのファイルを読んでいるかを表します。
Relay_Log_PosSQL threadは、Slaveサーバのレプリケーションログを読み取ります。今、レプリケーションログのどのポジションを読んでいるかを表します。
Relay_Master_Log_FileSQL threadは、Slaveサーバのレプリケーションログを読み取ります。今、読み取られているログが、Masterサーバ バイナリログのどのファイルに相当するかを表します。
Exec_Master_Log_PosSQL threadは、Slaveサーバのレプリケーションログを読み取ります。今、読み取られているログが、Masterサーバ バイナリログのどのポジションに相当するかを表します。

log_position_001

Master_Log_File, Relay_Master_Log_Fileの意味は混同しやすいので、細心の注意を払ってください。また、それぞれのポジションの実態は、master.info, relay.infoというファイルです。

mysql レプリケーション 復旧シナリオ 事前準備

mysql レプリケーション 復旧シナリオ 事前準備 – mysqld_multi環境の構築

mysqld_multiを用いて、3つのmysqld(MySQLサーバ)を起動させます。動作確認のシナリオで使用する/etc/my.cnfの設定は以下の通りです。mysqld_multiの使い方は、mysqld_multiの設定方法を参照ください。

mysql レプリケーション 復旧シナリオ 事前準備 – レプリケーションの設定

3つのmysqld(MySQLサーバ)に対してレプリケーション(replication)の設定を行います。具体的な設定方法は、mysql replication 設定方法を参照ください。

mysql レプリケーション 復旧シナリオ 事前準備 – 免責事項

以下の復旧シナリオでは、mysqld停止とcpコマンドによるデータコピーが基本的なオペレーションになっています。しかし、実務では、mysqldの停止は確認事項が多く、非常に難しい作業です。データコピーの方法もcpコマンド以外に多数存在します。

このページでは、実務ではなく概要を把握してもらう事を念頭においておりますので、細かな考慮点は検討の対象外としております。実務で必要になる確認項目や勘所は最終章のTipsにまとめております。

mysql レプリケーション 復旧シナリオ 01 – スレーブサーバの障害

mysql レプリケーション 復旧シナリオ 01 – スレーブサーバの障害 – 障害シナリオの再現

以下のような構成になるようMySQLレプリケーション環境を構築します。

mysql_recovery_scenario_001

この環境において、mysqld_multi 3の障害を発生させます。

mysql レプリケーション 復旧シナリオ 01 – スレーブサーバの障害 – 障害復旧

コピー元となる、mysqld_mutli 2をI/O thread, SQL threadを停止させます。これはコピーを行なっている最中にファイルの書き込みを避ける意図です。

mysql_multi 2からmysqld_multi 3へのデータコピーを行ないます。レプリケーションを行なう環境において、server-idとuuidの重複は許されません。uuidはauto.cnfに記載されているので、auto.cnfの削除も忘れずに行ないましょう。auto.cnfが存在しない場合は、自動的にuuidが付与されます。

mysql レプリケーション 復旧シナリオ 01 – スレーブサーバの障害 – 動作確認

mysqld_multi 2,3を起動させます。

それぞれ、レプリケーションが正常に動作している事を確認します。

mysql レプリケーション 復旧シナリオ 02 – マスターサーバの障害 ログ転送保証あり

mysql レプリケーション 復旧シナリオ 02 – マスターサーバの障害 ログ転送保証あり – 障害シナリオの再現

以下のような構成になるようMySQLレプリケーション環境を構築します。

mysql_recovery_scenario_002

この環境において、マスターサーバ mysqld_multi 1の障害を発生させます。

mysql レプリケーション 復旧シナリオ 02 – マスターサーバの障害 ログ転送保証あり – 障害復旧

マスターに昇格するサーバ側のバイナリログのポジションを確認します。mysqld_multi 2で、”SHOW MASTER STATUS”コマンドを発行し、バイナリログのポジションを確認します。

必須とは言い切れませんが、マスターに昇格する前には”RESET MASTER”コマンドを発行し、マスターサーバとしての情報を一度削除する事をお勧めします。

スレーブサーバ側で、レプリケーションの向き先を変更します。mysqld_multi 3において、レプリケーションの向き先をmysqld_multi 1からmysqld_multi 2へ変更します。

mysql レプリケーション 復旧シナリオ 02 – マスターサーバの障害 ログ転送保証あり – 動作確認

mysqld_multi 2からmysqld_multi 3へのレプリケーションが行われている事を確認します。スレーブサーバ mysqld_multi 2側で、”SHOW SLAVE STATUS”コマンドを発行し、Slave_IO_Running, Slave_SQL_RunningがともにYesになっている事を確認します。

mysql レプリケーション 復旧シナリオ 03 – マスターサーバの障害 ログ転送保証なし

mysql レプリケーション 復旧シナリオ 03 – マスターサーバの障害 ログ転送保証なし – 障害シナリオの再現

以下のような構成になるようMySQLレプリケーション環境を構築します。

mysql_recovery_scenario_003

前述の復旧シナリオ02との違いは、リレーログの転送に遅延が発生している事です。ネットワークの帯域が枯渇している場合やLOAD DATA文のようなトラフィックのバーストが発生しうる場合は、リレーログ転送の遅延が発生します。

リレーログの遅延はかなりの負荷をかけないと再現できませんので、ここでは”STOP SLAVE”コマンドを用いて疑似的に転送遅延を再現させます。まず、mysqld_multi 3で”STOP SLAVE”コマンドを入力し、意図的にリレーログが転送させないようにします。

マスターサーバ mysqld_multi 1において、バイナリログを発生させます。何らかの更新を伴うクエリをmysqld_multi 1に対して発行します。

以上の手順で、リレーログの転送遅延を再現できました。この状態で、マスターサーバmysqld_multi 1の障害を発生させます。

mysql レプリケーション 復旧シナリオ 03 – マスターサーバの障害 ログ転送保証なし – データ復旧

mysqld_multi 3はリレーログの転送が遅れてしまったため、mysqld_multi 2, 3の間でデータの差異が存在します。mysql レプリケーションはマスター/スレーブ間のデータが一致している事を前提としておりますので、まずmysqld_multi 3のデータを復旧させる必要があります。

mysqld_multi 2に存在するリレーログを用いてデータを復旧させます。復旧させるには、何分何秒のデータから何分何秒までのデータが破損しているかを明らかにする必要があります。

mysqld_multi 3上のリレーログを読み取り、どこまでのリレーログがデータベースに反映させたかを確認します。リレーログはバイナリ形式で保存されているので、読取にはmysqlbinlogコマンドが必要となります。ログを全て出力させると膨大な量になりますので、–start-datetimeオプションやtailを用いて必要な分だけ表示させると良いでしょう。

以下のような出力の場合は、一番最後に実行されたクエリは時刻21:43:14, タイムスタンプ1412944994である事が分かります。

次に遅延が発生してないスレーブであるmysqld_multi 2上のリレーログを観察します。すると、遅延が発生しているmysqld_multi 3はポジション712まで転送済であるものの、ポジション804以降が未転送である事が分かります。

ポジション804以降のリレーログを、遅延が発生しているmysqld_multi 3 に反映させる事によって、mysqld_multi 2, 3間のデータ差異が埋まります。リレーログの差異を埋めるコマンド例は以下の通りです。

最後に、mysqld_multi 2, 3間のレプリケーションを設定し、復旧作業完了です。

mysql レプリケーション 復旧シナリオ 04 – チェーン構成 マスターサーバの障害

mysql レプリケーション 復旧シナリオ 04 – チェーン構成 マスターサーバの障害 – 障害シナリオの再現

以下のような構成になるようMySQLレプリケーション環境を構築します。

mysql_recovery_scenario_004

この環境において、マスターサーバ mysqld_multi 1の障害を発生させます。

mysql レプリケーション 復旧シナリオ 04 – チェーン構成 マスターサーバの障害 – 障害復旧

チェーン構成におけるマスターサーバの復旧は非常に簡単です。孫スレーブサーバの構築と同様の手順で復旧する事ができます。

まず、孫スレーブのレプリケーション元となるスレーブサーバmysqld_mutli 3において、”stop slave”コマンドでレプリケーションを停止させ、ディスクへの書き込みがない状態にします。また、このディスクへの書き込みがない状態のマスターポジションをメモに控えておきます。

スレーブサーバmysqld_multi 3から孫スレーブmysqld_multi 1へのデータコピーを行います。この時、UUIDが記載されたauto.cnfを削除し、UUIDがバッティングしないように注意して下さい。また、設定によっては、PIDファイルの削除も必要になるかもしれません。

次の手順が一番の注意ポイントです。孫スレーブmysqld_multi 1をそのまま起動してしまうと、マスターに対してレプリケーションを行ってしまいます。これでは、想定外のデータが書き込まれてしまいますので、起動と同時にレプリケーションが行われないよう、–skip-slave-startオプションを指定します。

以下のように/etc/my.cnfの[mysqld1]セクションにskip-slave-startオプションを一時的に加筆します。

孫スレーブであるmysqld_multi 1を起動させます。”CHANGE MASTER TO”コマンドにより、レプリケーションを設定します。

mysql レプリケーション 復旧シナリオ 04 -チェーン構成 マスターサーバの障害 – 動作確認

レプリケーションが正常に行われている事を確認します。

mysql レプリケーション 復旧シナリオ 05 – チェーン構成 スレーブサーバの障害

mysql レプリケーション 復旧シナリオ 05 – チェーン構成 スレーブサーバの障害 – 障害シナリオの再現

以下のような構成になるようMySQLレプリケーション環境を構築します。

mysql_recovery_scenario_005

説明の都合上、他シナリオに比べて、やや実践的な環境を構築します。マスターサーバに定期的な書き込みを行います。以下は、定期的な書き込みを行う操作例です。

この状態で、スレーブサーバ mysqld_multi 2の障害を発生させます。

mysql レプリケーション 復旧シナリオ 05 – チェーン構成 スレーブサーバの障害 – 障害復旧

スレーブサーバの復旧はやや難しいです。孫スレーブであったmysqld_multi 3のポジションを”SHOW SLAVE STATUS”コマンドで確認しても、どこからレプリケーションを再開させれば良いかかは判断できないためです。レプリケーションを再開させるポジションは、リレーログ, バイナリログを目視で読み取って判断するしかありません

まず、孫スレーブであったmysqld_multi 3のリレーログを確認します。すると、”insert into test.sample values (20)”, “COMMIT”まで実行された事が分かります。

次にマスターサーバであるmysqld_multi 1のバイナリログを観察します。すると、”insert into test.sample values (20)”, “COMMIT”の次のクエリであるポジション5076より再開すれば良い事が分かります。

mysqld_multi 1からmysqld_multi 3へのレプリケーションを行います。

mysql レプリケーション 復旧シナリオ 05 – チェーン構成 スレーブサーバの障害 – 動作確認

スレーブサーバmysqld_multi 3において、レプリケーションが動作している事を確認します。

Tips

mysql server データコピー時の注意点

このページ紹介した手順は事前確認なしにデータコピーを行ってますが、実践では丁寧な確認作業が必要となります。cpコマンド、LVM Snapshot, DRBDのようなクラスタリング機能, AWSが提供するスナップショット機能などコピーの手段は様々ですが、これらの手段はディスク上のデータをコピーする事に注意して下さい。つまり、メモリ上のデータはコピーされません。mysqlの複製を作成する時はメモリ上にデータが存在しない事を確認する必要があります

mysql server データコピー時の注意点 – temporary table

mysqlのデータコピーで、運用者をよく泣かせる仕様のひとつがtemporary tableです。temporary tableはメモリ上に展開されるデータですので、temporary tableが存在する場合はmysqlの複製を行ってはいけません。temporaryテーブルの有無は、”show status”コマンドのSlave_open_temp_tablesで確認する事ができます。

以下のようにSlave_open_temp_tablesが1以上の値となっている場合は、MySQLの複製を控える事をお勧めします。

mysql server データコピー時の注意点 – ログ先行書き込み(Write Ahead Log)

innodbにはログ先行書き込みという仕組みがあります。ログ先行書き込みとは、「まずは高速なメモリ上にデータを書き込み、後に非同期でファイルに書き込む」高速化のための仕組みです。

メモリ上に書き込まれていても、まだファイルには書き込まれていないデータが存在する場合は、MySQLの複製を控える事をお勧めします。”show engine innodb status”コマンドでLog sequence number, Last checkpoint atなどの値が全て同じになっている場合は、メモリ上のデータが全てディスクに反映されたと判断できます。

mysql レプリケーション遅延

mysqlの復旧手順を考える際は、遅延が定常的に発生するのかどうかも含めて手順化する必要があります。私が勝手にネーミングした概念ではありますが、mysqlの遅延は”ネットワーク遅延”と”リレーログ反映待ち”の2種類が存在します。

多くの場合は”リレーログ反映待ち”が実際に起きている遅延です。しかし、遅延に関する誤認識をもっているエンジニアが多いせいか、私は「ネットワークが遅い」「mysqlの遅延が発生している」との問い合わせを数多く対応しました。ネットワークエンジニアの幸せのため、声を大にして誤解を解く説明を行いたいと思います。

mysql レプリケーション遅延 – ネットワーク遅延

ネットワーク帯域が小さい場合やネットワークレイテンシが大きい場合は、マスター スレーブ間でログ転送の遅延が発生しうる場合があります。ネットワークがボトルネックとなり遅延が発生するのは、以下のような場合です。どのようなケースでネットワーク起因の遅延が発生するかを理解するだけで、無駄な切り分け工数や無駄な説明工数を削減する事ができるでしょう。

  • 広域網越しでmysql レプリケーションを行なう場合
  • fusion io のような高速ストレージを使用し、「ディスク > ネットワーク」 のような関係が成り立つ場合
  • BLACKHOLEエンジンのように、メモリ上にデータベースを作成する場合 ( BLACKHOLEの説明は省略します )
  • 通信速度が大幅に劣化するようなレアケースのネットワークの障害が発生した場合 ( 例 : STP状態異常、MACアドレスバッティング、スイッチ機器が大量パケットを送付するような残念な壊れ方をした場合 )

それでは、マスター スレーブ間の遅延について確認方法について考えてみましょう。マスタースレーブ間の遅延を確認するには、マスターとスレーブの両方で同時にshowコマンドを実行する必要があります。スレーブサーバのみの情報では、ネットワークの遅延有無は判断できません。

動作確認例は以下の通りです。マスター側のバイナリログのポジションが1280になっているのに対し、スレーブ側のRead_Master_Log_Posが1058になっています。1058から1280がネットワークに起因した遅延分となります。

mysql レプリケーション 基本概念 – 遅延確認 – リレーログ反映待ち

MySQLはマスターと実行したクエリと同様のクエリがスレーブで実行されます。スレーブサーバではリレーログに書かれたSQLが順次実行されますので、処理に時間がかかるSQLが発行されれば、リレーログ反映待ちの遅延になります。

“ネットワーク遅延”と”リレーログ反映待ち”の2パターンの遅延を紹介しましたが、私が実務で経験した遅延は全て”リレーログ反映待ち”です。 mysqlの遅延と言えば多くの場合は、リレーログ反映待ちを指すと思って下さい。

リレーログ反映待ちが発生しうる状況としては以下をあげる事ができます。

  • マスター, スレーブ間でI/O性能に大きな差がある ( BLACKHOLEエンジンもI/O差が発生するデザインパターンの一種)
  • LOAD DATA, bulk insert等の大量更新処理が行なわれる
  • 何らかの理由によりスレーブサーバにロックがかけられる

動作確認例は以下の通りです。スレーブサーバで”show slave status”を実行します。Read_Master_Log_PosとExec_Master_Log_Posに差が生じている場合は、リレーログ反映待ちの遅延が発生していると判断できます。以下出力例の場合は、839から1058までが遅延となります。

“show slave status”のSeconds_Behind_Masterからリレーログ反映待ちを判断する事ができます。Seconds_Behind_Masterはリレーログ反映にかかる推定時間(秒)です。Seconds_Behind_Masterが0より大きい値を示しているならば、遅延が発生していると思って下さい。

リレーログ反映待ちのクエリを抽出するには、MySQLマスターサーバのバイナリログに対してmysqlbinlogコマンドを実行します。Exec_Master_Log_PosからRead_Master_Log_Posまでのポジションを指定して下さい。

リレーログ反映待ちのクエリは、MySQLスレーブのリレーログからも抽出する事ができます。 Relay_Log_Posから末尾までのログを抽出する事でも同様の結果を得る事ができます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする