MySQL から Cloud SQL への移行

このドキュメントでは、パーティション分割されていない MySQL 5.7 データベースを、Google Cloud のフルマネージド データベース サービスである Cloud SQL に移行するプロセスを計画および実行する方法について説明します。このドキュメントは、MySQL データベースがあり、一般に MySQL と Google Cloud のコンセプトに精通していることを前提としています。

このドキュメントで説明するコンセプトは、MySQL の他のバージョンと、人気のある MySQL のオープンソース フォークである MariaDB に適用されます。ただし、MySQL 5.7 以外のバージョンの場合、プロセスの若干の修正が必要となる場合があります。データベース移行の計画に使用できるサードパーティ ツールと Cloud SQL パートナーが多数あります。このドキュメントでは、ネイティブの MySQL および Google Cloud 機能についてのみ説明し、追加のツールやパートナーについては説明しません。

コンパニオン チュートリアルでは、このドキュメントで説明する移行プロセスのいずれかを順を追って説明します。

概要

MySQL データベースを別の環境に移行するには、次の 2 つの要素を移動する必要があります。

  • データベース内のデータ。これは、データベースのストレージ レイヤです。
  • ストレージ層への一貫した読み取りと書き込みを処理する管理システム。これは管理レイヤです。

課題は、データベースが機能するためにこれらの要素が常に同期している必要があることです。小さなデータベースでさえ、毎秒数千のリクエストを受け取る可能性があります。ストレージ レイヤと管理レイヤの間のトランザクションの遅延やネットワークの問題は、データベース、依存アプリケーション、ユーザーの満足度に悪影響を及ぼします。

移行方法

MySQL には、Cloud SQL への移行に役立つ 2 つの機能があります。これらの機能は、MySQL データベースを移行するための 2 つの戦略、すなわちエクスポート / インポート移行と外部レプリカ プロモーション移行を行う際の基本となります。

エクスポート / インポート移行

エクスポート / インポート戦略では、MySQL mysqldump コマンドを使用して、ソース データベース ストレージ レイヤのすべてのデータをエクスポートします。次に、このデータを新しいデータベース管理レイヤに直接インポートします。これには通常、すべてのデータの同期を維持するために、移行期間の全体を通じてデータベースにダウンタイムが必要です。

外部レプリカ プロモーションの移行

外部レプリカ プロモーションの移行戦略では、外部データベースのレプリカを作成し、既存のデータをそのレプリカに同期します。これは、既存のデータベースに対して、最小のダウンタイムで行われます。

レプリカ データベースがある場合、2 つのデータベースには異なる役割があります。このドキュメントでは、これらの役割をプライマリとレプリカと呼んでいます。

データを同期した後、データベースの稼働時間への影響を最小限に抑えて管理レイヤを移動するために、レプリカをプライマリに昇格させます。

Cloud SQL で外部レプリカのプロモーションを達成する簡単な方法は、自動移行ワークフローを使用することです。このプロセスは、このタイプの移行に必要な多くのステップを自動化します。

移行のための MySQL データベースの準備

移行手順を実行する前に、データベースがいずれかのオプションに対応していることを確認する必要があります。MySQL はいくつかのデフォルト構成でインストールされ、アプリケーションの要件に応じて調整およびカスタマイズできます。移行を開始する前に、MySQL がこのセクションの説明に従って構成されていることを確認してください。これにより、移行失敗のリスクを軽減し、ダウンタイムを制限できます。

論理バックアップを実行する

どちらの移行方法でも、MySQL データベースに変更を加えることになります。データベース内のデータを保護するには、移行アクションを実行する前に、MySQL mysqldump コマンドを使用して、バックアップとして保持するデータ エクスポートを作成する必要があります。このバックアップは、両方の移行方法で開始点として使用されます。

