# 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` – 数据库实例 ID（标识符）。
+ `session_id` – 当前会话的唯一标识符，针对主实例和读取器实例返回，如下所示：
  + 对于主实例，`session_id` 始终为 ``MASTER_SESSION_ID’`。
  + 对于读取器实例，`session_id` 始终为读取器实例的 `UUID`（通用唯一标识符）。
+ `durable_lsn` – 保存在存储中的日志序列号 (LSN) 。
  + 对于主卷，该值是当前生效的主卷持久性 LSN (VDL) 。
  + 对于任何辅助卷，该值是已成功应用辅助卷的主卷的 VDL。
**注意**  
日志序列号 (LSN) 是标识数据库事务日志中的记录的唯一序列号。对 LSN 进行排序，以便较大的 LSN 表示序列中较晚发生的事务。
+ `highest_lsn_rcvd` – 数据库实例从写入器数据库实例收到的最高（最新）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 中，您所连接的数据库实例的 `last_update_timestamp` 值设置为 `NULL`。
+ `feedback_xmin` – 副本的热备用 feedback\$1xmin。数据库实例使用的最小（最早）活动事务 ID。
+ `feedback_epoch` – 数据库实例在生成热备用信息时使用的纪元。
+ `replica_lag_in_msec` – 读取器实例滞后于写入器实例的时间（以毫秒为单位）。
+ `log_stream_speed_in_kib_per_second` – 日志流吞吐量（以每秒千字节为单位）。
+ `log_buffer_sequence_number` – 日志缓冲区序列号。
+ `oldest_read_view_trx_id` – 未使用。
+ `oldest_read_view_lsn` – 数据库实例用于从存储中读取的最早 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 数据库集群的副本状态管理器返回值。您可以使用此函数获取有关 Aurora PostgreSQL 数据库集群上复制状态的信息，包括 Aurora 数据库集群中所有数据库实例的指标。例如，您可以执行以下操作：
+ **获取有关 Aurora PostgreSQL 数据库集群中实例类型（写入器、读取器）的信息** – 您可以通过检查以下列的值来获取此信息：
  + `server_id` – 包含创建实例时指定的实例名称。在某些情况下，例如对于主（写入器）实例，通常会通过在为 Aurora PostgreSQL 数据库集群创建的名称后面附加 *-instance-1* 来为您创建名称。
  + `session_id` – `session_id` 字段指示实例是读取器还是写入器。对于写入器实例，`session_id` 始终设置为 `"MASTER_SESSION_ID"`。对于读取器实例，`session_id` 已设置为特定读取器的 `UUID`。
+ **诊断常见的复制问题，例如副本滞后** – 副本滞后是指读取器实例的页面缓存落后于写入器实例页面缓存的时间（以毫秒为单位）。出现此滞后的原因是 Aurora 集群使用异步复制，如 [使用 Amazon Aurora 进行复制](Aurora.Replication.md)中所述。它显示在该函数返回的结果中的 `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://www.amazonaws.cn/rds/aurora/faqs/#High_Availability_and_Replication)。

  Amazon CloudWatch 会随着时间的推移存储 `replica_lag_in_msec` 结果，作为 `AuroraReplicaLag` 指标。有关将 CloudWatch 指标用于 Aurora 的信息，请参阅[使用 Amazon CloudWatch 监控 Amazon Aurora 指标](monitoring-cloudwatch.md)。

要了解有关 Aurora 只读副本故障排查和重新启动的更多信息，请参阅 [Amazon Web Services 支持 中心](https://console.amazonaws.cn/support/home#/)内的[为什么我的 Amazon Aurora 只读副本滞后并重新启动？](https://www.amazonaws.cn/premiumsupport/knowledge-center/aurora-read-replica-restart/) 

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

以下示例说明如何获取 Aurora PostgreSQL 数据库集群中所有实例的复制状态：

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

以下示例显示 `docs-lab-apg-main` Aurora PostgreSQL 数据库集群中的写入器实例：

```
=> 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)
```