リードレプリカを管理する

このページでは、リードレプリカの管理方法について説明します。ここでは、レプリケーションの無効化と有効化、レプリカの昇格、並列レプリケーションの構成、レプリケーション ステータスの確認について説明します。

レプリケーションの仕組みについて詳しくは、Cloud SQL のレプリケーションをご覧ください。

このページは、Cloud SQL インスタンスのレプリカを対象としています。外部サブスクライバーのパブリッシャーとして機能する Cloud SQL インスタンスを設定するには、外部レプリカを構成するをご覧ください。

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

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

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

レプリケーションを無効にする手順は次のとおりです。

Console

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

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

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

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

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

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

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

リクエストの本文(JSON):

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

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

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

REST v1beta4

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

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

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

HTTP メソッドと URL:

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

リクエストの本文(JSON):

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

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

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

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

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

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

Console

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

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

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

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

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

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

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

リクエストの本文(JSON):

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

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

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

REST v1beta4

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

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

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

HTTP メソッドと URL:

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

リクエストの本文(JSON):

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

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

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

レプリカを昇格させる

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

昇格後のリードレプリカはバックアップで自動的に構成されますが、高可用性(HA)インスタンスとしては自動的に構成されません。レプリカ以外のインスタンスの場合と同様に、レプリカの昇格後に高可用性を有効にできます。高可用性用にリードレプリカを構成する方法は、プライマリ インスタンスの場合と同じです。インスタンスの高可用性構成の詳細をご確認ください。

リードレプリカを昇格させる前に、プライマリが現在も使用可能であり、クライアントを処理する場合は、次のことを行う必要があります。

  1. プライマリ インスタンスへの書き込みをすべて停止します。
  2. レプリカのレプリケーション ステータスを確認します。これを行う 1 つの方法として、SQL Server Management Studio(SSMS)の Always On 可用性グループ ダッシュボードを使用する方法があります。
  3. レプリカがレプリケーションされていることを確認し、レプリケーション ラグを確認します(たとえば、seconds_behind_master 指標によって報告されたようになっているか確認します)。

それ以外の場合は、新しく昇格したインスタンスに、プライマリ インスタンスに commit されたトランザクションの一部が存在しない可能性があります。

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

Console

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

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

gcloud

gcloud sql instances promote-replica REPLICA_NAME
  

REST v1

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

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

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

HTTP メソッドと URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

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

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

REST v1beta4

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

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

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

HTTP メソッドと URL:

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

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

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

昇格したインスタンスが正しく構成されていることを確認します。具体的には、必要に応じて高可用性対応のインスタンスを構成することを検討してください。

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

現在、レプリケーション ステータスをモニタリングするには、T-SQL クエリまたは SSMS を使用する必要があります。詳しくは以下をご覧ください。

トラブルシューティング

問題 トラブルシューティング
作成時にリードレプリカがレプリケーションを開始しなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。
リードレプリカを作成できない - invalidFlagValue エラー。 リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。

まず、max_connections フラグの値がプライマリの値以上であることを確認します。

max_connections フラグが適切に設定されている場合、Cloud Logging のログを調べて、実際のエラーを確認します。

リードレプリカを作成できない - 不明なエラー。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。

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

ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

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

レプリケーションが停止した。 ストレージの上限に達しており、ストレージの自動増量が有効になっていません。

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

レプリケーション ラグが常に大きい。 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

考えられる解決策は次のとおりです。

  • インスタンスを編集してレプリカのサイズを増やします。
  • データベースの負荷を軽減します。
  • リードレプリカにリード トラフィックを送信します。
  • テーブルをインデックスに登録します。
  • 遅い書き込みクエリを特定して修正します。
  • レプリカを再作成します。
レプリカの作成がタイムアウトで失敗する。 プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

実行中のクエリをすべて停止してからレプリカを再作成します。

次のステップ