mysqldump コマンドは、データベース内のすべてのデータのスナップショットを取得します。データベースのサイズに応じて、このプロセスには 1 秒未満から数時間かかる場合があります。スナップショットの作成後にデータが変更された場合、それらの変更は最終スナップショットにキャプチャされません。外部レプリカ プロモーションの移行プロセスを使用している場合、これは問題になりません。ただし、エクスポート / インポート移行プロセスでは、これによりデータの不整合やデータの損失が発生する可能性があります。

完全なバックアップを安全な場所に保存します。オプションには、クラウド ストレージ、ローカル オブジェクトのストレージ システム、オフサイト バックアップが含まれます。

ベンチマーク データベース パフォーマンス指標

移行を開始する前に、既存のアプリケーションとデータベースのパフォーマンス ベンチマークの完全なコレクションが必要です。これにより、予想される動作と現在のパフォーマンス指標を理解できます。

持っているベンチマークが、アプリとデータベースのユースケースを表していることを確認してください。後で、ベンチマークを使用して、移行されたデータベースのパフォーマンスを比較する場合、古いデータベースと新しいデータベースのデプロイを有意に比較できるようにする必要があります。

接続オプションを決定する

ネットワーク接続要件は、移行戦略ごとに異なります。使用できる方法を決定するうえで役立つ最も重要な質問は、パブリック IPv4 アドレスを使用してデータベースにアクセスできるかどうかです。

Cloud SQL 自動移行ワークフローを使用して外部レプリカ プロモーション移行を実行する場合、IPv4 アドレスを使用して既存のデータベースにパブリックにアクセスできる必要があります。Cloud SQL の移行先データベースには、プロモーションまたは移行プロセス全体を通して永続的なネットワーク接続が必要です。データベースのサイズによっては、これは長時間かかる場合があります。

宛先データベースの接続オプションも検討する必要があります。Cloud SQL はプライベート IP アドレスを使用できます。パブリック IP 接続を使用するように構成することもできます。

ルート パスワードを決定する

移行中に、多くの特権付き MySQL コマンドとタスクを実行します。したがって、MySQL root ユーザーへのアクセス権、または SUPER および GRANT 権限を持つアカウントへのアクセス権が必要です。これらの特権付きアカウントのいずれかのユーザー名とパスワードがわからない場合は、データベース管理者に相談するか、MySQL パスワード リセット手順に従う必要があります。

テスト移行を実行してランブックを作成する

本番環境への移行を実行する前に、テスト移行を実行する必要があります。そうすることで、手順を確認し、メソッドに自信を持ち、移行に必要な時間を予測できます。この経験から学んだ教訓を使用して、移行をサポートするランブックを生成できます。ランブックを作業ドキュメントとして使用して、移行の調整、トラブルシューティング、実行をサポートします。

このドキュメントは、データベース移行時のランブックを作成するための入門書として役立ちます。

データベース移行のためのアプリケーションを準備する

最後の準備手順は、移行のためのアプリケーションを準備することです。アプリケーションからデータベースへのすべての接続方法の説明は、このドキュメントの範囲外です。ただし、IP アドレスとドメイン ネーム システム(DNS)接続がアプリケーションに与える影響を理解することが重要です。

パブリック DNS または内部 DNS を使用することは、データベースにアクセスする一般的な方法です。DNS を使用すると、アプリケーション コードを更新することなく、宛先データベースの基になる IP アドレスを変更できます。アプリケーションがデータベース接続のために DNS レコードに依存している場合、通常、移行のためにそれらの DNS レコードの DNS 生存期間(TTL)値を小さくする必要があります。

DNS TTL 値は秒単位で測定され、クライアントまたはホストに保存されている DNS レコードの有効性を表します。この時間は、DNS キャッシュ ウィンドウとも呼ばれます。デフォルトの DNS TTL 値は、DNS プロバイダごとに異なります。たとえば、Cloud DNS はデフォルトで TTL を 5 分(300 秒)に設定します。データベースの DNS エントリはめったに変更されないため、DNS 管理者がこれを非常に高く設定している場合があります。

