

# aurora\$1replica\$1status
<a name="aurora_replica_status"></a>

すべての Aurora PostgreSQL リーダーノードのステータスを表示します。

## 構文
<a name="aurora_replica_status-syntax"></a>

 

```
aurora_replica_status()
```

## 引数
<a name="aurora_replica_status-arguments"></a>

なし

## 戻り型
<a name="aurora_replica_status-return-type"></a>

次の列を含む SETOF レコード。
+ `server_id` - DB インスタンス ID (識別子)。
+ `session_id` — 現在のセッションの一意の識別子。プライマリインスタンスおよびリーダーインスタンスについて次のように返されます。
  + プライマリインスタンスについては、`session_id` は常に ``MASTER_SESSION_ID’` です。
  + リーダーインスタンスについては、`session_id` は常にリーダーインスタンスの `UUID` (ユニバーサル一意識別子) です。
+ `durable_lsn` — ストレージに保存されているログシーケンス番号 (LSN)。
  + プライマリボリュームの場合、現在有効なプライマリボリューム耐久性 LSN (VDL)。
  + セカンダリボリュームの場合、セカンダリが正常に適用されたプライマリのVDL。
**注記**  
ログシーケンス番号 (LSN) は、データベーストランザクションログ内のレコードを識別する一意の連続番号です。LSN は、より大きな LSN がシーケンスの後の方で発生したトランザクションを表すように順序付けられます。
+ `highest_lsn_rcvd` — ライター DB インスタンスから DB インスタンスが受信した最も高い (最新の) LSN。
+ `current_read_lsn` — すべてのリーダーに適用された最新のスナップショットの LSN。
+ `cur_replay_latency_in_usec` — セカンダリでのログの再生に要すると推測されるマイクロ秒数。
+ `active_txns` - 現在アクティブなトランザクションの数。
+ `is_current` - 使用されません。
+ `last_transport_error` — 前回のレプリケーションエラーコード。
+ `last_error_timestamp` — 最後のレプリケーションエラーのタイムスタンプ。
+ `last_update_timestamp` — レプリカステータスの最終更新のタイムスタンプ。Aurora PostgreSQL 13.9 以降では、接続先の DB インスタンスの `last_update_timestamp` 値は `NULL` に設定されます。
+ `feedback_xmin` — レプリカのホットスタンバイ feedback\$1xmin。DB インスタンスで使用される最小の (最も古い) アクティブトランザクション ID。
+ `feedback_epoch` - DB インスタンスがホットスタンバイ情報を生成するときに使用するエポック。
+ `replica_lag_in_msec` — リーダーインスタンスがライターインスタンスより遅れている時間 (ミリ秒単位)。
+ `log_stream_speed_in_kib_per_second` — キロバイト/秒単位のログストリームスループット。
+ `log_buffer_sequence_number` — ログバッファのシーケンス番号。
+ `oldest_read_view_trx_id` - 使用されません。
+ `oldest_read_view_lsn` - ストレージから読み取るために DB インスタンスが使用した最も古い LSN。
+ `pending_read_ios` — レプリカで保留中の未処理のページ読み取り。
+ `read_ios` — レプリカでのページ読み取りの総数。
+ `iops` - 使用されません。
+ `cpu` – クラスター内の各ノードの Aurora ストレージデーモンの CPU 使用率。インスタンスによる CPU 使用率の詳細については、「[Amazon Aurora のインスタンスレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)」を参照してください。

## 使用に関する注意事項
<a name="aurora_replica_status-usage-notes"></a>

現在利用可能なすべての Aurora PostgreSQL バージョンは、この関数をサポートしています。`aurora_replica_status` 関数は、Aurora PostgreSQL DB クラスターのレプリカステータスマネージャーから値を返します。この関数を使用して、Aurora DB クラスター内のすべての DB インスタンスのメトリックを含め、Aurora PostgreSQL DB クラスターのレプリケーションのステータスに関する情報を取得できます。例えば、次のオペレーションを実行できます。
+ **Aurora PostgreSQL DB クラスター内のインスタンスのタイプ (ライター、リーダー) に関する情報を取得する** - この情報を取得するには、次の列の値を確認します。
  + `server_id` - インスタンスの作成時に指定したインスタンスの名前が含まれます。プライマリ (ライター) インスタンスの場合など、名前は、通常、Aurora PostgreSQL DB クラスター用に作成した名前に *-instance-1* を付加することによって自動的に作成されます。
  + `session_id` — `session_id` フィールドは、インスタンスがリーダーかライターかを示します。ライターインスタンスの場合、`session_id` は常に `"MASTER_SESSION_ID"` に設定されます。リーダーインスタンスの場合、`session_id` は特定のリーダーの `UUID` に設定されます。
+ **レプリカのラグなど、一般的なレプリケーションの問題を診断する** — レプリカのラグは、リーダーインスタンスのページキャッシュがライターインスタンスのページキャッシュより遅れている時間 (ミリ秒) です。このラグは、[Amazon Aurora でのレプリケーション](Aurora.Replication.md) で説明されているように、Aurora クラスターが非同期レプリケーションを使用しているために発生します。これは、この関数によって返される結果の `replica_lag_in_msec` 列に表示されます。ラグは、スタンバイサーバーでのリカバリとの競合によってクエリがキャンセルされた場合にも発生することがあります。`pg_stat_database_conflicts()` をチェックして、このような競合がレプリカラグを引き起こしている (または引き起こしていない) ことを確認できます。詳細については、『*PostgreSQL ドキュメント*』の「[統計コレクター](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW)」を参照してください。高可用性とレプリケーションの詳細については、「[Amazon Aurora よくある質問](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication)」を参照してください。

  Amazon CloudWatch は 時間の経過とともに `replica_lag_in_msec` の結果を `AuroraReplicaLag` メトリクスとして保存します。Aurora 向け CloudWatch メトリクスの使用については、「[Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。

Aurora リードレプリカおよび再起動のトラブルシューティングの詳細については、[AWS サポート センター](https://console.aws.amazon.com/support/home#/) の「[Amazon Aurora リードレプリカが遅れて再起動したのはなぜですか。](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/)」を参照してください。

## 例
<a name="aurora_replica_status-examples"></a>

次の例は、Aurora PostgreSQL DB クラスター内のすべてのインスタンスのレプリケーションステータスを取得する方法を示しています。

```
=> SELECT * 
FROM aurora_replica_status();
```

次の例は、`docs-lab-apg-main` Aurora PostgreSQL DB クラスター内のライターインスタンスを示しています。

```
=> SELECT server_id, 
    CASE 
        WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
        ELSE 'reader' 
    END AS instance_role
