扩展您的数据库可能令人生畏，但使用 Postgres 副本，就不必如此。数据库复制不仅可以确保高可用性，还有助于保持您的应用程序平稳运行，即使在意外的流量高峰或服务器故障的情况下也是如此。
虽然您可以在同一个数据中心本地维护您的副本，但理想情况下，副本应该位于地理位置不同的位置，以防出现严重的中断或灾难。
数据库副本不仅仅用于灾难恢复。虽然它是确保您在数据中心中断期间能够保持运行的最佳方式，但副本节点对于扩展和跨多个实例拆分工作负载，或将数据更靠近您的用户也很有用。
我们之前写过关于数据库副本的文章。从本质上讲，数据库副本是您数据库的副本。它可以用作只读副本、热备，甚至可以用作测试和性能节点。在配置复制时，您将一个节点指定为主节点，其他节点指定为副本节点。预写日志 (WAL) 通过维护对所有对数据库进行的更改（插入、更新和删除）的记录来保持同步。
副本可以通过在单独的数据中心或可用区保留数据库的完整副本，来提高灾难恢复能力。在中断期间，管理员可以故障转移到副本，并继续操作。PostgreSQL 不提供原生自动故障转移，因此这是管理员需要实现或做好准备的。 Timescale 可以通过多种方式帮助减轻此责任，具体取决于故障情况。
副本的另一个很好的用例是将数据库系统的负载拆分。例如，使用副本进行所有读取流量，可以在突然出现大量更新操作（如插入或回填大量数据）时，减少对应用程序的潜在影响。最终，这通过提高可靠性使最终用户受益。副本没有距离限制，因此您可以通过只读副本为用户提供更好的性能，无论他们在哪个大陆。
数据库副本的一个经常被忽略的用途是利用它们来创建测试环境。根据环境维护多个不同的数据集对组织来说可能很困难。使用生产环境数据库的副本来衡量负载和性能变化，可能更容易。非生产环境中的副本也非常适合在将更改合并到生产环境之前，在一个安全的环境中调整查询性能。
PostgreSQL 中有两种不同的复制类型：逻辑复制和物理复制。两者各有优缺点，以及最佳实践。逻辑复制会复制数据库中的数据和发生的更改，并将它们发送到副本以应用。物理复制通过将完整的 WAL 文件发送到副本，或使用 WAL 中记录的更改作为来源直接将更改流式传输到副本，来进行操作。
如前所述，还有“热备”或只读副本的概念。只读副本非常适合运行只读查询，同时维护一个可以在紧急情况下用作故障转移节点的数据库。
逻辑副本会复制整个数据库结构，然后对源数据库发生的每个更改进行复制。逻辑复制非常适合测试主要版本升级或限制用户对特定数据集的访问权限。
物理副本顾名思义，就是在另一台物理机上的整个数据库的副本。如前所述，这通常是通过发送 WAL 文件或将更改流式传输到目标数据库来完成的。这些副本非常适合异地备份和只读副本。由于更改可以在磁盘级别复制，因此您可以确保对每个数据库发生的更改将是相同的。
无论您使用的是物理复制还是逻辑复制，您都可以选择异步、同步写入或同步应用复制。根据风险级别，您可以选择不同的复制模式。例如，您只需要最终读取一致性，但需要支持大量的写入。在这种情况下，您可以选择异步复制，但要了解这种模式会带来一定程度的数据丢失，因为复制方式的本质就是如此。查看我们的关于流式复制的博文，如果您需要帮助在这些不同的模式之间进行选择。
复制可能很复杂，但幸运的是，我们可以分享一些最佳实践和要避免的陷阱，以降低管理此过程的难度。
在为 PostgreSQL 设置复制时，务必遵循最佳实践，以确保高可用性、数据完整性和最佳性能。其中最重要的方面之一是实现自动故障转移系统。故障转移协议对于在紧急情况下（例如硬件故障或网络中断）维护正常运行时间至关重要。
通过建立稳健的故障转移机制，您可以最大程度地减少停机时间，并确保您的应用程序即使在出现意外问题时也能正常运行。此外，将故障转移与定期备份相结合，可以提供两层保护系统，使您能够从数据丢失或损坏中恢复。故障转移允许在计划停机期间（例如软件更新或维护任务）保持稳定性。
值得注意的是，PostgreSQL 没有内置的故障转移工具。但是，有一些第三方解决方案可以帮助您在 PostgreSQL 环境中设置和管理故障转移。例如，Timescale 提供了一个基于 PostgreSQL 原生复制功能构建的复制和故障转移实现，为高可用性提供无缝且可靠的解决方案。
在设置复制时，另一个关键的考虑因素是为您的特定用例选择合适的复制模式。不同的复制模式提供不同级别的效率和一致性，选择合适的模式会对您系统性能产生重大影响。
例如，如果您的主要关注点是写入效率，则可以选择异步复制模式。这允许主服务器提交事务，而无需等待副本确认收到，从而提高写入性能。另一方面，如果您需要在写入性能和数据一致性之间取得平衡，则同步写入模式可能更合适。在此模式下，主服务器会在提交事务之前等待至少一个副本确认收到，从而确保所有节点的数据一致。
同步应用模式是要求最大读取一致性的应用程序的最佳选择。在此模式下，主服务器会在将事务视为已提交之前等待所有副本应用该事务，从而确保所有节点具有相同的数据状态。值得注意的是，您可以在每个事务的基础上更改复制模式，这使您能够根据每个操作的特定要求微调复制设置。
为了优化复制设置，了解和调整关键复制参数至关重要。这些参数会显著影响副本的性能和行为，因此在将它们部署到生产环境之前，应该进行深入测试。一些需要考虑的关键参数包括 max_wal_size、hot_standby、max_wal_senders, wal_keep_size 和 hot_standby_feedback。
max_wal_size 参数决定 WAL 文件在自动 WAL 文件回收发生之前的最大大小。调整此值会影响所需的存储空间量以及崩溃恢复所需的时间。
hot_standby 参数允许在副本服务器上进行只读查询，使您能够将读取工作负载从主服务器卸载。max_wal_senders 设置了副本的并发连接的最大数量，而 wal_keep_size 指定了要保留的 WAL 文件的最小大小，以供副本服务器使用。增加这些值可以支持更多副本，但可能会占用主服务器上的更多资源。最后，hot_standby_feedback 允许副本向主服务器发送有关其当前状态的反馈，有助于避免由于冲突而导致的查询取消。
监控您的副本对于确保其最佳性能以及紧急协议到位至关重要。有效的监控可以帮助您在问题影响应用程序的可用性或性能之前识别并解决问题。PostgreSQL 提供了各种内置监控工具和命令。
例如，EXPLAIN 命令可以帮助您分析查询性能，提供有关查询执行计划的见解。 pg_stat_activity 视图提供有关数据库中当前活动的信息，包括正在运行的查询及其关联的资源。
除了内置工具之外，还有许多第三方监控解决方案可用。这些工具通常提供更高级的功能和可视化，使监控和排查您的复制设置更加容易。 Timescale 提供监控仪表板，可以全面概述数据库的健康状况、性能和复制状态。这些仪表板可以帮助您快速识别瓶颈、检测异常情况并做出有关扩展和优化的明智决策。
在实施复制时，需要注意几个陷阱，这些陷阱会影响副本的性能和一致性。一个常见的问题是大量写入负载对复制过程的影响。当主服务器遇到大量写入查询时，它可能会减慢副本的速度，因为副本难以跟上传入的更改。
在这种情况下，副本可能会变得不同步，导致数据不一致，或者它们可能会等待 WAL 复制赶上，从而导致延迟增加。为了缓解此问题，将大型写入查询分解成较小的批次是最佳选择，这将使副本能够更有效地处理更改并与主服务器保持更好的同步。
另一个潜在的陷阱是使用源表上的排他锁。当查询在主服务器上的表上获取 ACCESS EXCLUSIVE 锁时，副本必须等到锁释放后才能重放更改。这会导致复制过程中出现重大延迟，尤其是在锁被保持很长时间的情况下。
要识别和解决此类延迟，您可以使用 pg_locks 视图来监控锁活动并相应地调整您的查询。您可以通过最大程度地减少排他锁并确保它们及时释放来防止复制延迟并保持更具响应性的副本环境。
读取复制不同步是另一个常见陷阱，主要是在使用读取副本时出现，此时数据一致性至关重要。如果读取副本配置不正确或经常出现延迟，它可能会向应用程序提供陈旧或不一致的数据。这会导致查询结果不正确，并导致糟糕的用户体验。
为了避免此问题，务必确保您的读取副本配置正确并适合您的特定用例。如果您的应用程序需要近乎实时的數據一致性，则具有重大延迟的读取副本可能不是正确选择。在这种情况下，可能需要探索其他复制策略或调整应用程序对略微陈旧数据的容忍度。
Timescale 提供了一系列工具和功能，简化数据库复制并改善整体体验。使用 Timescale，创建副本是一个简单的过程，这得益于直观的工具和文档。我们有一个关于 PostgreSQL 数据库复制的综合指南，其中将指导用户完成设置和管理副本的步骤。如前所述，Timescale 提供了 本地故障转移功能，确保高可用性并在主服务器发生故障时最大程度地减少停机时间。
监控副本对于维护健康的、高性能的复制设置至关重要。Timescale 提供了一个用户友好的副本监控界面，允许用户轻松跟踪其副本的状态和性能。副本上的指标（如 CPU、内存使用率、复制延迟等）很容易获取。
Timescale 还利用逻辑复制来促进无缝的平台转换和迁移。使用逻辑复制，用户可以在不同的数据库版本之间复制数据，使其成为最小停机时间迁移数据库的理想工具。 这篇关于将太字节级 PostgreSQL 数据库迁移到 Timescale 的博文 展示了无需停机时间进行迁移是多么容易。
在本指南中，我们了解了数据库复制的重要性以及最大程度地发挥其价值的最佳实践。副本确保了高可用性、流畅的性能以及将工作负载分散到多个实例的能力。我们简要探讨了不同类型的复制，例如逻辑复制和物理复制，以及各种模式，例如异步、同步写入和同步应用。然后，我们深入研究了使用复制时发现的最佳实践和常见问题。
最佳实践包括实施自动故障转移、选择正确的复制模式、调整关键参数以及有效地监控副本。我们还讨论了常见陷阱，例如大量写入负载、排他锁和读取副本不同步，以及缓解这些陷阱的策略。
最后，我们了解了 Timescale 如何通过直观的工具、本地故障转移功能和用户友好的监控界面来简化复制。通过利用这些功能并遵循最佳实践，用户可以创建健壮且高效的复制设置，从而增强其数据库的性能、可靠性和可扩展性。
立即免费试用，看看使用 Timescale 进行复制是多么容易。
