MySQL DBマスタのDC間移設

システムをデータセンターAからデータセンターBに論理移設を行うときのメモ。
肝になるのはDB、特にマスタDBだと思うので、主題の通りおもにDBマスタの切り替えに焦点を当てて手順を書く。
移設先であるデータセンターBではサーバ構築やアプリケーション/コンフィグのデプロイは完了していて、新マスタおよび全スレーブは現マスタにレプリを張っている状態からスタートする。新マスタにはバイナリログ出力など、DBマスタとして振る舞うための設定が入っているものとする。

手順の要約

1. 現DBマスタへの更新クエリをすべてブロックする
2. 全てのスレーブと新マスタでshow slave statusしてログとポジションが一致していることを確認する
3. 新マスタと全てのスレーブでstop slaveする
4. 新マスタと全てのスレーブでreset slaveする
5. 新マスタでreset masterする
6. 全てのスレーブでchange master to新マスタする
7. アプリケーションからの更新クエリを新マスタに向ける
8. DNSでインターネットからのHTTPリクエストを移設先のデータセンターBに向ける

(1) 現DBマスタへの更新クエリをすべてブロックする

DBマスタを切り替えるに当たって、切り替え作業中に更新系のクエリが飛んできたら困るのでそれを止める。DBマスタに更新を行うようなバッチを停止するのも忘れてはならない。

具体的には次のいずれかの手段で行う。

• Web/APにて、更新リクエストを受信した場合はメンテナンスページを返すようにする。
• Web/APの前段のロードバランサで、リクエストをソーリーサーバに飛ばす。
• 現DBマスタにて、Web/APからの接続ユーザをdrop userする。
• 現DBマスタにてflush tables with read lockする。
• 現DBマスタにてset global read only = 1する。

それぞれの手段にメリットデメリットはある。例えば、2つめの手段であるdrop userはJavaなWebアプリケーションなどで多用されるコネクションプーリングには効果がない(既に接続が確立されているため)。

(2)全てのスレーブと新マスタでshow slave statusしてログとポジションが一致していることを確認する

更新クエリのブロックを行った後にshow slave statusすると、新マスタを含むすべてのスレーブでログとポジションが一致しているはず。ここでポジションが一致していなかったりポジションがチマチマ動くようであれば、すべての更新クエリをブロックできていないか、現マスタからのバイナリログの受信および処理が完了していないと思われる。

(3)新マスタと全てのスレーブでstop slaveする

現DBマスタにぶら下がっているすべてのDBでstop slaveしてレプリケーションを止める。

(4)新マスタと全てのスレーブでreset slaveする

マスタを切り替えるために、reset slaveしてレプリケーションの設定をクリアする。



(5)新マスタでreset masterする

新マスタ構築時に、バイナリログ出力の設定をいれてからcreate databaseやalter tableなどを行った場合、それが新マスタのバイナリログに記録されてしまっているためreset masterしてバイナリログを初期化しておく(まあ、次のフェーズのchange master toでログとポジションを指定してあげてもいいんだけど)。

(6)全てのスレーブでchange master to新マスタする


ログとポジションの指定は不要。前のフェーズでreset masterを行っているため、バイナリログとそのポジションは先頭から開始すればいいので。



(7)アプリケーションからの更新クエリを新マスタに向ける

アプリケーションのコンフィグ書き換えなどを行い、更新系のクエリを新マスタに向ける。この時点でシステムは更新リクエストを受け付けることが可能となり、サービスを再開できる状態になる。
(8)DNSでインターネットからのHTTPリクエストを移設先のデータセンターBに向ける

移設元であるデータセンターA側に通信が飛んでこなくなったら移設完了。データセンターAのサーバは撤去可能となる。