リードレプリカの管理

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

レプリケーションの仕組みについて詳しくは、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 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 Console で、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 プライマリ インスタンスに変換されます。

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

  1. プライマリ インスタンスへの書き込みをすべて停止します。
  2. レプリカのレプリケーションのステータスを確認します([psql Client] タブの手順を行います)。
  3. レプリカがレプリケーションされていることを確認し、replay_lag 指標によってレポートされるレプリケーション ラグが 0 になるまで待つ必要があります。

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

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

Console

  1. Google Cloud Console で、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 Console でレプリカ インスタンスを表示するか、管理クライアントからインスタンスにログインすると、ステータスや指標などのレプリケーションの詳細を取得できます。gcloud コマンドライン ツールを使用すると、レプリケーション構成の概要を取得できます。

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

指標説明
レプリケーション状態
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 CollectorSystem Administration Function をご覧ください。

レプリケーション ラグ
cloudsql.googleapis.com/database/replication/replica_lag

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

ラグバイト
cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag

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

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

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

pg_catalog.pg_current_wal_lsn()pg_stat_replication のフィールド(sent_lsnwrite_lsnflush_lsn、または replay_lsn)を比較して、これらの指標が計算されます。詳細については、PostgreSQL リファレンス マニュアルの Statistics Collector をご覧ください。

最大ラグバイト
cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag

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

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

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

Console

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

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

  1. Google Cloud Console で、[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

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

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

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_timelast_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 を無効にしてから再度有効にします。この措置で、プロセスを続行するために必要なサービス アカウントが作成されます。

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

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

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

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

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

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

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

    ハッシュ インデックスを使用する必要がある場合は、PostgreSQL 10 以降にアップグレードしてください。レプリカも使用する場合は、PostgreSQL 9.6 でハッシュ インデックスを使用しないでください。

    レプリカの作成がタイムアウトで失敗する。 プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

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

    次のステップ