データベースを移行するときに、DNS TTL が高い場合、クライアントに DNS 値がキャッシュされていると、データベースのダウンタイムが長くなる可能性があります。TTL 値を下げると、クライアントは更新されたレコードをより頻繁にチェックするようになります。このアクションは、データベースのダウンタイムを最小限に抑えるのに役立ちます。

データベースの DNS レコードを変更することを見込んで、この番号を可能な限り最小の構成可能な値に設定する必要があります。DNS プロバイダが SaaS ベースの場合、これはコストの増加につながる可能性があります。この変更を行う前に、必ずプロバイダまたは管理者に確認してください。

エクスポート / インポート移行

エクスポート / インポート移行戦略では、MySQL mysqldump コマンドに依存して、移行元の環境のデータベースから論理スナップショットをエクスポートします。次に、スナップショットを移行先の環境のデータベースにインポートします。

この方法の単純さは、データベースが移行中にダウンタイムを経験するという事実によって相殺されます。トランザクションは大規模なデータベースで継続的に発生するため、管理者は通常、次のことを行います。

  1. ソース データベースの新しいデータを書き込む機能を無効にします。
  2. ソース データベースからスナップショットを作成します。
  3. スナップショットを宛先データベースにインポートします。
  4. 新しいデータベースを指すようにアプリケーション構成を更新します。
  5. 新しいデータベースのパフォーマンスを確認します。

次の図は、このシーケンスを示しています。

オンプレミスの MySQL データベースから Cloud Storage へのファイル エクスポート、Cloud SQL で実行されている MySQL への移行のシーケンス

このシーケンスにより、ソース データベースの書き込みを停止してから新しいデータベースへの書き込みを開始するまでの間に、データの変更されないことが保証されます。データのサイズによっては、このプロセスによりアプリケーションのダウンタイムが長くなる可能性があります。これは、多くのビジネスおよびアプリケーションでは受け入れられないことがよくあります。

エクスポート / インポート移行戦略を使用する場合、データベースは Cloud SQL への外部接続を必要としません。ただし、Cloud SQL からアクセスできる場所に mysqldump ファイルをエクスポートできるようにする必要があります。mysqldump ファイルのサイズによっては、このデータのインポート / エクスポート プロセスに時間がかかり、すべてのデータ行とすべてのトランザクション情報が正しくコピーされることを保証するために、複雑なファイルコピーおよび検証技術が必要になる場合があります。

さらに、組織のデータ分類ルールによっては、mysqldump ファイルを他の場所に保存できない可能性もあります。データを保存する方法を選択する前に、これらのルールを必ず確認してください。

エクスポート / インポート移行の手順

次のセクションでは、シーケンス全体の各ステップについて詳しく説明します。

書き込みを無効にする

管理者は、書き込み操作を防止するようにデータベースを構成します。これは、データベースのロックまたはフリーズとも呼ばれます。これが完了すると、データベースに送信された書き込みトランザクションはすべて失敗します。ただし、データベースまたはレプリカに対する読み取りトランザクションは、引き続き正常に機能します。次の手順に進む前に、この動作を確認するためにいくつかのテストクエリを実行する必要があります。

データベースをロックするとどのアプリケーションが影響を受ける可能性があるかを理解してください。大規模なシステム障害を防ぐために、データベースに依存しているユーザー、顧客、管理者、およびその他の部門への通知が必要となる場合があります。

データのエクスポート

データベースがロックされた後、データの完全なエクスポートを生成するために、古いデータベースで mysqldump コマンドを実行します。エクスポート プロセスが完了したら、このファイルを新しいデータベースからアクセスできる場所に移動する必要があります。

本番環境データベースを含むドライブとは別の物理ドライブにバックアップ ファイルを送信してください。この分離により、ディスク I/O の競合が減少し、バックアップの速度が向上します。メインドライブから書き込みの負荷を取り除くことにより、本番環境データベースのオペレーションへの影響が減少します。また、この分離により、本番環境データベースを含むディスクのスペースが不足する可能性が低くなります。

