GCPデータベースはどのようにスムーズに移行されますか?データベースMigration Service (DMS) を利用して、ダウンタイムのない移行を実現します。

クラウド 2026-06-04 阅读 8
1

クラウドコンピューティングの分野では、すべての設計者と運送次元 (SRE) が徹夜で残業し、気をつけられることがある

データベース移行

多くの人が「移転庫」と聞いて、頭に浮かんだ画面は、大晦日か午前3時の業務の絶頂期を選んで、ホームページ公告「システムメンテナンス中」を保留することであるそして、急いでSQLをエクスポートしたり、ファイルを転送したり、新しいライブラリをインポートしたり、配置を修正したりします。業務停止時間は無限に長くなる。

しかし、実際には、現在のクラウドメーカーは、このような「敵を殺して千、自損八百」のハードコア引っ越し方式は流行していない。今日はgoogleクラウド (GCP) が提供する神器について話しましょう

Database Migration Service (DMS)

生産環境で泥だらけになった人として、私は今日最もわかりやすい言葉で、公式文書の眠気を感じる用語を引っ張らないDMSを利用して「ダウンタイムゼロ」のスムーズな引っ越しを実現する方法を手で教えてください。

一、核心概念: DMSの「ゼロストップ引っ越し」とは?

手を出す前に、私たちはまずその基礎的な論理を理解するのに1分かかります。DMSが「ゼロダウン」できるのは、一度にデータを捨てるのではなく、二つの段階に分けたことが核心である

Googleクラウドアカウント購入

完全初期化 (在庫データのコピー):DMSは、まずソース・データベースに存在するすべての履歴データをGCPのターゲット・ライブラリ (Cloud SQLなど) に完全にコピーします。この過程で、あなたのオンライン業務は通常通り実行され、正常な読み書きは全く影響を受けない。

増分同期 (リアルタイム追データ): 履歴データが転送されると、DMSはソースライブラリのログ (MySQLのBinlogやPostgreSQLのWALなど) を読み取ることで引っ越し期間中に新たに生成された業務データを、次々と新しいライブラリに「同期」していく。このとき、新旧2つのライブラリのデータはほぼ完全にリアルタイムで同期されている。

新旧のライブラリデータが一致しているため、昼間、業務が最ものんびりしている時に、アプリケーションのデータベース接続文字列 (Connection String) を新しいライブラリのアドレスに変更することができます。

業務中断時間は、アプリケーションを再起動し、構成を切り替える数十秒、さらには数秒にすぎない。

二、引っ越し前の「三道セキュリティ」 (準備作業)

DMSで引っ越したのは飛行機のようで、安全検査ができて、航行が半分成功した。次の3点は、移行が失敗するかどうかを直接決定します

1.ソースライブラリのログを開く (最も重要なステップ)

DMSは、増分同期を行うために、ソースライブラリのリアルタイムログを読み取る必要があります。

ソースライブラリがMySQLの場合: binlogがオンになっていて、binlog _ formatがROW、binlogに設定されていることを確認する必要があります

_ Row _imageをFULLに設定します。

ソースライブラリがPostgreSQLの場合: wal_levelをlogicalに設定し、レプリケーションSlotsを構成する必要があります。

2.インターネットがどのように通じているかを考える (接続性案)

ソースライブラリとGCPの间で安全に话せるようにする必要があります。DMSは、セキュリティと推奨度でソートされたいくつかの接続方法を提供しています:

VPC peering(VPCピア接続): ソースライブラリがGCPの別のVPCにある場合、または専用線 (Interconnect) を介して接続されている場合、これが優先され、高速で安全です。

Reverse SSH Tunnel (逆SSHトンネル): 最も一般的な民間シナリオ。ソースライブラリのネットワークに小さな仮想マシンをジャンプマシンとしてオープンし、暗号化トンネルを介してGCPを接続します。

IP許可リスト (Public IP): 最も簡単だが、最も推奨しない。ソースライブラリのパブリックネットワークIPをDMSのIP範囲に直接暴露する。テストだけでできるなら、生産環境は慎重に使う。

3.移行アカウントの作成

Google Cloudアカウントの購入

直接使わないでください

ルート

または

管理者

このような最高のアカウントは移動します。ソースライブラリに一時的な

Dms_user

、それに必要な読み取り、コピーの権限を与えるだけです (例えばMySQLの

レプリケーションCLIENT

レプリケーションスレーブ

SELECT

など)。引っ越しが終わったら、このアカウントを直接削除して、安全で優雅です。

三、実戦: DMS配置四歩

準備が終わったら、GCPコンソールに直接アクセスして検索します

データベースMigration

最初のステップ: 「Migration Job」を作成します

「作成」をクリックすると、ジョブの基本情報を入力する必要があります

ソース・データベース・タイプ: たとえば、独自のMySQL、AWS RDS、またはその他のクラウド・データベース。

ターゲット・データベース・タイプ: 通常、GCPがホストするCloud SQLまたはAlloyDBです。

移行タイプ: 「継続同期」を選択することを躊躇しません。これを選ぶだけでダウンタイムゼロ引っ越しです「一回限り (One-time) 」を選ぶと、データの転送は終了し、後続の増分同期は含まれない。

ステップ2: ソース接続の構成

