原文地址：https://blog.crunchydata.com/blog/database-terminology-explained-postgres-high-availability-and-disaster-recovery
原文作者： MIKE PALMIOTTO
翻译：Maleah
在日常工作中，我周围都是优秀的数据库工程师。他们谈论诸如高可用HA、raft协议的东西，配置同步vs.异步复制的正确及错误的方式。这些深层次的技术知识上有很大的价值，但是当和一些客户沟通时，我更倾向于简化一下。我所看到的是，对于所多人来说，关键数据库原则的基础知识可能会迷失在细节中。以下就是我和客户就如何去考虑数据库管理的关键租户的对话摘要：高可用性和故障恢复。
高可用性意味着什么？
高可用通常意味着需要有一个”永远在线“的关键业务应用。意味着需要有一个或多个备用服务器和有一个自动故障转移的系统来实现业务的连续性。在数据库的高可用的情况下，你的核心数据需要至少存在两个独立的环境中，所有的数据都要保持最新的，并且在主数据库故障时，至少有一个准备好切换为主节点。
弹性和它有什么关系？
我从事足够长时间的技术工作，能够记住正常运行时间的百分比和包含停机时间条款的合同，这些条款涵盖了停机时间的情况。如今，停机的事故很少，对高可用性的关注也已经从停机时间/正常运行时间指标变为测量系统的故障转移到备机的速度。这通常称为弹性。你应该去寻找足够弹性的高可用的解决方案：在几秒内故障转移到一个新的主节点。如果测量的在数分钟或数小时，这不是高可用。
你将会经常听到关于高可用性故障转移时间和弹性的两个指标。一个是RPO（Recovery Point Objective）即数据恢复点目标，指的是备份和事故之间的时间，所以它衡量数据丢失量的容忍度。对于一些业务可能是几小时或几分钟，对于其他业务可能是几秒钟。RTO(Recovery Time Objective)即恢复时间目标，是从故障到服务恢复的时间度量，衡量目标恢复的时间。
个人理解：
i.RPO (Recovery Point Objective）即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。
ii.RTO(Recovery Time Objective）即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
故障恢复不仅仅是可用性
故障恢复(DR)是高级别的术语，指的是一个公司应对故障时的计划：自然事件，安全攻击，还是其他类型的重大故障。即使上云的数据库也是运行在一些物理的基础设施上……而不是在空中。这意味着类似飓风这样的事故也会把AWS东部这样的地方置于危险之中，就像数年前看到的那样。备份是故障恢复的基石。PostgreSQL有许多管理备份的功能，包括日志文件恢复、全备和基于时间点的恢复。pgBackRest是一个最受喜爱的项目，Crunchy的开发者是其中的一些主要贡献者。
谈起备份，需要熟悉PITR基于时间点的恢复。该系统的总体思路是，参考一个特定实践点进行一系列的备份，并且可以恢复到其中之一，具体取决于发生的故障类型。
通常HA是更大的故障恢复计划和系统的一部分，所以为你的数据设置HA也可以满足故障恢复需求。可能有些组织不需要HA实现其DR目标。所以总的来说，我认为HA是DR，然后是其他
架构
由于一个高可用场景要求有多个独立的数据备份，因此需要考虑托管数据的机器更高级别的架构。也需要去考虑你的实例是如何分离开的。如果你的数据库在VM上，不想在相同的数据中心或者云节点去创建另一台虚拟机，因为在这种情况下，可能会和主节点有相同的服务丢失。通常情况下，对于云托管，在单独的数据中心（或cloud terms availability zone）保留一个实例。对于弹性的极端情况下，可以考虑跨区域甚至通过跨云供应商进行复制。
复制
谈起高可用，绝对会提到复制，指的是保持数据库相互更新的机制。显然，在合理的时间移动数据是一个挑战，同时也要最小化数据的延迟。如果必须故障转移到备份的数据，希望的是数据已经准备就绪。有可靠的数据复制实践可确保在主数据位置发生故障时，有一个备份准备好承担工作负载。
PostgreSQL的复制有两种模式：同步和异步。同步复制是在存储数据时将数据写入多个位置。异步复制是将日志数据写入副本，通常这意味着写入复制信息可能会有一点延迟。
默认情况下PostgreSQL使用异步复制的方式来提高性能。PostgreSQL的日志数据来自wal(write-ahead-log)文件，异步流复制通常被视为性能的理想选择。
对于查看各种的复制以及如何去实现有一个很棒的资源- the Comparison Matrix
关于复制的现代命名法
如果去google这个话题，将会看到描述相同事情的各种不同的单词。我经常听到的术语就是‘master’和‘slave’，‘multi master’也会频繁听到。有些现代术语已经被弃用，例如’primary’指的是主数据源，'replica’是次要备份实例。同样，'active’和’standby’也有类似的用途。Active是指读写的实例，'standby’是备份实例，在需要的情况下可以进行读写。我也听到过’active’和’standby’指的是数据中心，因此’active’可能指的是PostgreSQL的两个active写入实例或两个数据中心。
监控&告警
监控也是高可用环境下的关键，因为集群自己也需要了解什么时候是不可用的并且需要采取措施进行自我修复。我们也推荐使用仪表板去监控整套系统的健康和集群的状态。即使你不是一个DBA或者系统工程师，也要尝试访问监控和仪表板。也应该计划着在一些重大事故，停机、故障切换、甚至高的CPU使用率等都要向关键的员工和利益相关者告警。任何好的HA系统都会内置自动告警。
容器化
如果谈论到现代架构，你也可能会听到容器。Kubernetes 技术和容器化趋势没有从根本上改变高可用性。这些术语和复制机制基本相同。最大的不同是实例的配置作为Kubernetes 清单的一部分存在，理想情况下，由 Postgres Operator的类似工具进行编排。故障转移机制总体上保持相似，并且可以利用Kubernetes等平台提供的基础设施
高可用组件
在高层次上，对于高可用数据库的架构，你将有以下组件：
- 主数据库有一个或多个副本
- 集群管理和配置软件
- 有保持对外的IP的工具，在发生故障转移到新的数据库服务器时不用更新app代码。这可能是弹性IP、代理或者其他的DNS配置
- 每个实例的监控、仪表板和告警实例
- 备份系统
总结
有关HA的具体知识和内容总是复杂的。你也可以将HA PostgreSQL归结为几个关键主题：监控、备份、复制。
对于那些不想深入了解同步异步复制以及RPO、RTO细节的人来说，我们希望这本入门书有助于揭开一些神秘面纱。对于想要深入了解并且有问题的人，如果你需要帮助的话可以免费联系我们。
