使用 Amazon Aurora PostgreSQL 进行复制
接下来，可以找到有关使用 Amazon Aurora PostgreSQL 进行复制的信息，包括如何监控和使用逻辑复制。
主题
使用 Aurora 副本
Aurora 副本是 Aurora 数据库集群中的独立端点，最适合用于扩展读取操作以及提高可用性。Aurora 数据集群可以包含位于 Aurora 数据库集群AWS区域的整个可用区中的最多 15 Aurora 个副本。
数据库集群卷由该数据库集群的多个数据副本组成。不过，集群卷中的数据，对于主要写入器数据库实例和数据库集群中的 Aurora 副本表示为单个逻辑卷。有关 Aurora 副本的更多信息，请参阅 Aurora 副本。
Aurora 副本十分适用于读取扩展，因为它们完全专用于集群卷上的读取操作。写入器数据库实例管理写入操作。集群卷在 Aurora PostgreSQL 数据库集群中的所有实例之间共享。因此，无需额外地复制每个 Aurora 副本的数据副本。
对于 Aurora PostgreSQL，在删除 Aurora 副本时，系统将立即删除其实例端点，并将 Aurora 副本从读取器端点中删除。如果在正待删除的 Aurora 副本上运行语句，则有 3 分钟宽限期。现有语句可在此宽限期内正常完成。当此宽限期结束后，将关闭并删除 Aurora 副本。
Aurora PostgreSQL 数据库集群支持不同 AWS 区域中使用 Aurora Global Database 的 Aurora 副本。有关更多信息，请参阅 使用 Amazon Aurora Global Database。
注意
有了改进的读取可用性功能，如果您想重启数据库集群中的 Aurora 副本，您必须手动执行此操作。对于在此功能之前创建的数据库集群，重启写入器数据库实例会自动重启 Aurora 副本。自动重启将重新建立可以保证整个数据库集群读取/写入一致性的入口点。
提高 Aurora 副本的读取可用性
Aurora PostgreSQL 通过在写入器数据库实例重新启动或 Aurora 副本无法跟上写入流量时持续提供读取请求，来提高数据库集群的读取可用性。
原定设置情况下，读取可用性功能在以下版本的 Aurora PostgreSQL 上可用：
16.1 及所有更高版本
15.2 及更高的 15 版本
14.7 及更高的 14 版本
13.10 及更高的 13 版本
12.14 及更高的 12 版本
Aurora Global Database 的以下版本支持读取可用性功能：
16.1 及所有更高版本
15.4 及更高的 15 版本
14.9 及更高的 14 版本
13.12 及更高的 13 版本
12.16 及更高的 12 版本
对于在推出读取可用性功能之前在其中一个版本上创建的数据库集群，要使用该功能，请重新启动数据库集群的写入器实例。
修改 Aurora PostgreSQL 数据库集群的静态参数时，必须重新启动编写器实例，以便参数更改生效。例如，当您设置 shared_buffers 的值时，必须重新启动写入器实例。随着 Aurora 副本可用性提高，数据库集群在这些重新启动期间保持读取可用性，从而减少更改写入器实例所带来的影响。读取器实例不会重新启动和继续响应读取请求。要应用静态参数更改，请重启每个单独的读取器实例。
Aurora PostgreSQL 数据库集群的 Aurora 副本可以通过在与写入器重新连接后快速恢复到内存数据库状态，从写入器重新启动、失效转移、缓慢复制和网络问题等复制错误中恢复。这种方法允许 Aurora 副本实例在客户端数据库仍然可用时与最新的存储更新保持一致。
与复制恢复冲突的正在进行的事务可能会收到错误，但客户端可以在读取器赶上写入器后重试这些事务。
监控 Aurora 副本
从写入器断开连接中恢复时，您可以监控 Aurora 副本。使用以下指标检查有关读取器实例的最新信息，并跟踪进行中的只读事务。
aurora_replica_status函数会更新，以便在读取器实例仍处于连接状态时返回该实例的最新信息。对于与用于执行查询的数据库实例对应的行，aurora_replica_status中的最后一次更新时间戳始终为空。这表明读取器实例具有最新的数据。当 Aurora 副本与写入器实例断开连接并重新连接时，会发出以下数据库事件：
Read replica has been disconnected from the writer instance and reconnected.当由于恢复冲突而取消了只读查询时，您可能会在数据库错误日志中看到以下一条或多条错误消息：
Canceling statement due to conflict with recovery.User query may not have access to page data to replica disconnect.User query might have tried to access a file that no longer exists.When the replica reconnects, you will be able to repeat your command.
限制
以下限制适用于可用性得到改进的 Aurora 副本：
如果在复制恢复期间无法从写入器实例流式传输数据，则可以重新启动辅助数据库集群的 Aurora 副本。
如果一个 Aurora 副本已在进行中并将重新启动，则 Aurora 副本不支持在线复制恢复。
当您的数据库实例接近事务 ID 重叠时，Aurora 副本将重新启动。有关事务 ID 重叠的更多信息，请参阅防止事务 ID 重叠故障
。 在某些情况下，当复制过程受阻时，Aurora 副本可能重新启动。
监控 Aurora PostgreSQL 复制
读取扩展和高可用性依赖于尽可能短的滞后时间。您可以通过监控 Amazon CloudWatch ReplicaLag 指标来监控 Aurora 副本滞后于 Aurora PostgreSQL 数据库集群写入器数据库实例的时间。由于 Aurora 副本从写入器数据库实例所在的同一个集群卷读取数据，因此 ReplicaLag 指标对于 Aurora PostgreSQL 数据库集群有不同的含义。Aurora 副本的 ReplicaLag 指标表示 Aurora 副本的页面缓存相较写入器数据库实例页面缓存的滞后时间。
有关监控 RDS 实例和 CloudWatch 指标的更多信息，请参阅监控 Amazon Aurora 集群中的指标。
