このページは Cloud Translation API によって翻訳されました。

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

MySQL | PostgreSQL | SQL Server

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

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

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

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

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

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

コンソール

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

Cloud SQL の [インスタンス] に移動
レプリカインスタンスの名前をクリックして選択します。
ボタンバーの [レプリケーションを無効にする] をクリックします。
[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"
  }
}

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

curl（Linux、macOS、Cloud Shell）

注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ユーザーアカウントで gcloud CLI にログインしているか、Cloud Shell を使用して自動的に gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name"

PowerShell（Windows）

注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ご自分のユーザーアカウントで gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

HTTP メソッドと URL:

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

リクエストの本文（JSON）:

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

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

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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

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

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

コンソール

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

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

gcloud

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

REST v1

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

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

HTTP メソッドと URL:

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

リクエストの本文（JSON）:

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

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

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

HTTP メソッドと URL:

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

リクエストの本文（JSON）:

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

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

curl（Linux、macOS、Cloud Shell）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name"

PowerShell（Windows）

リクエスト本文を request.json という名前のファイルに保存して、次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

レプリカをプロモートする

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

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

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

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

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

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

コンソール

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

Cloud SQL の [インスタンス] に移動
レプリカインスタンスの名前をクリックして選択します。
[レプリカをプロモート] をクリックします。
[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

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

curl（Linux、macOS、Cloud Shell）

次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica"

PowerShell（Windows）

次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

HTTP メソッドと URL:

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

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

curl（Linux、macOS、Cloud Shell）

次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica"

PowerShell（Windows）

次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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

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

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

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

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

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

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

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

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

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

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

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

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

リードレプリカフラグ	使用できる値	MySQL 5.7 のデフォルト値	MySQL 8.0 以降のデフォルト値
`replica_parallel_workers`	0～1,024	0	0（MySQL 8.0.26 以前） 4（MySQL 8.0.27 以降）
`replica_parallel_type`	`DATABASE, LOGICAL_CLOCK`	`DATABASE`	`DATABASE`（MySQL 8.0.26 以前） `LOGICAL_CLOCK`（MySQL 8.0.27 以降）
`replica_preserve_commit_order`	`ON, OFF`	`OFF`	`OFF`（MySQL 8.0.26 以前） `ON`（MySQL 8.0.27 以降）
`replica_pending_jobs_size_max`	1,024～1 GB	16 MB	128 MB

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

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

レプリカでバイナリログを有効にする（MySQL 5.7、MySQL 8.0.18 以前のバージョンのみ）
replica_parallel_type を LOGICAL_CLOCK に設定する

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

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

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

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

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

プライマリインスタンスフラグ	使用できる値	MySQL 5.7 のデフォルト値	MySQL 8.0 のデフォルト値	MySQL 8.4 のデフォルト値
`binlog_transaction_dependency_history_size`	1～1,000,000	25000	25,000	25000
`binlog_transaction_dependency_tracking`	`COMMIT_ORDER, WRITESET, WRITESET_SESSION`	`COMMIT_ORDER`	`WRITESET`	なし（MySQL 8.4 で非推奨）
`transaction_write_set_extraction`	`OFF, MURMUR32, XXHASH64`	`OFF`	`XXHASH64`	なし（MySQL 8.4 で非推奨）

MySQL 5.7 で、binlog_transaction_dependency_tracking が WRITESET または WRITESET_SESSION に設定されている場合、transaction_write_set_extraction を OFF 以外の値（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 REPLICA STATUS` が実行されたときに `Seconds_Behind_Master` の値をレポートします。詳細については、MySQL リファレンスマニュアルのレプリケーションステータスの確認をご覧ください。
ネットワークラグ（`cloudsql.googleapis.com/database/replication/network_lag`）	レプリカの IO スレッドに到達するためにプライマリデータベースにバイナリログを書き込むのにかかった時間（秒）。 network_lag がゼロまたはごくわずかであっても、「replica_lag」が高い場合は、SQL スレッドがレプリケーションの変更を迅速に適用できないことを示します。
スレーブ I/O スレッド実行状態（`cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state`）	プライマリインスタンスのバイナリログを読み取るために、I/O スレッドがレプリカで実行されているかどうかを示します。次の値があります。 `Yes` `No` `Connecting` この指標は、レプリカで `SHOW REPLICA STATUS` が実行されたときの `Slave_IO_Running` 値をレポートします。詳細については、MySQL リファレンスマニュアルのレプリケーションステータスの確認をご覧ください。
スレーブ SQL スレッドの実行状態（`cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state`）	リレーログのイベントを実行するために SQL スレッドがレプリカ上で実行されているかどうかを示します。次の値があります。 `Yes` `No` `Connecting` この指標は、レプリカで `SHOW REPLICA STATUS` が実行されたときの `Slave_SQL_Running` 値をレポートします。詳細については、MySQL リファレンスマニュアルのレプリケーションステータスの確認をご覧ください。

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

Console

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

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

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

[Monitoring] に移動
[ダッシュボード] タブを選択します。
[CREATE DASHBOARD] をクリックします。
ダッシュボードに名前を付けて [OK] をクリックします。
[グラフを追加] をクリックします。
[Resource Type] に [Cloud SQL Database] を選択します。
以下のいずれかの操作を行います。

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

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

mysql クライアント

MySQL クライアントを使用してレプリカに接続します。
詳しくは、外部アプリケーションのための接続オプションをご覧ください。
レプリカのステータスを確認します。
```
SHOW REPLICA STATUS \G
```
コマンドの出力で、次の指標を見つけます。
- Master_Host: プライマリインスタンスの名前。
- Slave_IO_Running、Slave_SQL_Running: I/O スレッドと SQL スレッドが実行されているかどうかを示します。これらのスレッドは、イベントをプライマリからレプリカのリレーログに転送し、それらのイベントをリレーログから実行します。スレッドが実行されている場合、指標の値は Yes になります。レプリケーションを有効にするには、両方のスレッドが実行されている必要があります。
- Seconds_Behind_Master: レプリカがプライマリトランザクションの処理にかかる秒数。たとえば、（1）現在の時刻と（2）元のタイムスタンプの差です。元のタイムスタンプとは、現在レプリカに適用されているトランザクションをプライマリが commit した時刻です。レプリケーションが壊れた場合、値は NULL になります。
- Master_Log_file、Read_Master_Log_Pos、Relay_Master_Log_File、Exec_Master_Log_Pos: これらの指標は座標（ファイル名とオフセット）を示し、I/O スレッドが読み取った直近のイベント（Master_Log_file と Read_Master_Log_Pos）と、SQL スレッドが実行した直近のイベント（Relay_Master_Log_File と Exec_Master_Log_Pos）です。これらが同一（Master_Log_file = Relay_Master_Log_File、Read_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` などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーションラグが発生します。考えられる解決策は次のとおりです。並列レプリケーションを構成する。リードレプリカの innodb_flush_log_at_trx_commit フラグを 2 に設定します。このフラグの詳細については、フラグの使用に関するヒントをご覧ください。インスタンスを編集してレプリカのサイズを増やす。データベースの負荷を軽減します。リードレプリカにリードトラフィックを送信します。テーブルをインデックスに登録します。遅い書き込みクエリを特定して修正します。レプリカを再作成します。
レプリケーションラグが突然急増する。	これは、トランザクションが長時間実行されていることが原因です。ソースインスタンスでトランザクション（単一ステートメントまたは複数ステートメント）が commit されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログイベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーションラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーションラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーションラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。長時間のトランザクションを避けるために、次のような解決策が考えられます。トランザクションを複数の小さなトランザクションに分割します。 1 つの大きな書き込みクエリを小さなバッチに分割します。 DML を含むトランザクションから長い SELECT クエリを分離します。
並列レプリケーションフラグを変更するとエラーが発生する。	1 つ以上のフラグに間違った値が設定されています。エラーメッセージが表示されているプライマリインスタンスで、並列レプリケーションフラグを設定します。 `binlog_transaction_dependency_tracking` フラグと `transaction_write_set_extraction` フラグを変更します。 `binlog_transaction_dependency_tracking=COMMIT_ORDER` `transaction_write_set_extraction=OFF` `slave_pending_jobs_size_max` フラグを追加します。 `slave_pending_jobs_size_max=33554432` `transaction_write_set_extraction` フラグを変更します。 `transaction_write_set_extraction=XXHASH64` `binlog_transaction_dependency_tracking` フラグを変更します。 `binlog_transaction_dependency_tracking=WRITESET`
レプリカの作成がタイムアウトで失敗します。	プライマリインスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。実行中のクエリをすべて停止してからレプリカを再作成します。

次のステップ

リードレプリカの作成方法を学習する。
リードレプリカのインデックスの Cloud SQL ストアドプロシージャについて学習する。
外部レプリカ構成の構成方法を学習する。
外部プライマリ構成を行う方法について学習する。
レプリケーションの要件とベストプラクティスを学習する。

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

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

コンソール

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

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

コンソール

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

レプリカをプロモートする

コンソール

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

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

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

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

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

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

Console

gcloud

mysql クライアント

トラブルシューティング

次のステップ

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

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