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

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

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

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

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

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

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

コンソール

  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 レスポンスが返されます。

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

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

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

コンソール

  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. レプリカのレプリケーションのステータスを確認します（[psql Client] タブの手順を行います）。
  3. レプリカがレプリケーションされていることを確認し、replay_lag 指標によってレポートされるレプリケーション ラグが 0 になるまで待つ必要があります。

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

スタンドアロンのインスタンスにレプリカをプロモートする手順は次のとおりです。

コンソール

  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 レスポンスが返されます。

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

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

Google Cloud コンソールでレプリカ インスタンスを表示するか、管理クライアントからインスタンスにログインすると、ステータスや指標などのレプリケーションの詳細を取得できます。gcloud CLI を使用すると、レプリケーション構成の概要が表示されます。

Cloud SQL レプリカ インスタンスのレプリケーション ステータスを確認する前に、gcloud sql instances describe コマンドを使用してインスタンスのステータスを表示します。
その結果、レプリカ インスタンスに対してレプリケーションが有効になっているかどうかを確認できます。

レプリカ インスタンスで使用できる指標は次のとおりです（レプリカ以外のインスタンスを含む、すべてのインスタンスで使用可能な他の指標については、こちらをご覧ください）。

指標説明
レプリケーション状態
（cloudsql.googleapis.com/database/replication/state）

レプリケーションでプライマリからレプリカにログがストリーミングされているどうかを示します。次の値があります。

  • Running
  • Stopped
  • Error

この指標は、次の場合に Running を報告します。

  1. pg_catalog.pg_stat_wal_receiver は、ストリーミングの status を報告します。さらに
  2. pg_catalog.pg_is_wal_replay_paused() は f（false）を報告します。

詳細については、PostgreSQL リファレンス マニュアルの Statistics Collector と System Administration Function をご覧ください。
レプリケーション ラグ
（cloudsql.googleapis.com/database/replication/replica_lag）

プライマリ インスタンスの状態に対するレプリカの状態の遅れ（時間）。（1）現在の時刻と（2）現在レプリカに適用されているトランザクションをプライマリが commit したときのタイムスタンプの差です。特に、レプリカが書き込みを受信していても、レプリカがデータベースへの書き込みをまだ適用していない場合、書き込みは遅延として記録される可能性があります。

カスケード レプリカの場合、プライマリとレプリカの各ペアが個別にモニタリングされ、エンドツーエンド（プライマリからレプリカ）のラグを発生させる単一の指標はありません。

詳細については、レプリケーション ラグをご覧ください。
ラグバイト
（cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag）

リードレプリカがプライマリをスローするバイト数を報告します。レプリカごとに 4 つの時系列が生成され、プライマリの write-ahead log で未処理のバイト数が示されます。

  • sent_location: …レプリカに送信しました
  • write_location: レプリカによってディスクに書き込まれます
  • flush_location: レプリカによってディスクにフラッシュしました
  • replay_location: レプリカによって再生されます

これらの指標は目的が異なります。たとえば、replay_location はレプリケーション ラグ（レプリカにまだ適用されていないプライマリに commit されたトランザクションの数）を返します。flush_location はレプリカ インスタンスに永続的に記録されていないトランザクションの数を示します。

pg_catalog.pg_current_wal_lsn() と pg_stat_replication のフィールド（sent_lsn、write_lsn、flush_lsn、または replay_lsn）を比較して、これらの指標が計算されます。詳細については、PostgreSQL リファレンス マニュアルの Statistics Collector をご覧ください。
最大ラグバイト
（cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag）

外部プライマリのレプリカについては、このインスタンスに複製されているすべてのデータベースでの最大レプリケーション ラグ（バイト単位）を報告します。これにより、データベースごとにプライマリの write-ahead log のバイト数（レプリカで受信が確認されていないバイト数）が定義されます。

この指標は、プライマリにクエリを送信し、このレプリカ インスタンスにレプリケートされるデータベースごとに pg_catalog.pg_current_wal_lsn() と confirmed_flush_lsn の値を比較します。詳細については、PostgreSQL リファレンス マニュアルの Statistics Collector をご覧ください。

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

コンソール

Cloud SQL は、デフォルトの Cloud SQL モニタリング ダッシュボードに Replication State 指標を表示します。

リージョン内のレプリカ、クロスリージョン レプリカ、外部サーバー レプリカの他の指標を表示するには、カスタム ダッシュボードを作成して、モニタリングする指標を追加します。

  1. Google Cloud コンソールで [Monitoring] ページに移動します。

    [Monitoring] に移動

  2. [ダッシュボード] タブを選択します。
  3. [CREATE DASHBOARD] をクリックします。
  4. ダッシュボードに名前を付けて [OK] をクリックします。
  5. [グラフを追加] をクリックします。
  6. [Resource Type] に [Cloud SQL Database] を選択します。
  7. 以下のいずれかの操作を行います。
    1. レプリケーション状態の指標をモニタリングする: [指標の選択] フィールドに「Replication state」と入力します。次に、state = "Running" のフィルタを追加します。レプリケーションが実行中の場合は 1、それ以外の場合は 0 が表示されます。
    2. リードレプリカのレプリケーション ラグをバイト単位でモニタリングする: [指標を選択] フィールドに「Lag Bytes」と入力します。続いて、replica_lag_type = "replay_location" のフィルタを追加します。プライマリに commit され、レプリカでまだ再生されていないトランザクションのバイト数がグラフに表示されます。
    3. 外部プライマリ レプリカのレプリケーション ラグをバイト単位でモニタリングするには: [指標の選択] フィールドに「Max Lag Bytes」と入力します。このグラフは、プライマリで commit され、レプリカでまだ確認されていないトランザクションのバイト数を示します。

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

