保证数据库的高可用不止是平常事务,而是首要任务。(Ensuring that databases are highly available is not just a thing these days, it’s the thing. )
无论是计划内的还是计划外的停机,对终端用户来说都是很难接受的。停机的后果可能很严重,可能包括客户流失、声誉受损或不符合服务水平协议 (SLA) 被处罚。因此,使数据库具有高可用性是你需要正确处理的重中之重。好消息是,你可以使用开源数据库构建出色的高可用性 (HA) 解决方案。我们将很快谈到这一点,但让我们从一些基础知识开始。
高可用性是指系统的持续运行,以便为最终用户提供的服务在很大程度上不会中断。基本的高可用性数据库系统提供从主数据库节点到集群内冗余节点的故障转移(最好是自动的)。
HA有时会与“容错”混淆。尽管两者是相关的,但关键区别在于HA系统提供了所有系统组件的快速恢复,以最大限度地减少停机时间。可能会发生一些中断,但会是最小的中断。容错旨在实现零停机和零数据丢失。因此,容错的实施成本要高得多,因为它需要完全反映主系统的专用基础架构。它还需要大量资源来维护它。
实现数据库HA解决方案取决于将三个关键原则付诸实践:
1.单点故障 (SPOF) – 消除数据库环境中的任何单点故障,包括数据库系统所依赖的可能导致其失败的物理或虚拟硬件。
2.冗余 – 确保数据库环境中所有组件的足够冗余,并在发生故障时可靠地交叉到这些组件。
3.故障检测——监控整个数据库环境的故障。
HA不能保证100%的正常运行时间,但它可以让你非常接近。在IT业内,高可用性的黄金标准是99.999%或“五个九”的可用性,但所需的HA级别实际上取决于你可以承受多少停机时间。例如,流媒体服务,运行关键任务系统,过多的停机时间可能会给企业带来重大的财务和声誉损失。但许多组织可以容忍几分钟的停机时间,而不会对其最终用户产生负面影响。
下表显示了从2个9到5个9的每个可用性级别的停机时间。
Availability % | 每年停机时间 | 每月停机时间 | 每周停机时间 | 每天停机时间 |
---|---|---|---|---|
99% | 3.65天 | 7.31小时 | 1.68小时 | 14.40分钟 |
99.5% | 1.83天 | 3.65小时 | 50.40分钟 | 7.20分钟 |
99.9% | 8.77小时 | 43.83分钟 | 10.08分钟 | 1.44分钟 |
99.95% | 4.38小时 | 21.92分钟 | 5.04分钟 | 43.20秒 |
99.99% | 52.60分钟 | 4.38分钟 | 1.01分钟 | 8.64秒 |
99.995% | 26.30分钟 | 2.19分钟 | 30.24秒 | 4.32秒 |
99.999% | 5.26分钟 | 26.30秒 | 6.05秒 | 864.00毫秒 |
并非所有公司都是相同的,它们对HA的要求也不同。在规划数据库HA架构时,公司的规模是开始评估需求的好地方。例如,如果一家小型企业,则可能没有必要为本地数据中心之外的灾难恢复站点付费,这可能会导致花费的钱超过数据丢失的价值。所有公司,无论规模大小,都应考虑如何在可用性目标和成本之间取得平衡。
1.初创和小型企业。大多数初创和小型企业都可以在本地节点上的单个数据中心内实现有效的HA基础架构。这种基础架构可以在主节点出现故障时为应用程序提供可用的数据库,无论这涉及在发生灾难时的自动故障转移还是在维护窗口期间的计划切换。
2.大中型企业。如果有更多预算,请考虑在本地数据中心之外添加一个灾难恢复站点。这种架构跨越数据中心,为数据库集群增加了更多的可用性层。即使主数据中心出现问题,它也能让你的基础架构保持可用,并使你的数据安全一致。除了灾难恢复站点之外,此设计还包括一个外部节点层,因此如果站点之间的通信丢失,外部节点层充当“事实来源”并决定将哪个副本提升为主要副本。这样做,它通过防止脑裂情况来保持集群的健康,并保持基础设施的高可用性。
3.企业。企业HA架构为拥有额外资源的公司增加了另一层保险;对那些提供全球分布服务的他们来说,停机意味着毁灭性的收入和声誉损失。他们具有两个灾难恢复站点,为基础架构添加了更多层,以保持高可用性并保持应用程序正常运行。这种架构基于分布在数据中心和地理可用性区域的紧密耦合的数据库集群,在与同步流复制、所有节点的相同硬件配置和快速的节点间连接一起使用时,可以提供99.999%的正常运行时间。
关于数据库高可用性的一个常见问题是哪个数据库最好。如果计划使用专有数据库,请注意,由于繁重的合同以及与数据可移植性损失相关的高成本(例如,过高的云出口费用),你可能将面临供应商锁定。
HA是一个重要目标,但切换到仅用于HA的专有数据库会限制开源的其他好处。除了支持强大的数据库HA架构之外,开源还避免了昂贵的许可费用,提供数据可移植性,让你可以随时随地自由部署,并提供由优先考虑创新和质量的贡献者社区设计的优秀软件。
Postgres、MariaDB、MySQL和Redis等开源数据库是HA的绝佳选择,但通常不包含内置的HA解决方案。这意味着需要仔细查看可用的各种扩展和工具。这些扩展和工具非常适合丰富各自的数据库,但是随着你的环境扩展,可能无法跟上不断发展的、更复杂的需求。
更高的复杂性意味着你和你的团队将需要某些技能和知识,例如,如何编写应用程序连接器、集成多个系统以及使业务需求与你的HA解决方案保持一致。还应该了解开源数据库、应用程序和基础架构。考虑可能需要外部专业知识来帮助你管理HA架构。
确定适合数据库环境的高可用性解决方案在很大程度上取决于你的目标。了解Percona高可用性数据库支持可以查看以下网址:https://www.percona.com/services/support/high-availability
如果PostgreSQL是你选择HA的数据库,请在我们的电子书《使用开源工具在PostgreSQL上实现高可用性》中了解如何仅使用经过实战考验的开源组件构建高可用性 PostgreSQL。(https://www.percona.com/resources/ebooks/achieving-high-availability-postgresql-open-source-tools)