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

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

レプリケーションの仕組みについて詳しくは、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. レプリカのレプリケーションのステータスを確認します([mysql クライアント] タブの手順を行います)。
  3. レプリカがレプリケーションされていることを確認し、Seconds_Behind_Master 指標によってレポートされるレプリケーション ラグが 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 レスポンスが返されます。

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

並列レプリケーションを構成する

レプリケーション ラグを減らすことは、レプリケーションのパフォーマンスを管理するうえで重要になります。レプリケーション ラグは、リードレプリカの更新がプライマリ インスタンスの更新よりも遅れた場合に発生します。このセクションでは、ユーザーが並列レプリケーションを有効にして、レプリケーション ラグを減らす方法について説明します。

MySQL レプリケーションでは、レプリケーション SQL スレッドを使用して、リードレプリカのリレーログで収集されたトランザクションを実行します。並列レプリケーションでは、これらのトランザクションを実行する SQL スレッドの数を増やすことで、レプリケーション ラグを減らします。並列レプリケーションが有効になっているリードレプリカは、マルチスレッド レプリカと呼ばれることもあります。

Cloud SQL for MySQL では、次の 3 つのシナリオで並列レプリケーションを利用できます。

わかりやすくするために、このページでは「プライマリ インスタンス」と「リードレプリカ」という用語を使用します。

並列レプリケーション フラグを変更する基本的な手順

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

  1. リードレプリカで、レプリケーションを無効にします
  2. リードレプリカで、並列レプリケーションのフラグを設定します。gcloud コマンドを使用してフラグを設定します。レプリカを無効にすると、Google Cloud Console オプションは無効になります。
  3. リードレプリカで、レプリケーションを有効にします
  4. 必要に応じて、プライマリ インスタンスでフラグを設定して、並列レプリケーションのパフォーマンスを最適化します

リードレプリカ: 並列レプリケーションのフラグ

Cloud SQL for MySQL は、リードレプリカの並列レプリケーションで複数のフラグをサポートしています。フラグの詳細については、次のリンクをクリックして MySQL 8.0 のドキュメントをご覧ください。

これらのフラグを変更しても、リードレプリカは再起動されません。

次の表に、これらのフラグに使用可能な値とデフォルト値を示します。

リードレプリカ フラグ 使用できる値 MySQL 5.7 のデフォルト値 MySQL 8.0 のデフォルト値
slave_parallel_workers 0~1,024 0 0(MySQL 8.0.26 以前)
4(MySQL 8.0.27 以降)
slave_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE(MySQL 8.0.26 以前)
LOGICAL_CLOCK(MySQL 8.0.27 以降)
slave_preserve_commit_order ON, OFF OFF OFF(MySQL 8.0.26 以前)
ON(MySQL 8.0.27 以降)
slave_pending_jobs_size_max 1,024~1 GB 16 MB 128 MB

slave_preserve_commit_order フラグを指定すると、レプリカのリレーログから実行されるトランザクション シーケンスのギャップを回避できます。

slave_preserve_commit_order=1 の設定を使用するには、次のことを行う必要があります。

slave_pending_jobs_size_max フラグには、未適用イベントを格納するアプリケーション キューで利用できる最大メモリをバイト単位で設定します。

プライマリ インスタンス: 並列レプリケーションのフラグ

Cloud SQL for MySQL では、プライマリ インスタンスで使用できるフラグがいくつかあります。これらのフラグを使用して、並列レプリケーションが有効になっている関連レプリカのレプリケーション パフォーマンスを調整できます。フラグの詳細については、次のリンクをクリックして MySQL 8.0 のドキュメントをご覧ください。

これらのフラグを変更しても、プライマリ インスタンスは再起動されません。

次の表に、これらのフラグに使用可能な値とデフォルト値を示します。

プライマリ インスタンス フラグ 使用できる値 MySQL 5.7 のデフォルト値 MySQL 8.0 のデフォルト値
binlog_transaction_dependency_history_size 1~1,000,000 25000 25000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64

MySQL 5.7 で、binlog_transaction_dependency_trackingWRITESET または WRITESET_SESSION に設定されている場合、transaction_write_set_extractionOFF 以外の値(XXHASH64 または MURMUR32)に設定する必要があります。

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

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

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

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

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

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

  • Running
  • Stopped
  • Error

この指標は、レプリカの I/O と SQL スレッドが実行中の場合に Running を報告します。詳しくは、スレーブ I/O スレッドの実行状態スレーブ SQL スレッドの実行状態をご覧ください。または、MySQL リファレンス マニュアルでレプリケーションのステータスを確認するをご覧ください。

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

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

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

この指標は、レプリカで SHOW SLAVE STATUS が実行されたときに Seconds_Behind_Master の値をレポートします。詳細については、MySQL リファレンス マニュアルのレプリケーション ステータスの確認をご覧ください。