psql クライアント

一部のレプリケーション ステータス指標はプライマリによって生成されますが、一部はレプリカによって生成されます。以下では、PostgreSQL クライアントを使用してレプリカまたはプライマリ インスタンスに接続します。

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

  1. プライマリ インスタンスからレプリカのステータスを確認するには:
    select * from pg_stat_replication;
     コマンドの出力で、次の指標を見つけます。
    • client_addr: レプリカ インスタンスの IP アドレス。
    • state: リレーログのイベントを実行するための SQL スレッドが実行されているかどうかを示します。レプリケーションが開始されている場合、値は streaming になります。
    • replay_lag: レプリカの SQL スレッドがプライマリ インスタンスよりも遅れているバイト数。値は O または小さいバイト数です。
  2. レプリカ インスタンスからレプリカのステータスを確認するには:
    select * from pg_stat_wal_receiver;

    コマンドの出力で、次の指標を見つけます。

    • sender_host: プライマリ インスタンスの IP アドレス。
    • status: リレーログのイベントを実行するための SQL スレッドが実行されているかどうかを示します。レプリケーションが開始されている場合、値は streaming になります。
    • last_msg_send_time と last_msg_receipt_time: この 2 つのタイムスタンプの差がタイムラグになります。

    レプリケーションが一時停止されているかどうかを確認するには:

    select pg_is_wal_replay_paused();

    レプリケーションが一時停止されている場合、値は t になり、それ以外の場合は f になります。

    プライマリから受信され、まだ適用されていないトランザクションがあるかどうかを確認するには:

    # for PostgreSQL 9.6
select pg_catalog.pg_last_xlog_receive_location(), pg_catalog.pg_last_xlog_replay_location();
# for PostgreSQL 10 and above
select pg_catalog.pg_last_wal_receive_lsn(), pg_catalog.pg_last_wal_replay_lsn();

    この 2 つの値が同じであれば、レプリカはプライマリから受信したすべてのトランザクションを処理済みです。

  • これらのコマンドの出力の詳細については、PostgreSQL ドキュメントで Statistics Collector をご覧ください。

    • トラブルシューティング

    問題 トラブルシューティング
    作成時にリードレプリカがレプリケーションを開始しなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。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 を無効にしてから再度有効にします。この措置で、プロセスを続行するために必要なサービス アカウントが作成されます。
    ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。
    ディスク容量が大幅に増加します。 データの追跡に使用されていないスロットでは、PostgreSQL が WAL セグメントに無期限に維持するため、ディスク容量は無期限に増加します。Cloud SQL で論理レプリケーションと論理デコーディング機能を使用すると、レプリケーション スロットが自動的に作成、削除されます。pg_replication_slots システムビューにクエリを実行し、active 列でフィルタリングすると、未使用のレプリケーション スロットを検出できます。未使用のスロットを削除することで、pg_drop_replication_slot コマンドで WAL セグメントを削除できます。
    レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

    レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。
    レプリケーションが停止した。 ストレージの上限に達しており、ストレージの自動増量が有効になっていません。

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

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

    • インスタンスを編集してレプリカのサイズを増やします。
    • データベースの負荷を軽減します。
    • リードレプリカにリード トラフィックを送信します。
    • テーブルをインデックスに登録します。
    • 遅い書き込みクエリを特定して修正します。
    • レプリカを再作成します。
    PostgreSQL 9.6 でインデックスを再構築する際のエラー。 特定のインデックスを再構築する必要があることを示す PostgreSQL のエラーが発生します。これは、プライマリ インスタンスでのみ行うことができます。新しいレプリカ インスタンスを作成すると、すぐに同じエラーが発生します。バージョン 10 より前の PostgreSQL ではハッシュ インデックスはレプリカに伝播されません。

    ハッシュ インデックスを使用する必要がある場合は、PostgreSQL 10 以降にアップグレードしてください。レプリカも使用する場合は、PostgreSQL 9.6 でハッシュ インデックスを使用しないでください。
    プライマリ インスタンスでのクエリは常に実行中です。 レプリカの作成後、クエリ SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' はプライマリ インスタンスで継続的に実行されます。
    レプリカの作成がタイムアウトで失敗する。 プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

    実行中のクエリをすべて停止してからレプリカを再作成します。
    プライマリ インスタンスとレプリカの vCPU サイズが異なる場合、クエリ オプティマイザーは vCPU サイズを考慮するため、クエリのパフォーマンスに問題が生じる可能性があります。

    この問題を解決するには、次の操作を行います。

    1. log_duration フラグをオンにして、log_statement パラメータを ddl に設定します。これにより、データベースのクエリと実行時間の両方を確認できます。ただし、ワークロードによっては、パフォーマンスの問題が発生する可能性があります。
    2. プライマリ インスタンスとリードレプリカの両方で、クエリに対して explain analyze を実行します。
    3. クエリプランを比較して違いを確認します。

    特定のクエリの場合は、クエリを変更します。たとえば、結合の順序を変更して、パフォーマンスが向上するかどうかを確認できます。

    次のステップ