レプリカの管理

このページでは、リードレプリカのレプリケーションを有効または無効にする方法、レプリカをスタンドアロンのインスタンスに昇格する方法、レプリカを削除する方法を説明します。リードレプリカの使用方法については、Cloud SQL でのレプリケーションをご覧ください。

レプリケーションの無効化

デフォルトでは、レプリカのレプリケーションは有効に設定されています。ただし、レプリケーションを無効にできます。たとえば、デバッグの実行時や、インスタンスの状態を分析する場合などです。準備が完了したら、レプリケーションを明示的に再び有効にします。レプリケーションを無効または再び有効にすると、レプリカが再起動されます。

レプリケーションを無効にしてもレプリカのインスタンスは停止されませんが、読み取り専用のインスタンスになり、プライマリ インスタンスからのレプリケーションは実行されなくなります。このインスタンスには引き続き課金されます。無効化されたレプリカでレプリケーションを再度有効にできます。また、レプリカの削除や、レプリカのスタンドアロン インスタンスへのプロモートを行うこともできます。レプリカを停止することはできません。

レプリケーションを無効にするには:

Console

  1. Google Cloud Console の Cloud SQL インスタンス ページに移動します。

    [Cloud SQL インスタンス] ページに移動

  2. レプリカ インスタンスの名前をクリックして開きます。
  3. ボタンバーの [レプリケーションを無効にする] をクリックします。
  4. [OK] をクリックします。

gcloud

gcloud sql instances patch [REPLICA_NAME] --no-enable-database-replication

REST v1beta4

コマンドライン プロンプトでこの cURL コマンドを実行するには、gcloud auth print-access-token コマンドを使用してアクセス トークンを取得します。インスタンス: patch ページの API Explorer を使用して REST API リクエストを送信することもできます。

後述のリクエストのデータを使用する前に、次のように置き換えます。

  • project-id: プロジェクト ID
  • replica-name: レプリカ インスタンスの名前

HTTP メソッドと URL:

PATCH https://www.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON 本文のリクエスト:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

レプリケーションの有効化

レプリカが長期間レプリケーションされていないと、プライマリ インスタンスとの同期に長時間かかります。この場合は、レプリカを削除し、新しいレプリカを作成します。

レプリケーションを有効にするには:

Console

  1. Google Cloud Console の Cloud SQL インスタンス ページに移動します。

    [Cloud SQL インスタンス] ページに移動

  2. レプリカ インスタンスの名前をクリックして選択します。
  3. ボタンバーの [レプリケーションを有効にする] をクリックします。
  4. [OK] をクリックします。

gcloud

gcloud sql instances patch [REPLICA_NAME] --enable-database-replication

REST v1beta4

コマンドライン プロンプトでこの cURL コマンドを実行するには、gcloud auth print-access-token コマンドを使用してアクセス トークンを取得します。インスタンス: patch ページの API Explorer を使用して REST API リクエストを送信することもできます。

後述のリクエストのデータを使用する前に、次のように置き換えます。

  • project-id: プロジェクト ID
  • replica-name: レプリカ インスタンスの名前

HTTP メソッドと URL:

PATCH https://www.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON 本文のリクエスト:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

レプリカの昇格

リードレプリカを昇格させると、レプリケーションが停止し、インスタンスは読み取りと書き込みが可能なスタンドアロン Cloud SQL プライマリ インスタンスに変換されます。この操作は元に戻せません。

プライマリ インスタンスがまだ使用可能で、クライアントにサービスを提供している場合は、リードレプリカを昇格させる前に、プライマリ インスタンスへの書き込みをすべて停止し、レプリカのレプリケーションのステータスを確認する必要があります([MySQL クライアント] タブの手順に沿ってください)。レプリカがレプリケーションされていることを確認し、Seconds_Behind_Master 指標によってレポートされるレプリケーション ラグが 0 になるまで待つ必要があります。それ以外の場合は、新しく昇格したインスタンスに、プライマリ インスタンスに commit されたトランザクションの一部が存在しない可能性があります。

スタンドアロンのインスタンスにレプリカを昇格させる手順は次のとおりです。

Console

  1. Google Cloud Console の Cloud SQL インスタンス ページに移動します。

    [Cloud SQL インスタンス] ページに移動

  2. レプリカ インスタンスの名前をクリックして選択します。
  3. ボタンバーの [レプリカをプロモート] をクリックします。
  4. [OK] をクリックします。

gcloud

gcloud sql instances promote-replica [REPLICA_NAME]
  

REST v1beta4

コマンドライン プロンプトでこの cURL コマンドを実行するには、gcloud auth print-access-token コマンドを使用してアクセス トークンを取得します。Instances:promoteReplica ページの API Explorer を使用して REST API リクエストを送信することもできます。

後述のリクエストのデータを使用する前に、次のように置き換えます。

  • project-id: プロジェクト ID
  • replica-name: レプリカ インスタンスの名前

HTTP メソッドと URL:

POST https://www.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

プロモートしたインスタンスが正しく構成されていることを確認します。具体的には、自動バックアップを有効にします。また、必要に応じて高可用性対応のインスタンスを構成することを検討してください。

