このページでは、Cloud SQL リードレプリカのレプリケーション ラグのトラブルシューティングと修正方法について説明します。
概要
Cloud SQL リードレプリカは、レプリケーションに SQL Server の Always-On 可用性グループを使用します。変更はプライマリ インスタンスのトランザクション ログに書き込まれます。プライマリ インスタンスは、セカンダリ レプリカ インスタンスにトランザクションを転送し、ここで変更が適用されます。使用される可用性モードは、非同期 commit モードです。レプリケーション ラグは、次のようないくつかのシナリオで発生する可能性があります。
- プライマリ インスタンスが、レプリカに変更を十分な速さで送信できない。
- レプリカが変更を十分な速さで受信できない。
- レプリカが変更を十分な速さで適用できない。
network_lag
metric
でモニタリングできます。3 つめの理由は seconds_behind_master
指標を介してモニタリングされます。seconds_behind_master
指標が高い場合は、レプリカがレプリケーションの変更を速やかに適用できないことを意味します。これらの指標については、以下のレプリケーション ラグのモニタリングのセクションで説明します。クエリとスキーマを最適化する
このセクションでは、レプリケーションのパフォーマンスを改善するためによく実行するクエリとスキーマの最適化について説明します。
リードレプリカでの長時間実行クエリ
レプリカで長時間実行されるクエリが原因で、Cloud SQL のレプリケーションがブロックされる場合があります。オンライン トランザクション処理(OLTP)とオンライン分析処理(OLAP)に別々のレプリカを使用し、長時間実行クエリのみを OLAP レプリカに送信できます。
DDL による排他ロック
データ定義言語(DDL)コマンド(ALTER TABLE
や CREATE INDEX
など)では、排他的ロックによってレプリカでレプリケーション ラグが発生することがあります。ロックの競合を回避するには、レプリカでクエリの負荷が低いときに DDL の実行をスケジュールすることを検討してください。
CREATE INDEX
、ALTER INDEX
、INDEX
MAINTENANCE
など)が生成できるトランザクション ログレコードが多数あることから、そうしたステートメントがレプリケーション ラグの原因になることがあります。レプリカの過負荷
リードレプリカが受信するクエリが多すぎると、レプリケーションがブロックされることがあります。読み取りを複数のレプリカに分割して、各レプリカの負荷を減らすことを検討してください。
クエリの急増を回避するには、アプリケーション ロジックまたはプロキシレイヤ(1 つ使用している場合)でレプリカの読み取りクエリを抑制することを検討してください。
プライマリ インスタンスでアクティビティが急増した場合は、更新を分散させることを検討してください。
モノリシックなプライマリ データベース
プライマリ データベースを垂直方向(または水平方向)に分割して、1 つ以上のラグテーブルが他のすべてのテーブルを抑制しないようにすることを検討してください。
レプリケーション ラグをモニタリングする
replica_lag
指標と network_lag
指標を使用してレプリケーション ラグをモニタリングし、ラグの原因がプライマリ データベース、ネットワーク、レプリカのどれにあるのかを識別できます。
指標 | 説明 |
---|---|
レプリケーション ラグ ( cloudsql.googleapis.com/database/replication/seconds_behind_master ) |
レプリカの状態がプライマリ インスタンスの状態よりも遅れている秒数。これは、セカンダリで最後にやり直されたログレコードのタイムスタンプと、プライマリで最後に送信されたログレコードのタイムスタンプの差です。 |
ネットワーク ラグ ( cloudsql.googleapis.com ) |
レプリカで最後に受信したログエントリのタイムスタンプと、プライマリで最後に送信されたログエントリのタイムスタンプの差。 |
レプリケーションを検証する
レプリケーションが機能していることを確認するには、プライマリ インスタンスのcloudsql.googleapis.com/database/replication/state
指標の値を確認します。状態が Running
の場合、レプリケーションは正常です。