ここでは、私たちが用意した「セキュリティ情報」を入力します

ソースライブラリのipアドレス、ポート、先ほど作成したdms_userアカウントとパスワードを入力します。

あなたが決めたネットワーク接続方式を選択します。

Erse SSHトンネル)。

「接続をテストする」をクリックして、プログレスバーが緑になっていることを確認します。エラーが発生した場合は、通常、ファイアウォールまたはセキュリティグループが解放されていないので、ネットワークをチェックします。

ステップ3: ターゲットライブラリの構成 (Cloud SQL)

ターゲットCloud SQLがまだ作成されていない場合、DMSはインタフェースで直接「ワンクリックで新規作成」することができます。

ソースライブラリと同じ構成 (CPU、メモリ、ストレージスペース) を選択できます。

ここでは、ついでにターゲットライブラリの高可用性 (HA) と自動バックアップをチェックして、一歩一歩到着することを強くお勧めします。

ステップ4: 検証と実行を開始する (startjob)

クリックして実行する前に、DMSは非常に強力な「事前チェック」機能を持っています。ソースライブラリのログフォーマットを自動的にチェックしますよね?権限が足りませんか?バージョンは互換性がありますか?

赤いエラーがある場合は、ヒントに基づいてソースライブラリに設定を変更しますすべて緑のフックであれば、直接クリックします

「スタート」

四、切断 (Cutover): どうやって完璧に「最後の銃」を打ちますか?

ジョブが実行されると、ステータスが

Full dump in progress

(全量エクスポート中) に続き

CDC in progress

(増分同期中)。

ステータスが入ると

CDC in progress

かつ

「同期遅延」は0に近い

新しいライブラリと古いライブラリのデータが完全に同期されていることを意味します。この時、私たちは本当の「切断」を準備することができる。

ここはゼロダウンの成否を決める真髄で、以下の手順に厳密に従ってください

1.業務の接線「読み取り専用」

接続を切り替えた数秒以内に新しいデータが書き込まれないように、まずアプリケーション層またはソースデータベースで、業務を「読み取り専用モード」に設定します。

2.DMSの最後の波のデータが平らになるのを待つ

DMSインタフェースを観察し、遅延が完全に0になるようにする。これは、ソースライブラリが読み取り専用になる前に生成された最後のいくつかのデータが、GCPの新しいライブラリにしっかりと横たわっていることを意味します。

3.DMSで「完了 (promotion) 」をクリックします

GCPコンソールで

「Promotion」

ボタン。このアクションは2つのことをします

新しい倉庫と古い倉庫の同期関係を解除します。

Google Cloudアカウントの購入

ターゲットCloud SQLを「読み取り専用の受信者」から「完全に独立して読み書きできる本番ライブラリ」に昇格する。

4.アプリケーション構成を修正し、全量オンラインにする

アプリケーションのデータベース接続を新しいCloud SQLのipアドレスに変更し、アプリケーションの読み取り専用モードをキャンセルして、サービスを再起動します。

業務をチェックして、フロント注文、バックグランド登録が正常かどうかを見てみましょう。うまくいけば、おめでとう、このスリルのあるデータベースは大きく引っ越して、使っています

家が全く感じていない状況で、円満に完成した!

五、初心者のピット避けと経験談

DMSは使いやすいですが、来た人として、いくつかの見えない大きな穴があります。

大きなテーブルにプライマリ・キーがない: ソース・ライブラリに非常に大きなテーブルがあると、プライマリ・キーが設定されていないと、DMSは増分同期 (CDC) を行う時にパフォーマンスが非常に悪くなります同期カードが死んでしまう可能性もあります。移行する前に、必ず開発者に主キーのない表を主キーに追加させます。

ネットワーク帯域幅を節約しないでください。もしあなたのソースライブラリが地元の機械室にあるなら、専用線や公衆網の帯域幅が小さすぎて、引っ越しは数日数晩移動するだけでなく、あなたの機械室の正常な業務帯域幅を爆発させる可能性がある。業務の低ピーク期に全量引っ越しを始めるか、DMSにトラフィック制限を設定することを覚えています。

タイムゾーンの問題に注意してください。Cloud SQLはデフォルトでUTCタイムゾーンです。もしあなたのソースライブラリがAsia/Shanghai (東八区) を使っているなら、移行後にアプリケーションが発見された時間は不可解に8時間少ないかもしれない。ターゲットライブラリを作成するときに、タイムゾーンパラメータ (09t_timezone) をソースライブラリとそっくりに調整したことを覚えています。

📝まとめ

GCPのデータベースMigration Service(DMS) は本質的に一つである

無料のサーバーレス (Serverless) 移行ツール

(移行中にターゲットライブラリのハードウェアとネットワーク料金を支払うだけで、DMS自体はソフトウェア料金を徴収しない)。

これはかつての高い敷居、高いリスクの “手動の人肉を倉庫に移します” を標準化、可視化のポイントマウスに変えました。

最後の一言のまとめ:

もうダウンタイムのメンテナンスの古い考え方で生産環境を振り回さないでください。DMSを利用して持続的な増分同期をして、主導権を自分の手に握って、昼にコーヒーを飲んで倉庫を移転することができて、これが現代の雲の原始的な運送の優雅な姿勢です!

cloud
← 返回新闻中心