オンプレOracleからクラウドMySQLへ、停止10分で切り替えた話

そう思うよね。でも実際には暗号化されたカラムがあったり、データ型がそのまま使えなかったりして、単純にデータを抜いて突っ込む、って話じゃなかったんだ。対象は15テーブル、合計30億レコード規模だったよ。

全世界から取引が発生する産業系システムだったから、止まれば売上損失に直結するんだ。24時間365日、気軽には止められない。最終的な切り替え停止は約10分で済ませたよ。

ポイントは「中間DB」を挟んだことなんだ。Oracle本番DBからいきなりMySQLに送るんじゃなくて、まずOracle上に中間DBを作って、そこでストアドプロシージャを使って暗号化データの復号やデータ型変換をやったんだよ。

直接やると、暗号化データの復号・データ型変換・本番への負荷影響っていう3つの問題が同時に降りかかるんだ。中間DBを挟むことで、問題をOracleの世界で解決してからMySQLに渡す、っていう分離ができたんだよね。しかも本番DBに移行処理の負荷をかけずに済んだよ。

だから二段構えにしたんだ。まず事前に一括でフルロードして大部分を移しておく。そのあとDMSのCDC（Change Data Capture）レプリケーションで差分をリアルタイム同期し続けるんだ。切り替え時には同期すべきデータ量が最小限になってるわけだね。

レプリカラグが1分を切るまで待って、書き込みを止めて、最終同期を確認して、DNSの向き先をオンプレからクラウドに変更。DB単体じゃなくてアプリケーションごと丸ごと切り替えたから、DB接続先の個別変更が不要になったんだ。

意外にも地味なところだったんだ。チームのメインスキルがOracleだったから、MySQLの「当たり前」がわからなくて。OracleのDATE型は日時を含むけどMySQLのDATEは日付のみ、VARCHAR2とVARCHARの文字数カウントの違い、NULLと空文字の扱い…「知ってる人には当たり前だけど知らない側からすると地雷」っていうポイントが無数にあったよ。

そうなんだ。Oracle一筋でやってきたチームがMySQLに移行するっていうのは心理的なハードルが高い。ひとつひとつ検証して「大丈夫だ」って確認していく地道な作業が結局一番大事だったんだよね。技術だけじゃ移行は成功しないんだ。