mysqldump コマンドの出力を圧縮すると、バックアップに必要な書き込みの総数を減らすこともできます。圧縮には CPU リソースの増加が必要になる可能性があるため、これがデータベース管理レイヤのパフォーマンスにどのように影響するかを確認してください。

詳細については、Cloud SQL にインポートするデータをエクスポートするをご覧ください。

データのインポート

新しいデータベースは、古いデータベースからダンプファイルをインポートする必要があります。インポート プロセスにより、データベース テーブルと古いデータベースのすべての行が再作成されます。インポートに必要な時間は、同様のシステム リソースが与えられた場合、エクスポートにかかった時間に匹敵します。移行の一環としてシステム リソースをアップグレードする場合、インポート プロセスはエクスポートよりも高速になる可能性があります。

詳細については、Cloud SQL にデータをインポートするをご覧ください。

データをインポートしたら、ソース データベースのテストから得たベンチマーク パフォーマンス情報を確認する必要があります。その後、新しいデータベースに対して本番環境でのクエリを読み取りベースで実行して、新しいデータベースがアプリケーションのパフォーマンス ニーズを満たしていることを確認できます。

アプリケーションを更新する

新しいデータベースの使用を開始する準備ができたら、新しいデータベースをサポートするようにアプリケーションを更新する必要があります。このタスクを実行するには、いくつかの方法があります。

  • アプリケーションのソースコードで直接定義されたデータベース エンドポイントまたは IP アドレスがある場合は、コードを更新し、データベースにアクセスする必要があるすべてのアプリケーションにこの更新を展開します。
  • アプリケーションがデータベースにアクセスするために DNS レコードを指す場合、DNS プロバイダを介して DNS レコードを更新し、新しいデータベース エンドポイント アドレスを反映します。
  • アプリケーションがデータベースにアクセスするためにロードバランサを指す場合は、新しいデータベース エンドポイントをロードバランサに登録します。

アプリケーションをカットオーバーして Cloud SQL を使用する場合、バッファプールをウォームアップできます。これにより、データベースがデータをメモリに保存する前にアプリケーションで発生する可能性のあるクエリのレイテンシを最小限に抑えることができます。ソースとなる本番環境データベースの MySQL スロー クエリログを使用して、新しいインスタンスのキャッシュに保存するすべての SELECT ステートメントを実行するスクリプトを作成できます。書き込みを有効にする直前にこれを行う必要があります。

バッファプールのウォームアップに役立つサードパーティのツールとパートナーが多数あります。

書き込みを有効にする

更新されたアプリケーション コードが新しいデータベースと通信できることを確認したら、新しいデータベースの読み取り専用ロックを削除する必要があります。そのステップの後、アプリケーションを介してデータベースが適切に機能することを検証できます。また、データベースのパフォーマンスがアプリケーションのニーズを満たしていることを確認するために、ベンチマーク テストの別のラウンドを実行する必要があります。

検証が完了し、両方のデータベース間ですべてのデータで整合性が保てていると判断したら、いくつかのクリーンアップ タスクを完了できます。

  • ダウンタイムが終了したことをユーザーに通知します。
  • ステータス ページを更新し、アプリケーションからステータス メッセージを削除します。
  • 変更された DNS TTL を元の値に戻します。

エクスポート / インポート移行のインポート時間を最適化するための推奨プラクティス

mysqldump ファイルのインポート速度を最適化するためにできることがいくつかあります。これにより、サーバーが読み取り専用状態でなければならない合計時間を減らすことができます。

  • スキーマを最適化します。外部キーを避けるためにデータを構造化します。可能であれば、主キーの順序でデータをエクスポートします。
  • リソースを最適化します。可能であれば、データセット全体をサポートするのに十分な RAM を備えた新しいデータベースを起動します。さらに、データベース ストレージに SSD を使用すると、データ スループットが大幅に向上します。SSD では、メカニカル ディスクよりも 1 秒あたりの入出力操作(IOPS)が多くなります。Google Cloud SSD では、ディスクサイズが増加すると IOPS も増加します。つまり、ディスクが増加することで追加のコストがかかり、プロビジョニングされる容量も過剰になりますが、追加の IOPS も得られるということです。
  • モニタリングを最適化します。古いデータベースまたは新しいデータベースの問題を検出するための堅牢なモニタリング ソリューションを導入することは、移行に非常に役立ちます。たとえば、Cloud MonitoringMySQL プラグインを使用できます。モニタリングにより、問題の早期検出、通常のデータベース動作の特定、新しいデータベースと以前のデータベース ベースラインとの比較を行えます。