FROM aurora_replica_status() 
WHERE session_id = 'MASTER_SESSION_ID';
        server_id       | instance_role
------------------------+---------------
 db-119-001-instance-01 | writer
```

次の例では、クラスター内のすべてのリーダーインスタンスをリストします。

```
=> SELECT server_id, 
    CASE 
        WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
        ELSE 'reader' 
    END AS instance_role
FROM aurora_replica_status() 
WHERE session_id <> 'MASTER_SESSION_ID';
        server_id       | instance_role
------------------------+---------------
db-119-001-instance-02  | reader
db-119-001-instance-03  | reader
db-119-001-instance-04  | reader
db-119-001-instance-05  | reader
(4 rows)
```

次の例では、すべてのインスタンス、各インスタンスがライターより遅れている時間、および最後の更新からの経過時間をリストします。

```
=> SELECT server_id, 
    CASE 
        WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
        ELSE 'reader' 
    END AS instance_role,
    replica_lag_in_msec AS replica_lag_ms,
    round(extract (epoch FROM (SELECT age(clock_timestamp(), last_update_timestamp))) * 1000) AS last_update_age_ms
FROM aurora_replica_status()
ORDER BY replica_lag_in_msec NULLS FIRST;
       server_id        | instance_role | replica_lag_ms | last_update_age_ms
------------------------+---------------+----------------+--------------------
 db-124-001-instance-03 | writer        |         [NULL] |               1756
 db-124-001-instance-01 | reader        |             13 |               1756
 db-124-001-instance-02 | reader        |             13 |               1756
(3 rows)
```