03_要点と暗記

Section 3 — 要点と暗記カード

🎯 全レベル向けチートシート。DMS / Datastream の使い分けを暗記。

🚚 移行ツール選定マップ（暗記必須）

シナリオ                                          推奨ツール
─────────────────────────────────────────────────────────────
MySQL → Cloud SQL MySQL                          DMS
PostgreSQL → Cloud SQL PostgreSQL                DMS
PostgreSQL → AlloyDB                             DMS
SQL Server → Cloud SQL SQL Server                DMS
SQL Server → Cloud SQL PostgreSQL (異種)         DMS Heterogeneous
Oracle → Cloud SQL PostgreSQL / AlloyDB          DMS Heterogeneous (拡大中) / Ora2Pg
Oracle → Bare Metal Solution (リフトアンドシフト) Data Pump / RMAN
Oracle → BigQuery (分析統合)                     Datastream
MySQL → BigQuery (分析統合)                      Datastream
PostgreSQL → BigQuery (分析統合)                 Datastream
任意 RDBMS → Pub/Sub (イベント連携)              Datastream
任意 RDBMS → GCS (データレイク)                  Datastream
オフライン大容量 (>10TB)                         Transfer Appliance
S3 → GCS                                         Storage Transfer Service
MongoDB → Firestore (MongoDB)                    mongodump / mongorestore
他DWH → BigQuery                                 BigQuery Data Transfer Service

🎯 DMS vs Datastream 一発判定

キーワード 答え
「DBを移行する」「プライマリを切り替える」「リフトアンドシフト」 DMS
「変更を BigQuery にリアルタイム」「分析統合」「CDC」 Datastream
「Pub/Sub に変更を流す」「イベント駆動」 Datastream
「GCS にデータレイクとして」 Datastream
「ニアゼロダウンタイム移行」 DMS Continuous

⏱️ ダウンタイム → 推奨手段

許容時間 手段
ゼロ DMS Continuous + リバースレプリ
数秒〜数分 DMS Continuous
数時間 DMS One-time or mysqldump/pg_dump
数日 Transfer Appliance

🧩 ゼロダウンタイム フロー（暗記）

1. 準備（バックアップ・ターゲット構築・ネットワーク）
        ↓
2. DMS Continuous 開始（スナップショット + CDC）
        ↓
3. 遅延 < 5秒 を確認
        ↓
4. アプリ書き込み停止 → 残ログ適用待ち
        ↓
5. Promote（新DBを Primary に昇格）
        ↓
6. アプリ接続先切替 → 書き込み再開
        ↓
7. リバースレプリケーション（保険）
        ↓
8. 数日〜数週間運用後、旧 DB 廃止

🔄 リバースレプリケーション

用途 実装
同種 DB の保険 DMS で逆方向ジョブを作る
異種 DB の保険 Striim or 手動 CDC
不要な場合 ダウンタイム許容 or バックアップで代替

📋 異種DB移行 主要ツール

ツール 用途
DMS Migration Assistant Google 公式、対応拡大中
Database Migration Assessment (DMA) 移行前評価、難易度判定
Ora2Pg Oracle → PostgreSQL、OSS の定番
Striim 商用、リアルタイム CDC、複雑な変換対応

🚨 移行で失敗するパターン TOP 5

  1. 事前テスト不足 → 本番でアプリが動かない
  2. ロールバック計画なし → 問題発生時に詰む
  3. DDL/DML 互換性確認漏れ → ストアドプロシージャが動かない
  4. DMS 遅延の監視不足 → カットオーバーで詰む
  5. コミュニケーション不足 → カットオーバー中にアプリ側が動けない

💡 整合性検証 4 階層

  1. 行数 （COUNT(*) を旧新で比較）
  2. ハッシュ （MD5 で全体を比較）
  3. サンプリング （ランダム n 行を比較）
  4. アプリ E2E テスト （業務フロー実行）

🚫 ひっかけパターン

問題 NG 回答 正解
「Oracle を AlloyDB へ完全移行」 mysqldump DMS Heterogeneous / Ora2Pg
「Oracle の変更を BigQuery 分析へ」 DMS Datastream
「MongoDB アプリ移行」 Bigtable Firestore (MongoDB-compatible)
「PB級オフライン転送」 gsutil cp Transfer Appliance
「Oracle Exadata を物理移行」 Cloud SQL Bare Metal Solution
「リアルタイム DB → BigQuery」 BigQuery Data Transfer Datastream

🔧 DMS Continuous 設定で覚えるべき項目