大規模データベースのエクスポートとインポート

mysqldump プロセスは、10 GB 未満のデータベースで迅速に機能します。10 GB を超えるデータベースをインポートするには、高度な戦略を使用して、最終的なカットオーバー中に発生するデータベースのダウンタイムを最小限に抑える必要があります。

サブセクションのスキーマとデータをエクスポートする

1 つの戦略は、第 2 キーを使わすに、データベース スキーマとデータをセクションにエクスポートすることです。これにより、移行の最後に ALTER TABLE ステートメントを使用して第 2 キーを追加できます。このアプローチを使用すると、キーの関係に基づいて、さまざまなテーブルセットをさまざまなファイルにエクスポートできます。その後、Compute Engine インスタンスから MySQL インポート プロセスを並行して実行できます。並列インポートのためにデータをエクスポートする 1 つの方法は、エクスポート ファイル自体を手動で編集することです。ただし、これには時間がかかり、エラーが発生しやすくなります。

タイムスタンプを活用する

いずれかのテーブルがタイムスタンプ列を使用している場合、WHERE 句を指定できる mysqldump コマンドの機能を使用できます。これにより、タイムスタンプ付きのデータを複数のインポートで Cloud SQL に読み込むことができます。

最終的な移行カットオーバーの準備ができたら、この手法を使用して、最後のエクスポート以降に変更されたソース データベース内の行のみをエクスポートできます。タイムスタンプ付きのテーブルがなく、ソース データベース内のテーブルにタイムスタンプ列を導入することに問題がない場合は、各ソーステーブルに MySQL トリガーを追加して、行が変更されるたびにタイムスタンプを設定できます。

この方法で懸念すべきは、削除された行の追跡です。タイムスタンプ列では、INSERT または UPDATE ステートメントによる変更で行が削除され、テーブルから行が取り除かれたものだけが追跡されます。したがって、タイムスタンプを使用して最初の移行後に削除された行を検出できるのは、アプリケーションとデータベースがソフト削除メカニズムを使用するように構築されている場合のみです。この場合には、DELETE ステートメントを実行するのではなく、is_deleted 列を true に設定することで行が削除されたことを示します。もしくは、実際のそれぞれのテーブルで削除された行を追跡するテーブルを作成し、その削除追跡テーブルに削除された行を挿入して on_delete トリガーと照合する方法もあります。移行の最終段階で、必要な DELETE ステートメントを作成して、Cloud SQL インスタンスからそれらの行を削除できます。

エクスポート ファイルの検証

エクスポート ファイルを手動で変更する場合、または異なるテーブルのエクスポートを取得する場合は、データが正確にエクスポートされたことを確認する必要があります。

エクスポート ファイルの比較

エクスポートされたデータを検証する 1 つの方法は、アイドルテスト データベースを実装することです。本番環境の最新のバックアップを新しいスタンドアロン データベース インスタンスに復元することにより、アイドルテスト データベースを作成できます。次に、mysqldump ファイルを新しいアイドルテスト データベースに復元します。次に、マルチフェーズの mysqldump プロシージャをテストし、それをさらに別のアイドルテスト データベースに並行して復元できます。これにより、データベースの同一のコピーが 2 つできるはずです。その後、2 つのアイドルテスト データベースで mysqldump コマンドを実行し、diff コマンドまたはファイル比較ツールを使用して 3 つすべてを比較することにより、データを検証できます。

次の図は、このシーケンスを示し、プロセス中に作成されたアーティファクトを示しています。

