データベースのシームレスな移行: GCPデータベース移行サービスを使用してMySQLをスムーズにクラウド化します

2026-05-30 阅读 19

インターネット会社の枠組みの発展の中で、最も感動的で、薄氷を踏むような任務は、決して「データベース移行」ではない。

従来のデータベース移行は、高速道路で狂暴な車にタイヤを交換するようなものです。データの整合性を保証するために、古いアプローチは通常、午前3時に停止公告を一時停止し、すべてのフロントエンド流量を切断してから使用することを選択します

mysqldump

数十GBの大きなSQLファイルをエクスポートして、ゆっくりとクラウドに転送し、インポートします。その結果、ネットワークのジッターが中断されたり、導入速度が遅すぎたりして、夜が明けてもまだ完成していないため、最後には全員の高圧の下でロールバックを余儀なくされ、研究開発チームが髪の毛を落としただけでなく会社の中核業務にも大きく影響している。

Google Cloud(GCP、Googleクラウド) の現代化の生態の中で、この行き詰まりを打ち破るために生まれた次元を下げる打撃の神器があります。

データベース移行サービス (データベース移行サービス、略称DMS)

。

その核心的な論理は非常に純粋である

完全管理、ダウンタイムゼロ、シームレスリアルタイム同期

。MySQLのネイティブのBinlogレプリケーション技術と組み合わせることで、DMSはオンライン業務で通常通りにオープンして接客すると同時に、バックグラウンドで古いデータベースのデータを流水のようにどんどんクラウドに移動することができる。両側のデータが完全に揃ったら、穏やかな午後を選んで、数秒でフロントエンドの接続文字列を軽く変更するだけで、大工場レベルの「滑らかな雲」を完成できる。

今日私たちは複雑な暗号学の公式を引っ張って、何のでたらめも拒絶しない。ハードコアの実戦から直接切り込んで、手を持ってあなたを連れて地元のMySQLからgoogleクラウドに構築します

Cloud SQL for MySQL

のシームレスな移行演習。

第一段階: 深さ分解、DMSリアルタイム移行の「二段階物理世界モデル」

コンソールに行ってマウスをクリックする前に、DMSの基礎的な物理的な運行モデルを頭の中に構築しなければならない。そうでなければ、複雑なネットワークと権限の配置に気絶される。

DMSの全量の増分リアルタイム移行は、本質的にgoogleイントラネットの基礎層に高可用性のデータ転送ルートを構築し、ライフサイクル全体を二つの核心段階に分けた。

第一段階: 在庫大皿初期化(Full Dump): 移行タスクを開始すると、DMSはソースライブラリの正常な読み書きに影響を与えずに稲妻のようにソースライブラリの現在の在庫のすべてのテーブル構造、データパッケージをクローンして、クラウドのCloud SQLターゲットライブラリに迅速に配信します。

第二段階: 増分流水追跡 (CDC/Binlogコピー): 在庫が移動した瞬間、DMSは継続的なデータ収集 (CDC) モードにシームレスに切り替わる。標準的なMySQLスレーブ (ライブラリから) になり、ソースライブラリのBinlog (バイナリログ) をじっと見つめている。オンラインユーザーが新しい注文を出し、パスワードを変更すると、DMSはミリ秒レベルでこれを

増分的に「つかむ」を修正して、クラウドのターゲットライブラリでもう一度再生します。

コアアーキテクチャの結論: この2つの段階で、あなたの古いデータベースはすべて対外営業を維持して、一秒でもダウンする必要はない。クラウドの新しいライブラリは古いライブラリの影のようで、両方のデータ時差がゼロになるまで歩いています。

第二段階: 実戦前夜 ― 自建元データベースで「通行証」を引き出す

DMSが合法的にレンガを運ぶためには、私たちはまず実家 (地元のMySQLソースライブラリ) に戻って基礎的な配置をしなければならない。

1.Binlogログを開く (リアルタイムで魂をコピーする)

ソースライブラリの

my.cnf

または

My.ini

プロファイル。次の行がコメントされておらず、パラメータが正しいことを確認します

Ini, TOML

[Mysqld]

Log-ビン = mysql-ビン

Binlog_format = ROW # はROW形式でなければなりません。DMSはこの正確さで各行のデータの変動を識別します。

Server-id = 100001 # ソースライブラリに一意のクラスタIDを指定します

Expire_logs_days = 7 # Binlogは少なくとも7日間保留し、DMSがまだ読めないうちにシステムによって自動的に削除されることを防止します。

変更したら、自分のMySQLを再起動して構成を有効にすることを覚えています。

2.DMS専属の「ジョイント」アカウントを作成する

ソースライブラリに接続し、次の大規模な工場仕様のSQLコマンドを入力して、GCP DMSのために独自のコピー権限を持つセキュリティアカウントを作成します

SQL

-- GCP _ dmsというアカウントを作成して、任意の場所 (またはGCPイントラネットセグメントを指定) から接続できるようにします

