このページでは、リードレプリカの管理方法について説明します。ここでは、レプリケーションの無効化と有効化、レプリカのプロモート、並列レプリケーションの構成、レプリケーション ステータスの確認について説明します。
レプリケーションの仕組みについて詳しくは、Cloud SQL のレプリケーションをご覧ください。
レプリケーションを無効にする
デフォルトでは、レプリカのレプリケーションは有効に設定されています。ただし、レプリケーションを無効にできます。たとえば、デバッグの実行時や、インスタンスの状態を分析する場合などです。準備が完了したら、レプリケーションを明示的に再び有効にします。レプリケーションを無効または再度有効にしても、レプリカ インスタンスは再起動されません。
レプリケーションを無効にしてもレプリカのインスタンスは停止されませんが、読み取り専用のインスタンスになり、プライマリ インスタンスからのレプリケーションは実行されなくなります。このインスタンスは引き続き課金されます。無効にしたレプリカでは、レプリケーションを再度有効にしたり、レプリカを削除できます。また、レプリカをスタンドアロン インスタンスにプロモートすることもできます。
レプリケーションを無効にする手順は次のとおりです。
コンソール
-
Google Cloud コンソールで 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" } }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような 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 レスポンスが返されます。
レプリケーションを有効にする
レプリカが長期間レプリケーションされていないと、プライマリ インスタンスとの同期に長時間かかります。この場合は、レプリカを削除し、新しいレプリカを作成します。
レプリケーションを有効にするには:
コンソール
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- レプリカ インスタンスの名前をクリックして選択します。
- [レプリケーションを有効にする] をクリックします。
- [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)インスタンスとしては自動的に構成されません。レプリカ以外のインスタンスの場合と同様に、レプリカのプロモート後に高可用性を有効にできます。高可用性用にリードレプリカを構成する方法は、プライマリ インスタンスの場合と同じです。インスタンスの高可用性構成の詳細をご確認ください。
リードレプリカをプロモートする前に、プライマリが現在も使用可能であり、クライアントを処理する場合は、次のことを行う必要があります。
- プライマリ インスタンスへの書き込みをすべて停止します。
- レプリカのレプリケーションのステータスを確認します([mysql クライアント] タブの手順を行います)。
- レプリカがレプリケーションされていることを確認し、
Seconds_Behind_Master
指標によってレポートされるレプリケーション ラグが 0 になるまで待つ必要があります。
それ以外の場合は、新しくプロモートしたインスタンスに、プライマリ インスタンスに commit されたトランザクションの一部が存在しない可能性があります。
スタンドアロンのインスタンスにレプリカをプロモートする手順は次のとおりです。
コンソール
-
Google Cloud コンソールで 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
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような 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 つのシナリオで並列レプリケーションを利用できます。
わかりやすくするために、このページでは「プライマリ インスタンス」と「リードレプリカ」という用語を使用します。
並列レプリケーション フラグを変更する基本的な手順
並列レプリケーションを有効にする手順は次のとおりです。
- リードレプリカで、レプリケーションを無効にします。
- リードレプリカで、並列レプリケーションのフラグを設定します。
gcloud
コマンドを使用してフラグを設定します。レプリカを無効にすると、Google Cloud Console オプションは無効になります。 - リードレプリカで、レプリケーションを有効にします。
- 必要に応じて、プライマリ インスタンスでフラグを設定して、並列レプリケーションのパフォーマンスを最適化します。
リードレプリカ: 並列レプリケーションのフラグ
Cloud SQL for MySQL は、リードレプリカの並列レプリケーションで複数のフラグをサポートしています。フラグの詳細については、次のリンクをクリックして MySQL 8.0 のドキュメントをご覧ください。
- replica_parallel_workers
- replica_parallel_type
- replica_preserve_commit_order
- replica_pending_jobs_size_max
これらのフラグを変更しても、リードレプリカは再起動されません。
次の表に、これらのフラグに使用可能な値とデフォルト値を示します。
リードレプリカ フラグ | 使用できる値 | 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 のドキュメントをご覧ください。
- binlog_transaction_dependency_history_size
- binlog_transaction_dependency_tracking
- transaction_write_set_extraction
これらのフラグを変更しても、プライマリ インスタンスは再起動されません。
次の表に、これらのフラグに使用可能な値とデフォルト値を示します。
プライマリ インスタンス フラグ | 使用できる値 | 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 ) |
レプリケーションでプライマリからレプリカにログがストリーミングされているどうかを示します。次の値があります。
この指標は、レプリカの I/O と SQL スレッドが実行中の場合に |
レプリケーション ラグ ( cloudsql.googleapis.com ) |
プライマリ インスタンスの状態に対するレプリカの状態の遅れ(時間)。(1)現在の時刻と(2)現在レプリカに適用されているトランザクションをプライマリが commit したときのタイムスタンプの差です。特に、レプリカが書き込みを受信していても、レプリカがデータベースへの書き込みをまだ適用していない場合、書き込みは遅延として記録される可能性があります。 カスケード レプリカの場合、プライマリとレプリカの各ペアが個別にモニタリングされ、エンドツーエンド(プライマリからレプリカ)のラグを示す単一の指標はありません。 この指標は、レプリカで |
ネットワーク ラグ ( cloudsql.googleapis.com ) |
プライマリ データベースの binlog に書き込んでから、レプリカの IO スレッドに到達するまでにかかる時間(秒)。 network_lag がゼロまたはごくわずかであっても、「replica_lag」が高い場合は、SQL スレッドがレプリケーションの変更を迅速に適用できないことを示します。 |
スレーブ I/O スレッド実行状態 ( cloudsql.googleapis.com ) |
プライマリ インスタンスのバイナリログを読み取るために、I/O スレッドがレプリカで実行されているかどうかを示します。次の値があります。
この指標は、レプリカで |
スレーブ SQL スレッドの実行状態 ( cloudsql.googleapis.com ) |
リレーログのイベントを実行するために SQL スレッドがレプリカ上で実行されているかどうかを示します。次の値があります。
この指標は、レプリカで |
レプリケーションのステータスを確認するには:
Console
Cloud SQL は、デフォルトの Cloud SQL モニタリング ダッシュボードに Replication State
指標と Replication Lag
指標を表示します。
リージョン内のレプリカ、クロスリージョン レプリカ、外部サーバー レプリカの他の指標を表示するには、カスタム ダッシュボードを作成して、モニタリングする指標を追加します。
-
Google Cloud コンソールで [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 エラー。 | リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。 まず、
|
リードレプリカを作成できない - 不明なエラー。 | ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。 エラーが |
ディスクに空きがない。 | レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。 |
レプリカ インスタンスのメモリ使用量が多すぎる。 | レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。 |
レプリケーションが停止した。 | ストレージの上限に達しており、ストレージの自動増量が有効になっていません。 インスタンスを編集して |
レプリケーション ラグが常に大きい。 | 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
考えられる解決策は次のとおりです。
|
レプリケーション ラグが突然急増する。 | これは、トランザクションが長時間実行されていることが原因です。ソース インスタンスでトランザクション(単一ステートメントまたは複数ステートメント)が commit されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログ イベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーション ラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーション ラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーション ラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。 長時間のトランザクションを避けるために、次のような解決策が考えられます。
|
並列レプリケーション フラグを変更するとエラーが発生する。 | 1 つ以上のフラグに間違った値が設定されています。 エラー メッセージが表示されているプライマリ インスタンスで、並列レプリケーション フラグを設定します。
|
レプリカの作成がタイムアウトで失敗する。 | プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。 実行中のクエリをすべて停止してからレプリカを再作成します。 |
次のステップ
- リードレプリカの作成方法を学習する。
- リードレプリカのインデックスの Cloud SQL ストアド プロシージャについて学習する。
- 外部レプリカ構成の構成方法を学習する。
- 外部プライマリ構成を行う方法について学習する。
- レプリケーションの要件とベスト プラクティスを学習する。