変更要約: Professional Cloud Database Engineer 第3章を新規作成（ドメイン3「移行」: 戦略と計画＝ゼロ/ニアゼロ停止(継続レプリケーション)/長時間停止/フォールバック/DDL・DML 変換/リバースレプリケーション、ツールとレプリケーション＝Database Migration Service/Datastream(CDC)/Storage Transfer Service/Transfer Appliance/検証）。
3.1移行戦略と計画
ゼロ/ニアゼロダウンタイム・長時間停止・フォールバックといった移行戦略と計画、DDL/DML 変換、Google Cloud から移行元へのリバースレプリケーション、そしてビジネス要件に応じた移行アプローチの選択を理解します。
多くのデータベースは新規ではなく移行で Google Cloud に来ます。停止をどこまで許せるか、失敗時にどう戻すかを、ビジネス要件から計画します。
3.1.1移行戦略の選択
移行は許容停止時間で選びます：業務を止めずに切り替える ゼロ/ニアゼロダウンタイム（継続レプリケーションで追いつかせてから切替）、計画的に長く止める 長時間停止（extended outage）。いずれも失敗に備え、移行元へ戻せる フォールバック を計画します。「止めずに移行＝ゼロ/ニアゼロダウンタイム（継続レプリケーション）」「失敗時に戻す＝フォールバック」と結びます。
3.1.2変換とリバースレプリケーション
異種データベース間の移行では、スキーマやコードの DDL/DML 変換 が必要です（型・構文・ストアドプロシージャの違いを吸収）。移行後の安全策として、Google Cloud から移行元へ変更を戻す リバースレプリケーション を設計しておくと、問題時に切り戻せます。移行ツールは要件で選び（同種は最小停止が容易、異種は変換を要す）、検証と本番カットオーバーを計画します。「異種移行＝DDL/DML 変換」「切り戻しの保険＝リバースレプリケーション」を押さえます。
「要件 → 戦略」が頻出。例：「業務を止めずに移行」＝ゼロ/ニアゼロダウンタイム（継続レプリケーション→カットオーバー）、「失敗時に移行元へ戻す」＝フォールバック/リバースレプリケーション、「異なる DB エンジンへ移行」＝DDL/DML 変換、「計画停止で一括移行」＝長時間停止戦略。
混同に注意：
①ゼロ/ニアゼロダウンタイム（継続レプリケーション）と長時間停止を要件で選ぶ。
②異種移行は DDL/DML 変換が要る（同種より複雑）。
③移行は検証とフォールバックまで計画する（切替して終わりではない）。
3.1.3この節のまとめ
- 移行戦略＝ゼロ/ニアゼロ停止（継続レプリケーション）/長時間停止を許容停止で選ぶ
- 異種移行は DDL/DML 変換、切り戻しはフォールバック/リバースレプリケーション
- 検証と本番カットオーバーまで計画する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 業務をできるだけ止めずにデータベースを移行したい。最適な戦略はどれですか？
Q2. 移行が失敗したときに移行元へ戻せるようにしたい。設計すべきものはどれですか？
Q3. 異なる DB エンジンへ移行する際に必要となる作業はどれですか？
Q4. 計画的に長時間止めて一括で移行できる場合に適した戦略はどれですか？
Q5. 移行計画で「切替して終わり」にしないために含めるべきものはどれですか？
Q6. ゼロ/ニアゼロダウンタイム移行を支える中心的な仕組みはどれですか？