CREATE USER 'gcp _ dms' @' % 'IDENTIFIED BY' yourhardpass word 123! ';

-- 基礎的なデータ読み取りとクラスタ複製権限を付与する (大工場最小権限原則)

Grantselect、RELOAD、SHOW DATABASES、r e p r i c a t i o n c o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n a t i o n t i o n t i o n a t i o n a t

-- 権限を更新して、暗号を瞬時に有効にします

FLUSH PRIVILEGES;

第三段階: 実戦演習 ― 手でDMS移行ラインを配置する

環境の準備ができました。ログインします

GCPコンソール

、検索してアクセスする

データベースマイグレーション (データベース移行)

ページ。

手順1: 移行ジョブの作成 (Migration Job)

上部にある「移行ジョブの作成」をクリックします

ジョブ名: mysql-to-cloud sql-prod.

ソースデータベースエンジン: MySQLを選択します。

ターゲットデータベースエンジン: Cloud SQL for MySQLを選択します。

移行タイプ: 「継続」を選択することを躊躇しません。注: 「連続」を選択した場合にのみ、増分同期を持つシームレスでスムーズな移行が可能ですOne-time(一回限り) を選択すると、データの移動が完了し、ダウンタイムの切り替えができなくなります。

手順2: ソース接続プロファイルを定義する

ここでは、第二段階の実家でのパラメータをグーグルに伝えます

接続型プロファイル名: source-local-mysql.

ホスト名/IPとポート: ローカルMySQLのパブリックネットワークIPまたは専用線イントラネットIPを入力します。ポートはデフォルト3306です。

ユーザー名とパスワード: 先ほど作成したgcp _ dmsとそのパスワードを正確に入力します。

ステップ3: クラウドのターゲットライブラリを定義する

データをどこに移動しますか?DMSはここで無敵の機能を提供しています

ワンクリックでバックグラウンドで新しいCloud SQLターゲットライブラリを直接作成できます

。

新規作成するクラウドデータベースインスタンスID (cloud sql-mysql-prodなど) を入力します。

