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

レプリケーションラグ

MySQL | PostgreSQL | SQL Server

このページでは、Cloud SQL リードレプリカのレプリケーションラグのトラブルシューティングと修正方法について説明します。

概要

Cloud SQL リードレプリカは、レプリケーションに SQL Server の Always-On 可用性グループを使用します。変更はプライマリインスタンスのトランザクションログに書き込まれます。プライマリインスタンスは、セカンダリレプリカインスタンスにトランザクションを転送し、ここで変更が適用されます。使用される可用性モードは、非同期 commit モードです。

レプリケーションラグは、次のようないくつかのシナリオで発生する可能性があります。

プライマリインスタンスが、レプリカに変更を十分な速さで送信できない。
レプリカは変更を十分な速さで受信できない。
レプリカが変更を十分な速さで適用できない。

上記の最初の 2 つの理由は、

network_lag
metric

でモニタリングできます。3 つめの理由は、seconds_behind_master 指標を介してモニタリングされます。seconds_behind_master 指標が高い場合は、レプリカがレプリケーションの変更を速やかに適用できないことを意味します。これらの指標については、下のレプリケーションラグのモニタリングのセクションで説明します。

クエリとスキーマを最適化する

このセクションでは、レプリケーションのパフォーマンスを改善するためによく実行するクエリとスキーマの最適化について説明します。

リードレプリカでの長時間実行クエリ

レプリカで長時間実行されるクエリが原因で、Cloud SQL のレプリケーションがブロックされる場合があります。オンライントランザクション処理（OLTP）とオンライン分析処理（OLAP）に別々のレプリカを使用し、長時間実行クエリのみを OLAP レプリカに送信できます。

DDL による排他ロック

データ定義言語（DDL）コマンド（ALTER TABLE や CREATE INDEX など）では、排他的ロックによってレプリカでレプリケーションラグが発生することがあります。ロックの競合を回避するには、レプリカでクエリの負荷が低いときに DDL の実行をスケジュールすることを検討してください。

また、DDL ステートメント（CREATE INDEX、ALTER INDEX、

INDEX
MAINTENANCE

など）が生成できるトランザクションログレコードが多数あることから、そうしたステートメントがレプリケーションラグの原因になることがあります。

レプリカの過負荷

リードレプリカが受信するクエリが多すぎると、レプリケーションがブロックされることがあります。読み取りを複数のレプリカに分割して、各レプリカの負荷を減らすことを検討してください。

クエリの急増を回避するには、アプリケーションロジックまたはプロキシレイヤ（1 つ使用している場合）でレプリカの読み取りクエリを抑制することを検討してください。

プライマリインスタンスでアクティビティが急増した場合は、更新を分散させることを検討してください。

モノリシックなプライマリデータベース

プライマリデータベースを垂直方向（または水平方向）に分割して、1 つ以上のラグテーブルが他のすべてのテーブルを抑制しないようにすることを検討してください。