14. ClustrixDB 高可用性的最佳实践

本文档详细介绍了最大化ClustrixDB上运行的应用程序正常运行时间的最佳实践。这涵盖了广泛的主题，从环境需求到变更管理程序，所有这些最终都会影响应用程序的可用性。其中许多是您可能已经熟悉的标准最佳实践或概念。

小心控制环境和应用程序更改
消除单点故障
提供足够的额外资源，以便在发生故障时能够继续运行
定期制定和测试备份和恢复计划

使用多个操作环境

一个运营成熟的组织可能有多达四种不同的环境:

生产
异地容灾
测试
开发

了获得最高的可用性，生产环境可能包含一对相同的集群，它们在主控配置中进行复制。只有一个集群应该主动接受写操作，而另一个集群可以立即进行故障转移(主动/被动);或者，如果存在不同的应用程序或数据库，则可以将这些应用程序或数据库配置为一个集群对一组应用程序是活动的，而另一个集群对另一个集群是活动的。让两个集群都进行写操作(活动/活动)是可能的，但是会带来一些操作上的挑战(请参阅主从复制)。管理从一个集群到另一个集群的应用程序负载转移，可以通过使用外部负载平衡器来处理，也可以通过重新配置应用程序服务器来处理。

异地容灾环境通常位于地理位置不同的位置，包括从生产环境复制的集群，以及能够在生产环境的站点级故障时提供站点功能(可能会降低性能)的应用服务器。

测试环境通常是生产环境(按比例缩小)的复制品，包括可比较的应用服务器和数据集。它用于验证应用程序软件的更改以及ClustrixDB软件的升级。准备环境的一个关键部分是测试自动化框架，它允许在生产环境中使用接近峰值负载的负载来运行应用程序和数据库。

开发环境允许进行更多的特别开发，其中开发人员相互干扰工作的风险是无关紧要的。

为了实现最佳的正常运行时间目标，Clustrix强烈建议使用多个集群，它们可以提供以下功能:

将应用程序开发与生产数据库隔离
分析工作负载与时间关键型事务工作负载的隔离
用于站点范围内停机的灾难恢复/业务持续故障转移
应用程序更改和ClustrixDB软件升级的预生产验证

高可用性生产环境

为了充分利用ClustrixDB的容错架构，应该满足以下环境和供应要求:

每个节点的电源应该连接到一个单独的电源电路
每个生产集群应该有两个后端网络交换机
每个后端网络交换机应连接到一个单独的电源电路
每个节点应该通过两个以太网端口(接口是绑定的)连接到生产网络，再连接到两个独立的以太网交换机
应该配置集群节点，以便在节点发生故障时满足存储和并发性需求。应该配置专区来隔离故障。

变更管理

绝大多数软件故障都是由应用程序行为的变化引起的，可能是由于应用程序本身的错误，也可能是由于底层(如数据库)中的错误的暴露。因此，最佳实践是首先在非生产环境中彻底验证这些更改，然后小心地将这些更改部署到生产环境中，制定回滚计划，以便在出现意外情况时撤消更改。

应用程序变更管理

开发和测试环境的存在允许组织以安全的方式推出新的应用程序和应用程序更改。

新的应用程序开发被限制在开发环境中，在这种环境中，不正确的查询和数据库的其他滥用只会影响其他开发工作。
一旦代码稳定下来，就可以将其合并到登台环境中，并与现有的生产工作负载一起进行负载测试。(ClustrixGUI管理UI可以提供有用的比较信息。)
在测试环境中验证了适当的功能和性能之后，可以将更改部署到生产环境中。

ClustrixDB升级的最佳实践

在您的ClustrixDB集群上升级软件时，可以采用与更改应用程序代码大致相同的方式进行处理。尽管ClustrixDB软件版本是在内部进行了彻底的测试，但是诸如新的编译器优化之类的更改可能会对客户的工作负载产生意料之外的影响;在运行模拟工作负载的登台集群上对新版本进行验证，可以在产品推出之前发现此类问题。

在理想的操作环境中，客户可以参与beta程序，获得早期版本候选版本，以便在他们的开发集群中使用。一旦有一个合格的版本可用，他们就可以在他们的测试环境中进行测试，以消除在繁重的工作负载下明显存在的问题。升级生产时，如果有一对集群可用，则应先升级一个集群;然后，在升级第二个集群之前，集群可以承受一整天或一周的负载，从而提供故障恢复到运行上一个稳定版本的第二个集群。

高可用性的应用程序配置

虽然消除应用程序堆栈中的单点故障超出了本文的范围，但是下面的指导原则适用于您的应用程序如何与ClustrixDB数据库层进行交互:

应用服务器应该通过负载平衡器连接
应用程序软件应该有数据库事务或连接失败的重试逻辑
初始重试计时应该是积极的，因为集群通常在几秒钟内处理组件故障
重试频率和迭代也应该适应可能的更长的持续时间恢复

备份与恢复

ClustrixDB并行快速备份提供了快速备份，允许在集群增长、工作被跨节点分配时提供几乎恒定的备份时间。在规划你的备份策略时，考虑以下几点:

FTP服务器通常成为备份期间的瓶颈

它应该配备10Gb或几个绑定的1Gb以太网接口
它应该具有足够快的磁盘I/O来同步集群中所有节点的并行写操作
它应该有足够的磁盘容量来处理集群的两个或多个完整备份(总使用容量的1/2，因为ClustrixDB只从每个片备份一个副本)

备份的离线存档

定期做备份文件恢复测试
ClustrixDB并行恢复支持恢复备份的子集，以及恢复到备用位置(不同的数据库名称)，允许在无法使用足够大的集群进行完全恢复时进行定期“抽查”
(离线)使用repclient实用程序对binlog进行归档，以支持时间点恢复

这还需要使用repserver来重放binlog
描述了实时点恢复的全过程 https://www.cnblogs.com/yuxiaohao/p/11969626.html