在生产环境中扩展 PostgreSQL 时，您可能会遇到两个问题
您需要一种机制来确保您的生产数据库在出现问题时保持正常运行，以避免用户遇到停机。
您的工作负载变得非常繁重，您必须分散读写操作，以避免耗尽机器并导致问题。
好消息是，PostgreSQL 中的复制可以帮助您解决这两个问题。在本指南中，我们将回顾数据库复制、使您的数据库具有高可用性的策略以及 Timescale 如何简化操作。
PostgreSQL 复制有两种不同的形式：逻辑复制和物理复制。这两种方式都有优点和缺点，以及最佳实践。让我们深入了解。
逻辑复制复制数据库中的数据对象以及对它们的更改。它从源 (发布者) 上的数据快照开始，并将其复制到目标 (订阅者)。快照完成之后，更改会实时发送到订阅者，并按与发布者相同的顺序应用 - 这保证了事务一致性。
PostgreSQL 文档 列出了逻辑复制的一些典型用例。在我的经验中，一些常见用例包括
在运行不同主要版本的 PostgreSQL 的数据库之间复制数据
将多个数据库合并到单个数据库中
为不同的用户组提供对数据子集的访问
使用逻辑复制的好处是，它可以用于从数据库中复制非常细粒度的数据片段。它也适用于级联复制或使用订阅者数据库作为发布者数据库，如果您想要维护基于地理位置的读副本以提高性能，这可能非常有用。最后，如上所述，逻辑复制是迁移主要 PostgreSQL 版本之间的一个好方法。与逻辑复制相关的负面影响是，它在较大的数据集上通常设置起来比较慢。在可写订阅者数据库上，存在发生冲突的可能性，这将最终停止复制，并且需要人工干预才能重新启动。
Timescale 在从 PostgreSQL 到 Timescale 数据库迁移时使用逻辑复制。使用 pgcopydb（一种逻辑解码工具），Timescale 可以迁移具有 TB 级数据的数据库，几乎没有停机时间，正如我们在博客文章中所展示的：“将 TB 级 PostgreSQL 数据库迁移到 Timescale，几乎没有停机时间。”
物理复制以两种方式运行：基于文件的日志传输和流式复制。这两种方法都使用预写日志 (WAL) 来实现复制。
基于文件的日志传输在将 WAL 文件发送到订阅者数据库之前等待 WAL 文件被填满。由于要等待完整的 WAL 文件，因此通常会存在延迟，这会导致潜在的数据丢失窗口。
流式复制 在生成 WAL 记录时将其发送到订阅者。这种方法具有更短的数据丢失窗口。但是，它设置起来更复杂。您还需要注意，如果流式连接断开，复制可能会延迟或停止。
Timescale 允许用户轻松配置流式复制，并提供详细的文档 来介绍如何操作。
复制在实现具有高可用性的 PostgreSQL 数据库中发挥着至关重要的作用 - 确保它保持在线可能是您取得成功的关键。高可用性 (HA) 的核心概念是在基础设施中的另一台服务器上维护主数据库的副本。
在我们的 文档 中，我们讨论了备份、冗余、复制和故障转移的必要性。我们还在博客文章中讨论了 PostgreSQL 中的数据库备份和灾难恢复，因此，如果您对这在 Timescale 中是如何工作的有任何疑问，我强烈建议您阅读该文章。
现在，让我们更深入地探讨实现高可用性，我们需要谈论故障转移。如果主数据库出现问题，系统应将请求转移到副本数据库或进行故障转移。在计划的故障转移情况下，主数据库会正常关闭，副本会无缝接管成为新的主数据库。在计划外的故障转移情况下，架构需要考虑各种故障场景，以最大程度地减少应用程序的停机时间。Timescale 会在检测到任何类型的故障时自动为您处理。
虽然这个概念看似很简单，但需要考虑几个复杂因素
缺少原生故障转移：PostgreSQL 缺少内置的故障转移系统。因此，管理员必须选择和实现外部解决方案来有效地处理故障转移场景。
故障后重新建立 HA：为了维护高可用性系统的完整性，必须在主数据库故障后重新建立它。虽然这可以自动化，但它需要额外的实施时间和持续维护来确保其有效性。在真正的故障转移事件中，这经常会被忽略。
自动故障转移和复制：自动化在 HA 中发挥着至关重要的作用。与定期备份相结合，副本可以确保最小的停机时间，甚至在出现严重错误的情况下也是如此。自动化保证故障转移过程快速准确地进行，减少人工干预和潜在的错误。
Timescale 提供了一个 优雅的解决方案 来创建副本和设置故障转移机制。它通过提供一个自动故障转移机制来简化流程，该机制在主数据库切换时会自动重置。此功能大大降低了与手动故障转移管理相关的复杂性。
我们在之前关于 逻辑和物理备份 的文章中简要讨论了读副本。鉴于我们对复制的关注，以及它与读副本的使用方式有关，这是一个更深入探讨该功能的好机会。虽然读副本通常与高可用性相关联，但它们在分布读查询的工作负载方面同样有用。这意味着，当写入查询被定向到主数据库中的预写日志 (WAL) 时，读取查询可以从流式副本中同样高效地获取数据。
将读取请求发送到副本服务器就像将负载分散到多个肩膀上一样。这种查询负载的分配有助于提高数据库的整体速度和响应能力。它可以防止主数据库服务器过载，从而确保它始终可用于关键写入操作。
另一个使用读副本的令人信服的理由是安全性。读副本本质上是只读的，这使得它们非常适合委派给不应该具有写入权限的实用程序。它们也非常适合授予那些可能永远不需要向数据库写入数据的用户（例如商业智能团队）的读取权限。通过将这些请求发送到读副本，可以维护数据库的安全性及其完整性。
在 PostgreSQL 中，创建“热备用”服务器是一个简单的过程。 官方 PostgreSQL 文档 提供了有关使用副本设置热备用服务器的明确指南。第一步就是将 hot_standby 参数设置为 true。完成此操作后，服务器将准备好在处理读取请求。
为了充分利用读副本的潜力，您可以管理哪些查询被定向到哪个服务器。这种行为与优化引擎以提高某些数据类型的获取方面的性能相结合，可以提高性能。
监控连接以确保响应是最新的且一致的至关重要。此外，必须立即解决主服务器和备用服务器之间可能发生的任何冲突，以维护数据完整性。在 Timescale 中了解有关 读取扩展 的更多信息。
如果这看起来像是需要花费大量时间的过程，那是因为它确实如此——而这正是托管数据库派上用场的地方。因此，对于那些寻求无缝解决方案的人来说，Timescale 提供了一种更方便的方法，在主数据库发生故障时，它将在后台处理所有需要切换到副本的工作。
让我们更详细地解释一下。在 Timescale 中，您会发现两种类型的副本
高可用性副本，其主要目标是在发生故障时提供更高的可用性，尽管也可以从它们那里提供读取操作。如前所述，它们在发生故障时会自动提升。
读副本，其主要目标是读取扩展。根据您的工作负载需求，它们可以与主副本具有不同的配置大小，并且您可以拥有多个副本。
我们对构建可靠且高度可用的数据库的承诺始于我们的架构：面对故障，Timescale 会自动启动一个新的计算节点，并将其重新连接到现有的解耦数据库存储，该存储本身会独立复制以实现高可用性和持久性。
即使没有启用副本，这种云原生架构也可以在 30-60 秒内为许多类型的故障提供完全恢复，而更严重的物理服务器故障通常只需要几分钟的停机时间来恢复您的数据库。
在 Timescale 中，数据库复制就像按几个按钮一样简单。以下是在 Timescale 中创建高可用性副本的方法
登录您的 Timescale 帐户，然后单击您要复制的服务。
导航到“操作”选项卡，然后选择“高可用性”。
查看副本的价格，然后单击“添加副本”。通过单击“添加副本”确认操作。
您可以通过单击服务名称，导航到“操作”选项卡，然后选择“高可用性”来查看每个服务的副本。副本不会显示在主“服务”部分中，因为它们不是独立的。
您可以通过导航到“概述”选项卡来查看副本的连接信息。在“连接信息”部分，从“角色”下拉菜单中选择副本以使用副本的连接详细信息填充该部分。
一切就绪！
在本篇博文中，我们深入探讨了 PostgreSQL 数据库复制的世界，揭示了它在确保高可用性、负载分配和安全性方面的至关重要作用。掌握了这些知识，您现在可以做出明智的决策，确定哪些复制系统与您的特定需求和要求相符。
无论您是想实施手动复制解决方案，还是寻求自动化管理的简便性，PostgreSQL 都提供了一个通用的框架来满足您的数据库复制需求。
Timescale 简化了 PostgreSQL 复制，提供了一种无缝的自动化方法，不仅可以确保高可用性，还可以为读取操作提供热备用。使用 Timescale，您可以专注于优化数据库的查询分配和性能，从而使您能够在无需手动管理的复杂性的情况下充分利用 PostgreSQL 的潜力。
注册 以使用 Timescale 的复制服务，并了解数据库复制可以多么轻松。 创建免费帐户，以提升您的 PostgreSQL 体验，并享受增强的高可用性和工作负载分配带来的安心。