MySQLのバージョンを選択します (ソースライブラリと一致することをお勧めします (8.0など)。

地域 (asia-east1台湾など) を選択します。

クラウドのrootアカウントの強力なパスワードを設定し、マシンの仕様を選択します (たとえば、2コア4gbメモリ、本番環境では「高可用性高防御線」をチェックして、利用可能なゾーン間の2つの災害を有効にすることを覚えています)。

ステップ4: 接続性攻防戦 -- ハッカーの覗き見を断ち切る

これはピットの殻を踏みやすいところです。GoogleクラウドのDMSはどのようにしてファイアウォールを通ってあなたのローカルマシンを接続しますか?DMSは、次の3つの標準的な接続方法を提供しています

高度な推奨シナリオ: リバースSSHトンネル (Reverse SSH Tunnel):DMSはバックグラウンドで非常に軽量な中間vm仮想マシンを生成し、SSHコマンドを提供します。ローカルサーバでこのコマンドを実行するだけで、ローカルとGCPイントラネットの間に暗号化され、ファイアウォールを貫通する秘密の一方的なトンネルを作ることができます。会社のファイアウォールで世界に3306ポートを開く必要はありません。安全係数は直接いっぱいです。

代替案:IP許可リスト: GCP DMSがあなたの公式パブリックネットワークのIPアドレスを提示して、あなたのローカルルームの最外層のハードウェアファイアウォールのホワイトリストにデッドロックします。

接続性テストに合格したら、一番下のをクリックします。

「ジョブを作成して開始する (Create &

Amp; Startjob) 」

。

第四段階: 奇跡を目撃する時 ―― オンラインでリアルタイムで追いかけて究極の断流と交換する

クリックして起動すると、DMSの巨大な柔軟な分散計算力が瞬時に目覚めます。移行作業リストに戻ると、ステータスバーを見つめて、魔法のライフサイクルの進化を見てみましょう

状態はCreatingからStartingに変わり、Full dump in progressに入ります。

在庫が移動すると、ステータスは緑のCDC in progressになります。

この時、コンソールに行ってみます。

「レプリケーションラグ」

指標。在庫運搬期間中に発生した新たな変動のため、遅延は数分になる可能性があるしかし、すぐに、グーグルの強力なイントラネット帯域の火力が全開になるにつれて

レプリケーションラグは完全にゼロになります。

。

これは、今、あなたの地元の古いライブラリのすべてのデータと、googleクラウドCloud SQLの新しいライブラリのデータが到着したことを意味します

絶対的、画素レベルの完全リアルタイム同期

。

大工場級標準の「黄金切流」操作五段階法:

遅延が0秒に安定した後、私たちは業務の谷期 (例えば午後4時にユーザーの訪問が最も少ない場合) を選んで、最後の遮断をすべて変えることができる。プロセス全体はわずか10秒です

フロントエンドが一時的に読み取り専用になっています。Webアプリケーションのバックグラウンドで、またはMySQLソースライブラリでSET GLOBAL read_only = 1を実行します古いライブラリを強制的に「読み取り専用状態」にします。この動作は、切り替えの数秒以内に、新しい注文がこっそり古いライブラリに書き込まれ、両側のデータが外れることを絶対に保証するために使用されます。

最後の調査不足をじっと待っている: DMSコンソールを見つめて、5秒待って、最後のわずかなポイントが転送されているBinlogのしっぽを完全にクラウドで再生して、双方のデータが一期的に悪くないことを確認する。

「アップグレード」の大きなボタンをクリックします。GCP DMSコンソールで、一番上の「アップグレード」を思い切ってクリックします。基礎内部者: この動作は、クラウドの新しいライブラリと古いライブラリの奴隷コピー関係を瞬時に切断します。Cloud SQLターゲットライブラリは、一瞬にしてライブラリから離れ、完全に独立した読み取り可能なトップレベルのマスターライブラリ (Master) に進化します。

接続文字列の交換: バックエンドのすべてのWebアプリケーション、マイクロサービス構成のデータベース接続IPを、元の古い自己構築ライブラリIPから、新しいCloud SQLパブリックネットワーク/イントラネットIPへの変更をワンクリックで行います。

アプリケーションを再起動し、全面的に復活する: フロントエンドAppはクラウドの新しいライブラリに再接続し、読み取り専用を解除する。新しい注文はgoogleクラウドで非常に高い性能で落盤し始めた。

完璧な仕事です

戦いが終わると、クライアントはステップ1とステップ4の間だけで、非常に軽微で短い「注文できない/エラー」のヒントを体験し、サイト全体は小さな黒屋公告を掛けたことがないデータがゼロで失われ、クラウドで大勝しました。

第五段階: 多国籍データベースアーキテクチャでのピット血涙歴

この完全管理移行プログラムは、非常にエレガントに使用されています。しかし、真の企業レベルの高合併生産環境で生きていくには、最高のデータ設計者として、基礎技術の細部の違いから生まれた次の二つの見えない大きな穴を防ぐ必要があります

1. 致命的な「タイムゾーンと文字セット (Collation) 心霊乱」

多くのチームが移行した結果、オンラインで半年の古いコードが実行され、クラウドCloud SQLに接続した後、すべての中国時間、現地時間が不可解に8時間減った。あるいは、人里離れた字やEmojiの表情を含むユーザーコメントが文字化けやエラーになった。

原因の分解: ローカルに構築されたMySQLのデフォルトのタイムゾーンは、通常、ホストに付いて行きます (たとえば、システムのタイムゾーンCSTに設定されています)。GCP Cloud SQLはデフォルトでグローバルなコンプライアンスのためにその基礎となる主時間帯は強制的に国際標準時間UTCにロックされ、文字セットのデフォルトもあなたの古いライブラリと微妙に異なる可能性がある。

大工場標準ピット回避操作: DMSをクリックして移行を開始する前に、Cloud SQLの「構成変更」に行って、データベースフラグ (databaseflag) を見つけて、明示的にけっこうtime_zone = '08を追加します00 '(またはあなたのビジネスのメインタイムゾーンに合う) を選択し、文字セットを強制的にutf8mb4に揃えます。ソースカードの死の基礎パラメータが一致していることは、オンラインコードのエラーを防ぐ第一の法律である。

2. DMS移転後の「砂時計の遊休トラップ」

多くの初心者は完璧にデータベースをアップグレードし、業務がクラウドに駆け上がった後、喜んで仕事を終えて鍋物を食べに行った。その結果、月末に請求書を見ると、不可解で価格の高いDMS資源占有費が発生したことがわかった。

ハードコアの損失を止めるアドバイス: 「promotion」をクリックした後、DMSという移行作業は完全に物理的に破壊されておらず、クラウドのバックグラウンドで一時的なコンピューティングリソースとネットワークインタフェースを占領している砂時計はまだ狂ったように動いている。

正しい姿勢: クラウドの新しいライブラリが24時間スムーズに動作していることを確認し、ロールバックが不要であることを確認した後、すぐにDMSコンソールに戻って、完了した移行作業を選択する必要があります「削除」をクリックします。心配しないでください。削除作業は、あなたが進化したCloud sqlデータベースにわずかな影響を与えることはありません。それだけで、料金は完全に停止します。

まとめ

GCP Database Migration Serviceを利用してデータベースをシームレスに移行します。核心的な工業レベルの真髄は16文字にあります。

ロック設定、

トンネルが通じて、Binlogが追いかけて、進級して切ります。

。

あなたは過去の午前3時に肉体的に監視し、気をつけたワークショップ式の手作業に別れを告げた。すべてのインターネット通信、大皿データをパッケージ化し、リアルタイム状態を同期してグーグルのトップレベルの全管理安全脳がクローンする。コアのデータベース資産をクラウドの高防地盤の上に安定して、滑らかに溶接して、これこそ現代クラウドの原生時代で最も優雅で、最も本格的な設計者の通関姿勢である。