レプリケーションのステータスの確認

管理クライアントを使用して個々のレプリカ インスタンスにログインすると、ステータスや指標を含むレプリケーションの詳細を取得できます。Google Cloud Console または gcloud コマンドライン ツールを使用すると、レプリケーションの概要を取得できます。

注: Cloud SQL の外部にプライマリ インスタンスがあるレプリカの場合、Google Cloud Console ではレプリケーションのステータスを確認できません。

レプリケーションのステータスを確認するには:

Console

  1. Google Cloud Console の Cloud SQL インスタンス ページに移動します。

    [Cloud SQL インスタンス] ページに移動

  2. レプリカ インスタンスの名前をクリックして選択します。
  3. レプリケーションのステータスが、ページ上部のバナーに表示されます。

gcloud

レプリカ インスタンスの場合、以下のようにしてレプリケーションのステータスを確認します。

gcloud sql instances describe [REPLICA_NAME]

出力内で、databaseReplicationEnabledmasterInstanceName プロパティを見つけます。

プライマリ インスタンスの場合、以下のようにしてレプリカがあるかどうかを確認します。

gcloud sql instances describe [PRIMARY_INSTANCE_NAME]

出力内で、replicaNames プロパティを見つけます。

MySQL クライアント

  1. MySQL クライアントを使用してレプリカに接続します。

    詳しくは、外部アプリケーションのための接続オプションをご覧ください。

  2. レプリカのステータスを確認します。
    SHOW SLAVE STATUS \G
  3. コマンドの出力で、次の指標を見つけます。
    • Master_Host: プライマリ インスタンスの名前。
    • Slave_IO_Running: プライマリ インスタンスからの読み取り用の I/O スレッドが実行されているかどうかを示します。レプリケーションが開始されている場合、値は Yes になります。
    • Slave_SQL_Running: リレーログのイベントを実行するための SQL スレッドが実行されているかどうかを示します。レプリケーションが開始されている場合、値は Yes になります。
    • Seconds_Behind_Master: レプリカの SQL スレッドの処理がプライマリ インスタンスよりも遅れている秒数。値は、O または小さい秒数です。

    コマンドからの出力の詳細については、レプリケーションのステータスの確認をご覧ください。

トラブルシューティング

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
リードレプリカの作成時にレプリケーションが開始されなかった。 バイナリ ロギングを有効にした後に、少なくとも 1 つのバックアップが作成されている必要があります。 バイナリログを有効にした後、少なくとも 1 つのバックアップが作成されるまで待ちます
リードレプリカを作成できない - 不明なエラー。 多くの根本原因が考えられます。 ログで詳細を確認します
ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。 プライマリ インスタンスをより大きなディスクサイズにアップグレードします
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは、頻繁にリクエストされる読み取りオペレーションをキャッシュに保存できます。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。
レプリケーションが停止しました。 保存容量の上限に達しましたが、保存容量の自動増加が有効になっていません。 ストレージの自動増量を有効にします
レプリケーション ラグが常に大きい。 多くの根本原因が考えられます。 こちらをご確認ください。

リードレプリカの作成時にレプリケーションが開始されなかった

リードレプリカの作成時にレプリケーションが開始されませんでした。

次のような問題が考えられます

プライマリ インスタンスには少なくとも 1 週間分の binlog が必要です。存在しない場合、レプリカは複製を開始できません。

次の方法をお試しください

binlog が十分な数になるまで待ちます。


リードレプリカを作成できない - 不明なエラー

リードレプリカを作成できません - unknown error

次のような問題が考えられます

ログファイルに、より具体的なエラーが表示される可能性があります。

次の方法をお試しください

Cloud Logging のログを調べて、実際のエラーを確認します。エラーが set Service Networking service account as servicenetworking.serviceAgent role on consumer project の場合は、Service Networking API を無効にしてから再度有効にします。 この措置で、プロセスを続行するために必要なサービス アカウントが作成されます。


ディスクに空きがない

UPDATE_DISK_SIZE エラーまたは mysqld: disk is full エラー。

次のような問題が考えられます

レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。

次の方法をお試しください

プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。


レプリカ インスタンスのメモリ使用量が多すぎる

レプリカ インスタンスのメモリ使用量が多すぎます。

次のような問題が考えられます

レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュするため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

次の方法をお試しください

レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。


レプリケーションが停止した

レプリケーションが停止しました。

次のような問題が考えられます

保存容量の上限(>automatic storage increase is disabled)に達しました。

次の方法をお試しください

インスタンスを編集して automatic storage increase を有効にします。


レプリケーション ラグが常に大きい

レプリケーション ラグが常に大きい。

次のような問題が考えられます

書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。

  • レプリカのクエリが遅い。この状態は、log_slow_slave_statements を有効にして修正することで検出できます。
  • すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

次の方法をお試しください

考えられるソリューションは次のとおりです。

  • インスタンスを編集して、レプリカのサイズを増やす。
  • データベースの負荷を軽減します。
  • テーブルをインデックスに登録します。
  • 遅いクエリを特定して修正します。
  • レプリカを再作成します。

次のステップ