Google Cloud Database Migration Service

9月の第2週からの移行体験を時系列で記録しておく。最初は簡単だと思ってたが、実際は予想以上に時間がかかった。

9月7日（土）朝4時 - メモリエラーでサーバーダウン。mysqld: Out of memory (Killed by signal 15)。この時点でもう移行は避けられない状況だった。MySQL メモリ関連の問題は頻繁に発生する。

9月9日（月） - 朝会で移行の期限と予算が決定。「来月までに何とかしろ」と言われ、月30万の予算で作業開始。データベース移行の計画を立てる必要があった。

9月10日 - AWS DMSとGoogle Cloud DMSを比較検討。Googleの「同種移行は追加料金なし」という説明に惹かれて決定。

9月11日 - 接続設定でつまずく。IPアドレスのタイプミス（10.0.1.100のつもりが10.0.1.10）で40分ほど悩んだ。ERROR 2003 (HY000): Can't connect to MySQL serverが出続けた。MySQL接続のトラブルシューティングは事前に読んでおくべきだった。

9月12日〜15日 - 実際の移行作業。1.2TBのデータ移行に予想以上の時間（13時間）がかかった。大容量データベースの移行では事前の計画が重要。

9月16日 - 移行完了したが、文字化け問題が発覚。

9月17日〜18日 - 文字コード修正で週末作業。MySQL文字セットの変換は時間がかかる。

AWS DMSとの比較

AWS DMS（Database Migration Service）とGoogle Cloud DMSで比較検討した結果。AWS DMSの機能とGoogle Cloud DMSの違いを理解することは重要：

料金比較:

• AWS DMS: t3.micro（$0.0309/時間）+ データ転送料金
• Google Cloud DMS: 「同種移行は追加料金なし」

Googleの「追加料金なし」に惹かれて決定したが、これはDMSサービスの利用料のみで、移行先のCloud SQLインスタンス料金（月¥32,000程度）は別途必要だった。事前に料金計算機でしっかり計算すべきだった。

実際の移行結果

予想より良かった点:

• Change Data Captureで本番を停止せずに移行できた（約15分のダウンタイムのみ）
• レプリケーション設定を手動で行う必要がなかった
• Google Cloud Consoleで移行進捗をリアルタイムで確認できた

想定外だった問題:

• VPC peering設定で半日ほど時間を費やした。gcloud compute networks peerings createの権限設定でつまずいた
• 文字エンコード問題：ERROR 1366: Incorrect string valueエラーが大量発生。古いテーブルのlatin1エンコードに日本語データが混在していた
• ネットワーク帯域の不足。100Mbpsでは不十分で、深夜の長時間作業が必要だった

実際にかかった期間:

• 移行作業自体: 1日
• 事前準備（VPC設定、接続テスト）: 3日。VPC設定は特に重要。
• 文字化け修正と性能チューニング: 2週間

公式ドキュメントも事前に確認しておくべきだった。

接続設定での躓き

最初の躓きは基本的な設定ミス。ソースDBのエンドポイントでIPアドレスを間違って入力していた（10.0.1.100のつもりが10.0.1.10）。DMSコンソールで「接続をテスト」を実行するとERROR 2003 (HY000): Can't connect to MySQL serverが継続的に発生。

セキュリティグループやポート番号を確認してもエラーが解消されず、最終的に同僚に確認してもらって単純なタイプミスが発覚した。接続設定のドキュメントを事前に確認しておくべきだった。

ネットワーク設定とセキュリティ要件

Google Cloud DMSのIPアドレス範囲（35.235.240.0/20）をfirewallの許可リストに追加しようとしたところ、セキュリティチームから本番環境への外部IPアクセスに関する懸念が上がった。

結果的にVPC Peeringを設定することになり、gcloud compute networks peerings createコマンドで接続を構成した。この作業に予想以上の時間がかかったが、ネットワーク接続オプションを事前に理解しておけば効率的に進められたと思う。

主キーなしテーブルの対応

DMSの事前チェックで複数のテーブルに主キーが設定されていないエラーが発生：

ERROR: Table 'customer_logs_2019' has no primary key or unique index
ERROR: Table 'session_data_2018' has no primary key or unique index
ERROR: Table 'temp_cache' has no primary key or unique index

古いテーブル設計で主キーが設定されておらず、ALTER TABLE customer_logs_2019 ADD PRIMARY KEY (id)で主キーを追加しようとしたところ、重複レコードが存在して「Primary key duplicate error 1062」が発生。

重複データを特定して削除した後、主キーを追加することで解決した。移行前の準備は重要な工程だと実感した。

文字エンコード問題の対応

移行開始後に文字化けエラーが大量発生。古いテーブルがlatin1エンコードに設定されているのに日本語データが格納されている状況：

ERROR 1366: Incorrect string value: '\xE3\x82\xA2' for column 'customer_name' at row 8472
ERROR 1366: Incorrect string value: '\xE6\x97\xA5\xE6\x9C\xAC' for column 'address' at row 8473
ERROR 1366: Incorrect string value: '\xE4\xBC\x9A\xE7\x4E\xAE' for column 'company_name' at row 8474

ALTER TABLE customer_master CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciで文字エンコードを修正したが、この作業に週末の大部分を費やした。文字セットとコレーションの設定は移行前に十分確認すべきポイントだった。

ネットワーク帯域の不足

本格移行時のデータ転送で予想以上に時間がかかった。1.2TBのデータ転送について、理論値では数時間で完了する計算だったが、実際の帯域制限により予想を大幅に上回る時間が必要だった。

深夜にCDC（Change Data Capture）でのミラーリングを開始し、翌日昼過ぎまで継続。この間、オフィス内の他のネットワーク利用に影響が出てしまった。データベース移行の計画を事前に十分検討し、作業タイミングについて関係者と調整すべきだった。

参考: 以前のOracle移行経験

前職でのOracle 11g → PostgreSQL移行では、今回のMySQL移行よりもはるかに複雑な課題に直面した：

主な課題:

• 大量のPL/SQLパッケージとストアドプロシージャの移行
• Oracle固有の構文（ROWNUM、DECODEなど）のPostgreSQL対応
• カスタムファンクションの書き直し
• データ型の差異への対応

AI支援ツールの活用:

• Gemini AIを使った自動変換を試したが、成功率は期待より低かった
• 結果的に手動修正が大部分を占めた
• 移行方法の比較を事前に行うべきだった

学んだこと:
Oracle移行は MySQL移行と比較して格段に複雑。同種DB間の移行（MySQL → Cloud SQL for MySQL）の方が圧倒的に楽だった。Cloud SQLへの移行は同種DBなら比較的スムーズ。異種DB移行は複雑で専門ツールが必要.