エクスポート ファイルを検証するためのシーケンスとアーティファクト

外部レプリカのプロモーション

MySQL データベースを移行する 2 番目のオプションは、外部レプリカ プロモーションを使用することです。この戦略では、レプリカ データベースを作成し、既存のデータベースをプライマリとして設定します。2 つのデータベースが同期するまで待ってから、MySQL レプリカ データベースをプライマリに昇格させます。このプロセスにより、データベースの移行に関連するデータベースのダウンタイムが最小限に抑えられます。

要件

外部レプリカのプロモーションによる移行方法を使用するには、レプリケーション ユーザーの作成と GTID レプリケーションの有効化という 2 つの追加の前提条件が必要です。

レプリケーション ユーザーを確立する

バージョン 5.7(このドキュメントの例に使用)を含む MySQL の特定のバージョンは、プライマリ データベースのログに、レプリケーションに使用されるユーザー アカウントのユーザー名とパスワードをクリアテキストで保存します。root ユーザー カウントを使用してレプリケーションを実行する場合、プレーン テキストログに root パスワードを保存します。したがって、レプリケーションに root ユーザーを使用すると、セキュリティ上のリスクが生じます。

データベースの他の側面を危険にさらす可能性を制限するには、レプリケーションを実行するためのアカウントを完全に別個に作成する必要があります。新しいアカウントには、レプリケーション プロセスに必要な特権のみが必要です。このアカウントは、プライマリ データベースの IP アドレスからのみ複製できるように制限する必要もあります。

GTID を構成する

外部レプリカのプロモーションによる移行を実行するには、ソース データベースで GTID レプリケーションが有効になっている必要があります。ソース データベースでレプリケーションを構成していない場合、GTID レプリケーションが有効になっていない可能性があります。

グローバル トランザクション識別子(GTID)は、プライマリ データベース サーバーで commit された各トランザクションに関連付けられた一意の識別子です。これらの識別子は、レプリカとプライマリ データベース間のレプリケーション プロセスを構築するために使用されます。

Cloud SQL for MySQL の新しいインスタンスは、デフォルトで GTID レプリケーションを使用します。この機能を無効にすることはできないため、特定の SQL ステートメントとオペレーションは許可されません。詳細については、Cloud SQL と標準の MySQL 機能の違いと、GTID を使用したレプリケーションに関する MySQL の制限をご覧ください。

外部レプリカのプロモーション移行の概要

エクスポート / インポートの移行と比較して、外部レプリカのプロモーションの移行は非常に簡単です。前述のすべての前提条件を満たしている場合、Cloud SQL はこのプロセスを自動化するのに役立ちます。自動化された移行ワークフローでは、引き続きエクスポート / インポート プロセスが必要ですが、自動化の一部として手動ステップの一部が抽象化されます。

自動移行ワークフローは、次のシナリオをサポートしています。

  • オンプレミスから Cloud SQL への移行。
  • 別のクラウド プロバイダから Cloud SQL への移行。
  • ある Google Cloud プロジェクトから別の Google Cloud プロジェクトへの移行。

自動移行ワークフローでは、次のことを行います。

  1. データソースに関する詳細を提供します。
  2. Cloud SQL リードレプリカを作成します。
  3. リードレプリカとソースを同期します。
  4. Cloud SQL リードレプリカをプライマリ インスタンスに昇格させます。

データソースの詳細を提供する

Cloud SQL を使用して自動移行ワークフローを実行するとき、データソースの参照名を指定します。この名前は移行のデータを参照するために使用され、ソースの実際の名前と一致する必要はありません。

ソース データベースのパブリック IP アドレスとポートも指定します。Cloud SQL データベースが IPv4 アドレスを使用してソース データベースに直接接続していることを確認する必要があります。また、ソース データベースを保護するファイアウォールまたはセキュリティ アプライアンスが、新しい Cloud SQL データベースの IP アドレスからの接続を許可するように構成されていることを確認する必要があります。