ネットワーク ラグ
cloudsql.googleapis.com/database/replication/network_lag

プライマリ データベースの binlog に書き込んでから、レプリカの IO スレッドに到達するまでにかかる時間(秒)。

network_lag がゼロまたはごくわずかであっても、「replica_lag」が高い場合は、SQL スレッドがレプリケーションの変更を迅速に適用できないことを示します。

スレーブ I/O スレッド実行状態
cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state

プライマリ インスタンスのバイナリログを読み取るために、I/O スレッドがレプリカで実行されているかどうかを示します。次の値があります。

  • Yes
  • No
  • Connecting

この指標は、レプリカで SHOW SLAVE STATUS が実行されたときの Slave_IO_Running 値をレポートします。詳細については、MySQL リファレンス マニュアルのレプリケーション ステータスの確認をご覧ください。

スレーブ SQL スレッドの実行状態
cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state

リレーログのイベントを実行するために SQL スレッドがレプリカ上で実行されているかどうかを示します。次の値があります。

  • Yes
  • No
  • Connecting

この指標は、レプリカで SHOW SLAVE STATUS が実行されたときの Slave_SQL_Running 値をレポートします。詳細については、MySQL リファレンス マニュアルのレプリケーション ステータスの確認をご覧ください。

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

Console

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

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

  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. レプリケーション ラグの指標をモニタリングする: [指標の選択] フィールドに「replica_lag」と入力します。グラフには、プライマリに対するレプリカの状態の遅れが時間単位で表示されます。
    3. レプリカの I/O スレッドのステータスをモニタリングする: [指標の選択] フィールドに「Slave I/O thread running state」と入力します。続いて、state = "Yes" のフィルタを追加します。スレッドが実行中の場合は 1、それ以外の場合は 0 が表示されます。
    4. レプリカの SQL スレッドのステータスをモニタリングする: [指標の選択] フィールドに「Slave SQL thread running state」と入力します。続いて、state = "Yes" のフィルタを追加します。スレッドが実行中の場合は 1、それ以外の場合は 0 が表示されます。

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

mysql クライアント

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

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

  2. レプリカのステータスを確認します。
    SHOW SLAVE STATUS \G

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

    • Master_Host: プライマリ インスタンスの名前。
    • Slave_IO_RunningSlave_SQL_Running: I/O スレッドと SQL スレッドが実行されているかどうかを示します。これらのスレッドは、イベントをプライマリからレプリカのリレーログに転送し、それらのイベントをリレーログから実行します。スレッドが実行されている場合、指標の値は Yes になります。レプリケーションを有効にするには、両方のスレッドが実行されている必要があります。
    • Seconds_Behind_Master: レプリカがプライマリ トランザクションの処理にかかる秒数。たとえば、(1)現在の時刻と(2)元のタイムスタンプの差です。元のタイムスタンプとは、現在レプリカに適用されているトランザクションをプライマリが commit した時刻です。レプリケーションが壊れた場合、値は NULL になります。
    • Master_Log_fileRead_Master_Log_PosRelay_Master_Log_FileExec_Master_Log_Pos: これらの指標は座標(ファイル名とオフセット)を示し、I/O スレッドが読み取った直近のイベント(Master_Log_fileRead_Master_Log_Pos)と、SQL スレッドが実行した直近のイベント(Relay_Master_Log_FileExec_Master_Log_Pos)です。これらが同一(Master_Log_file = Relay_Master_Log_FileRead_Master_Log_Pos = Exec_Master_Log_Pos)の場合、レプリカはプライマリから受信したイベントすべての処理を完了しています。

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

トラブルシューティング

問題 トラブルシューティング
作成時にリードレプリカがレプリケーションを開始しなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。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 されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログ イベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーション ラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーション ラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーション ラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。

長時間のトランザクションを避けるために、次のような解決策が考えられます。

  • トランザクションを複数の小さなトランザクションに分割します。
  • 1 つの大きな書き込みクエリを小さなバッチに分割します。
  • DML を含むトランザクションから長い SELECT クエリを分離します。
並列レプリケーション フラグを変更するとエラーが発生する。 1 つ以上のフラグに間違った値が設定されています。

エラー メッセージが表示されているプライマリ インスタンスで、並列レプリケーション フラグを設定します。

  1. binlog_transaction_dependency_tracking フラグと transaction_write_set_extraction フラグを変更します。
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. slave_pending_jobs_size_max フラグを追加します。

    slave_pending_jobs_size_max=33554432

  3. transaction_write_set_extraction フラグを変更します。

    transaction_write_set_extraction=XXHASH64

  4. binlog_transaction_dependency_tracking フラグを変更します。

    binlog_transaction_dependency_tracking=WRITESET

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

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

次のステップ