# リードレプリケーションのモニタリング
リードレプリカのステータスは、さまざまな方法でモニタリングできます。Amazon RDS コンソールは、リードレプリカの詳細にある **[Connectivity & security]** (接続性とセキュリティ) タブの **[Replication]** (レプリケーション) セクションでリードレプリカのステータスを表示します。リードレプリカの詳細を表示するには、Amazon RDS コンソールの DB インスタンスのリストでリードレプリカの名前を選択します。
![\[リードレプリカのステータス\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ReadReplicaStatus.png)
AWS CLI `describe-db-instances` コマンドまたは Amazon RDS API `DescribeDBInstances` オペレーションを使用して、リードレプリカのステータスを確認することもできます。
リードレプリカのステータスは、以下のいずれかです。
+ ****replicating**** – リードレプリカが正常にレプリケーションされています。
+ ****replication degraded** (SQL Server および PostgreSQL のみ) – **レプリカはプライマリインスタンスからデータを受信していますが、1 つ以上のデータベースが更新を取得していない可能性があります。これは、レプリカが新しく作成されたデータベースをセットアップしているときなどに発生します。また、ブルー/グリーンデプロイのブルー環境で、サポートされていない DDL やラージオブジェクトの変更が行われた場合にも発生する可能性があります。
パフォーマンスが低下した状態でエラーが発生しない限り、ステータスは `replication degraded` から `error` に移行しません。
+ ****error**** – レプリケーションでエラーが発生しました。Amazon RDS コンソールの [**Replication Error**] またはイベントをログを確認して、正確なエラーについて調べます。レプリケーションエラーのトラブルシューティングの詳細については、「[MySQL リードレプリカに関する問題のトラブルシューティング](USER_ReadRepl.Troubleshooting.md)」を参照してください。
+ ****terminated** (MariaDB、MySQL、または PostgreSQL のみ)** – レプリケーションが終了しました。これは、手動またはレプリケーションエラーによってレプリケーションが連続する 30 日超停止した場合に発生します。この場合、Amazon RDS はプライマリ DB インスタンスとすべてのリードレプリカ間のレプリケーションを終了します。Amazon RDS は、ソース DB インスタンスでのストレージ要件の増加と長いフェイルオーバー時間を防ぐためにこれを行います。
レプリケーションが中断すると、ログに書き込まれるエラーメッセージの量が増えてログのサイズと数が増加するため、ストレージに影響が及ぶ可能性があります。さらに、レプリケーションが中断すると、Amazon RDS が復旧中に大量のログを保持して処理するのに必要な時間が原因で、災害対策にも影響が及ぶ可能性があります。
+ ****終了** (Oracle のみ)** – レプリケーションは終了します。これは、リードレプリカに十分なストレージが残っていないため、レプリケーションが 8 時間以上停止した場合に発生します。この場合、Amazon RDS はプライマリ DB インスタンスと影響を受けたリードレプリカ間のレプリケーションを終了します。このステータスは終了状態であり、リードレプリカを再作成する必要があります。
+ ****stopped** (MariaDB または MySQL のみ)** – お客様がリクエストを開始したため、レプリケーションが停止しました。
+ ****replication stop point set** (MySQL のみ)** – お客様が開始した停止ポイントが [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャを使用して設定され、レプリケーションが進行中です。
+ ****replication stop point reached** (MySQL のみ)** – お客様が開始した停止ポイントが [mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャを使用して設定され、レプリケーションは停止ポイントに到達したために停止しました。
DB インスタンスのレプリケート先の場所を確認でき、その場合は、そのレプリケーションステータスを確認できます。RDS コンソールの [**Databases**] (データベース) ページの [**Role**] (ロール) 列に [**Primary**] (プライマリ) と表示されます。その DB インスタンス名を選択します。詳細ページの [**Connectivity & security**] (接続とセキュリティ) タブの [**Replication**] (レプリケーション) の下に、レプリケーションの状態が表示されます。
## レプリケーションラグのモニタリング
Amazon CloudWatch のレプリケーションのラグをモニタリングするには、Amazon RDS `ReplicaLag` メトリクスを表示します。
Db2 の場合、`ReplicaLag` メトリクスは、遅延しているデータベースの最大遅延 (秒単位) です。例えば、5 秒遅れているデータベースと 10 秒遅れているデータベースがある場合、`ReplicaLag` は 10 秒です。高可用性ディザスタリカバリ (HADR) の使用可能なステータスがないデータベースは、計算に含まれません。
MariaDB と MySQL の場合、`ReplicaLag` メトリクスでは、`Seconds_Behind_Master` コマンドの `SHOW REPLICA STATUS` フィールドの値がレポートされます。MySQL と MariaDB のレプリケーション遅延の一般的な原因は以下のとおりです。
+ ネットワークが停止している。
+ リードレプリカで、インデックスがあるテーブルに書き込んでいる。`read_only` パラメータがリードレプリカで 0 に設定されていない場合、レプリケーションが中断されることがあります。
+ MyISAM などの非トランザクションストレージエンジンを使用している。レプリケーションは、MariaDB の MySQL および InnoDB ストレージエンジンの XtraDB ストレージエンジンでのみサポートされます。
**注記**
MariaDB の旧バージョンは、`SHOW SLAVE STATUS` ではなく `SHOW REPLICA STATUS` を使用していました。10.5 より前の MariaDB バージョンを使用している場合は、`SHOW SLAVE STATUS` を使用します。
`ReplicaLag` メトリクスが 0 に達すると、レプリカはプライマリ DB インスタンスに追いついています。`ReplicaLag` メトリクスにより `-1` が返された場合、レプリケーションは現在アクティブではありません。`ReplicaLag = -1` は `Seconds_Behind_Master = NULL` と同等です。
Oracle で、`ReplicaLag` メトリクスは、`Apply Lag` 値と、現在の時刻と適用するラグの `DATUM_TIME` 値の差異の合計です。`DATUM_TIME` 値は、リードレプリカがソース DB インスタンスから最後にデータを受信した時刻です。詳細については、Oracle ドキュメントの「[V\$1DATAGUARD\$1STATS](https://docs.oracle.com/database/121/REFRN/GUID-B346DD88-3F5E-4F16-9DEE-2FDE62B1ABF7.htm#REFRN30413)」を参照してください。
SQL Server の場合、`ReplicaLag` メトリクスは、遅延しているデータベースの最大ラグ (秒単位) です。例えば、5 秒遅れているデータベースと 10 秒遅れているデータベースがある場合、`ReplicaLag` は 10 秒です。`ReplicaLag` メトリクスは、次のクエリの値を返します。
```
SELECT MAX(secondary_lag_seconds) max_lag FROM sys.dm_hadr_database_replica_states;
```
詳細については、Microsoft ドキュメントの「[secondary\$1lag\$1seconds](https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-hadr-database-replica-states-transact-sql)」を参照してください。
`ReplicaLag` はレプリカのセットアップ中やリードレプリカが `-1` 状態にあるときなど、RDS でラグを確認できない場合は `error` を返します。
**注記**
新しいデータベースは、リードレプリカでアクセス可能になるまでラグ計算に含まれません。
PostgreSQL では、`ReplicaLag` メトリクスは次のクエリの値を返します。
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS reader_lag
```
PostgreSQL バージョン 9.5.2 以降では、ソースインスタンスで保持される先書きログ (WAL) の管理に物理レプリケーションスロットを使用します。クロスリージョンリードレプリカインスタンスごとに、Amazon RDS は物理レプリケーションスロットを作成し、インスタンスに関連付けます。2 つ Amazon CloudWatch メトリクス `Oldest Replication Slot Lag` と `Transaction Logs Disk Usage` では、WAL データの受信について最も長い遅延が発生しているレプリカまでの距離と、WAL データに使用されているストレージの量が表示されます。クロスリージョンリードレプリカで著しい遅延が発生しているときは、`Transaction Logs Disk Usage` の値を大幅に増やすことができます。
CloudWatch を使用した DB インスタンスのモニタリングの詳細については、「[Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。