また、MySQL レプリケーション ユーザーの資格情報と移行する MySQL のバージョンを使用して、自動移行ワークフローを提供する必要があります。これは、サーバーで認証し、次のステップで安全な転送をサポートするために必要です。必要に応じて SSL/TLS オプションを構成することもできます。

Cloud SQL リードレプリカを作成する

自動移行ワークフローを実行する場合、Google Cloud で新しい Cloud SQL インスタンスを作成するためのオプションを設定します。これにはいくつかの手順が必要です。

  • データベース インスタンス ID の設定。
  • Google Cloud リージョンとゾーンの選択。
  • インスタンス タイプの選択。
  • ディスク ストレージ タイプの選択。
  • 合計ストレージ容量の選択。ストレージの自動増量を有効にすることをおすすめします。このオプションを使用すると、必要に応じてデータベースが拡張され、ディスク領域が不足するリスクが軽減されます。

最後に、Cloud Storage に保存したスナップショットへのリンクを提供します。Cloud SQL インスタンスと同じプロジェクトにある Cloud Storage バケットに最新のエクスポート ファイルがあることを確認してください。

リードレプリカとソースの同期

移行プロセスを開始すると、新しい Cloud SQL VM が起動し、ソースから複製を開始します。同期が完了すると、データベース内のデータを比較して、レプリケーションが完了したことを確認できます。ベンチマークを開始して、アプリケーションの要件および以前に測定されたソース データベースのベースライン パフォーマンスに対して Cloud SQL データベースのパフォーマンスをテストすることもできます。

リードレプリカをプライマリ インスタンスに昇格させる

データが複製されたら、古いデータベースを読み取り専用モードにします。これにより、データベースへの書き込みが防止され、昇格プロセス中にデータが変更されないことが保証されます。次に、前述のように、Cloud SQL の新しいエンドポイントをサポートするようにアプリケーション コードまたは DNS エントリを更新します。

ソース データベースが読み取り専用モードで、アプリケーションが新しい Cloud SQL エンドポイント アドレスで更新されたら、Cloud SQL で新しいデータベース インスタンスに移動し、レプリカをプライマリ サーバーに昇格できます。このプロモーション プロセスにより、新しく昇格した Cloud SQL プライマリの書き込みが自動的に再度有効になります。

レプリカをプライマリ サーバーに昇格させた後、データベースのサイズに関係なく、データベースで数分間のダウンタイムが発生する場合があります。これは、データベースの昇格に関連するすべてのタスクと構成作業を実行するために Cloud SQL が必要とする時間です。

プロモーションが終了すると、プライマリ データベースが Cloud SQL で実行され、移行が完了します。これは、アプリケーションの要件とソース データベースのベースライン パフォーマンスに対するパフォーマンス テストの別のセットを実行する良い機会です。Cloud SQL パフォーマンス ベンチマークの新しいセットを入手したら、他のデータベース最適化を計画できます。

移行後の最適化

移行が完了したら、移行方法に関係なく、次の方法で Cloud SQL データベースを最適化できます。

  • VM を適切なサイズにします。モニタリング データを分析することにより、データベースに異なるサイズの VM を選択する必要があるかどうかを確認できます。より小さなインスタンスを使用することで、コストを削減できる場合があります。逆に、より多くのリソースを備えた大規模な VM では、データベースのパフォーマンスが向上する可能性があります。
  • 追加のインデックスを追加します。データベースが追加のインデックスやその他の最適化の恩恵を受ける可能性がある場合は、移行の完了後に追加できます。
  • 追加のトランザクション ロギングを有効にします。サーバーのロギングレベルを調べると、バイナリ ロギングまたはその他の拡張ロギング オプションを有効にすることの利点を調査できます。
  • 外部レプリカのプロモーション移行方法では、バイナリ ロギングを再度有効にし、自動バックアップを活用します(レプリカのプロモーション移行後、バイナリログがオフになっているため、Cloud SQL 自動バックアップは無効になります)。

次のステップ