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

ひよこ

OracleからMySQLへ、コピーするだけじゃダメなの？

ペンギン先生

移行するのはデータだけではないよ。日時や空文字の意味、SQL、アプリの動きも合わせよう。まず、小さなテストデータで「同じ意味を保てるか」を確認するのが入口だね。

ひよこ

この記事の事例は、どのくらいの規模だったの？

ペンギン先生

この事例では15テーブル、合計30億レコードだったよ。暗号化されたカラムやデータ型の変換も対象だったんだ。

ひよこ

動いているシステムの切り替えは、どのくらい止めたの？

ペンギン先生

この事例では、最終的な切り替えの停止が約10分だったよ。個別の案件での結果で、同じ方法なら必ず10分で移行できる、という意味ではないんだ。

ひよこ

中間DBは何のため？

ペンギン先生

この事例では、Oracle側に中間DBを置き、復号や型変換をしてから渡しているよ。ただし、中間DBはどの移行でも必須ではない。本番からの複製やログ取得にも負荷があり、影響の測定が必要なんだ。

ひよこ

全部のデータを、切り替える間に送るの？

ペンギン先生

既存データを事前にフルロードし、その後の変更をCDCで反映する方法があるよ。停止中に残る作業を減らせるけれど、CDCは遅延が変わる仕組みで、常に即時反映されるわけではないよ。

ひよこ

遅れが1分以内なら、切り替えていい？

ペンギン先生

それだけでは決められないよ。書き込みを止め、最後の変更が反映されたかを確かめ、移行エラーや未反映の件数、重要な取引の整合も確認しよう。DNSの変更だけで全接続が同時に移るとは限らないんだ。

ひよこ

DATEや空文字は、どこに気を付ける？

ペンギン先生

OracleのDATEは時刻も持つけれど、MySQLのDATEは日付だけだよ。OracleがNULLとして扱う長さ0の文字列も、MySQLでは空文字とNULLを区別する。検索や集計の結果も確かめよう。

ひよこ

覚え方を教えて！

ペンギン先生

「DB移行」って出てきたら「データの意味と、最後の変更まで確かめる引っ越し」と思えばだいたいOK！

最初に確かめること：引っ越し後も同じ意味？

データベースの移行は、箱の中身を運ぶだけではありません。住所録を別の形式へ移すときに、日付、文字、空欄の意味も合わせるような作業です。

この記事の移行事例と、以下の小さな学習用データは別のものです。学習用の例で、まず日時と空欄がどう変わるかを考えてみましょう。

これは移行の実行結果ではなく、テストケースの例です。実際の移行先で、アプリの登録・表示・検索・集計まで確かめる材料にします。

名前が似ていても、データ型の意味は違う

OracleのDATEは、年・月・日だけでなく時・分・秒も持ちます。MySQLのDATEは日付だけです。時刻を保つなら、DATETIMEなどを候補にし、扱う範囲やタイムゾーンの約束も確認します。型名を置き換えるだけでは済みません。

Oracleは、現在の仕様では長さ0の文字列をNULLとして扱います。一方、MySQLでは空文字とNULLは別です。たとえば、連絡先がNULLの行を探す条件と、空文字の行を探す条件は違います。

IS NULLで探すのか、= ''で探すのかを、アプリの入力規則と合わせて決めましょう。NULLの比較を= NULLで書くものではありません。

文字列も、OracleのVARCHAR2ではBYTE/CHARの指定があります。MySQLのVARCHARの長さは文字数で指定しますが、行サイズなどのバイト上限も関わります。日本語、長い文字列、末尾の空白、文字の比較や並べ替えをテストに含めると、単純な英数字だけでは見つからない違いに気付けます。

フルロードとCDCを分ける

フルロードは、既存データを移す段階です。CDCは、その後の変更を継続的に取得して反映する段階です。大量のデータを事前に運び、最後の差分を少なくする考え方で、短い停止時間を目指せます。

ただし、AWS DMSのCDCはリアルタイム性や一定の遅延を保証していません。元DBの負荷、ネットワーク、移行用のリソース、移行先の処理などで遅れます。Oracleをソースにする場合は、ログの保持、追加のログ設定、権限などの前提も必要です。

中間DBは、変換などの作業を分離するために選ぶ構成です。複製元の読み込みやログの取得まで無負荷になるわけではありません。元の更新を中間側へどう追従させるかも含め、構成に合わせて確認します。

切り替えの合格条件を先に決める

1. 書き込みを止められる範囲と、止める担当を決めます。アプリ以外のバッチなども含めます。
2. 最後の変更が移行先へ反映され、エラーや未反映のデータがないか確かめます。
3. 重要なテーブルの件数、取引の合計、代表的なデータと、アプリの動作を照合します。
4. 接続先を切り替え、古い接続が残っていないか、動作・監視を確認します。
5. 問題があった場合に、いつ誰が中止し、どの状態へ戻すかを決めておきます。

同期の遅れが小さいことと、移行が正しいことは別です。DNSのキャッシュや既存の接続が残る場合もあるため、DNSの変更だけで全処理が同時に新しい側へ移るとは限りません。

切り替え後の書き込みが新しいDBだけに入った場合、そのまま古い側へ戻すと、その変更を失う可能性があります。戻す際のデータの扱いも計画します。

データ以外も確認する

ストアドプロシージャ、索引、制約、採番、SQL、アプリの接続設定も確認対象です。DMSのデータ移行と、スキーマ・コードの変換は分けて考えます。Schema Conversionの評価結果で、自動変換できない項目を確認し、必要な修正とテストを行います。

具体的なDBの版・クラウド構成・業務の条件で手順は変わります。この記事だけを本番の作業手順とせず、検証環境でリハーサルし、合格条件と復旧方法を確認してください。

次に学ぶなら

移行後のDBを選ぶ観点はMySQLとPostgreSQLの比較、変更を確定する単位はトランザクションの仕組みへ進めます。

参考資料

以下は技術的な仕組みと制約を確認する資料です。この事例の規模や停止時間を証明する資料ではありません。

• Oracle：Data Types — DATEの時刻・VARCHAR2のBYTE/CHAR指定
• Oracle：Nulls — 長さ0の文字列とNULL
• MySQL 8.4：DATE・DATETIME・TIMESTAMP — 日付と日時の区別
• MySQL 8.4：NULL — 空文字との区別・IS NULL
• MySQL 8.4：CHAR・VARCHAR — 文字数・バイト上限・文字集合・照合順序
• AWS DMS：CDC — フルロードとCDC・遅延・ログからの変更取得
• AWS DMS：Oracleソース — ログ・権限・supplemental loggingなどの前提
• AWS DMS：Schema Conversion — 変換できない要素と手動対応の評価