VPS間のサーバ移行、ネームサーバ周りの作業はこんな感じ

　
元々の構成はこんな感じでした。[A]がいままでメインで使っていた
旧8Gプラン、[B]が練習用に契約した512MプランをそのままDNSスレーブ
として使っていたもの、そして[C]が今回移行のために契約した新8Gプランです。
　
ドメインレジストラのところで簡易的なDNS機能は提供されているのですが、
ここでは TTLの短縮 ができないために以前思わぬトラブルを引き起こした
ことがあり、それ以降は 自前のDNS をサーバの中に置いています。
　
しかしckworks.jpのIPアドレスを教えてくれるはずのns.ckworks.jpが
ckworks.jpの中にあるという本末転倒な状態が生まれるため、
レジストラのところにns.ckworks.jpのIPアドレスだけは直書きする
ということを行っています。これが俗に言う グルーレコード です。
　

　
このグルーレコードが一番TTLの制御をつけにくいということで、
まず移行先の[C]の中に [A]と同じDNSを 作ってしまい、グルーレコードも
[C]のほうに向けなおしました。[B]のスレーブのDNSも、[A]からではなく
[C]からのスレーブに付け替えています。ただしこの時点ではckworks.jp
自体は[A]を向いているのがポイントです。そして[A][B][C]のDNSすべてで
TTLを600secまで縮めて1日ほど様子を見ます。
　

　
メンテナンス開始時刻になったら、[A]へのhttpアクセスを全て
「メンテナンス中」 にし、その時点でのHTMLデータ、DBデータなどを[C]に
コピーしていきます。ここでもckworks.jpの振り向け先はあくまで[A]です。
ユーザ見えにはckworks.jpはメンテナンス中という表示だけが見えます。
　

　
コピーが完了し、[C]のサーバでサービスが再開できることを確認したら、
最後に一斉にckworks.jpの指す先を [C]に書き換えます。各DNSでTTLを600sec
まで短縮してありますので、10～20分程度あれば新しいDNS情報が浸透し、
ckworks.jp へのアクセスは全て[C]の新サーバに向く形になります。
なお、古いDNS情報を持って[A]にアクセスしに来てしまった人にはメンテナンス中
の表示を返し続けるように、[A]はずっとメンテナンス中にしておきます。
　
DNSは各マシン上で色々なキャッシュ情報を持ってしまうため、ヘタを打つと
丸1日以上アクセスできない人 が出てきたりします。事前に
シナリオを書いて検証しつつ慎重に進めていかないといけないので大変ですね。