利用本地检查点和部分检查点快速重启MySQL NDB Cluster

作者：Bernd Ocklin 译：徐轶韬

MySQL NDB Cluster团队致力于NDB架构核心部分的基础重新设计。这些更改之一是部分检查点算法。现在，用户可以充分利用它构建更大的集群，NDB 8.0可以在每个数据节点上使用16 TB的内存表，也可以使用磁盘数据构建3副本5 PB的集群。

新的部分检查点算法执行重新启动的速度提高了4倍，在典型设置中将检查点时间减少了6倍，并最大程度地减少了集群的磁盘空间消耗。另外，新的检查点减少了节点之间的同步延迟。使得较小的集群更易于维护，并进而允许构建具有更高存储容量的较大群集。

内存数据库写入磁盘？

为了保证持久性，MySQL Cluster将内存中的数据更改记录到磁盘上的并行事务日志（REDO）中。定期的“本地”检查点（LCP）将所有内存中的内容写入磁盘，允许截断REDO日志，从而限制了磁盘空间的使用和恢复时间。

为了使磁盘延迟不影响集群的实时内存事务，LCP到磁盘的操作在后台异步执行。

在以前的MySQL Cluster版本中，这些检查点始终将每个检查点的完整数据集写入磁盘，称为“ Full LCP”，此过程对于配置了数百GB内存的数据库可能要花费数小时。在这样的LCP期间，写入密集型应用程序执行的重做日志可能会变得非常大。虽然LCP是写入在每个本地节点，但它们对节点的重新启动有影响，随着LCP持续时间的增加，影响显着。

新的检查点算法

磁盘上维护了许多部分本地检查点（pLCP）。每个部分本地检查点是整个未更改数据的一个子集，并包含自上一个pLCP以来所做的所有更改。

在恢复期间，多个pLCP的内容与REDO日志内容一起恢复，以将整个数据集返回到其内存中的恢复点。该算法减少了每个检查点写入的数据量，从而线性地影响检查点持续时间，影响REDO日志大小和同步延迟。加上一些磁盘空间使用优化，还可以减少磁盘上检查点的总大小。

为了确保在所有情况下都将与LCP相关的同步延迟最小化，每个节点上的检查点执行已进一步分离，以确保数据节点恢复不会对LCP持续时间产生不利影响。这提高了系统的稳定性和健壮性。

重新启动的方式变得更快

以下数字说明了实施新算法的好处。为了进行测试，我们将600个DBT2数据表装入具有100G DataMemory的2个数据节点集群中，从而存储了大约60GB的数据。

在这种情况下，我们看到节点重启时间提高了近3.5倍。在使用旧版LCP的版本中，正常节点重启大约需要25分钟。使用部分检查点，仅需要大约7分钟即可重新启动节点，并且重新启动时间可以预测。节点重启时，集群在起始节点中恢复数据，而其余节点继续提供完整服务。

我们仔细研究时间花费在哪里。遍历集群节点重新启动阶段，我们可以确定集群如何受益：

在初始设置阶段，将初始化内存。这花费的时间与要初始化的内存量成线性关系，并且与检查点算法无关。

在下一阶段，数据将从检查点还原到集群内存中。实际上，使用部分检查点将花费较长的时间，因为必须从磁盘还原多个较小的部分本地检查点。

在REDO执行阶段，我们开始看到新检查点算法的真正好处。REDO日志较小，因此恢复速度快两倍（部分检查点为43秒，传统LCP为75秒）。此外，通过我们新的UNDO日志应用程序中的额外改进，我们将看到存储在磁盘表中的数据集有了5倍的改进。

下一阶段是重建索引，这也得到了改善。在任何集群版本中，随后的同步阶段仅持续3-4秒。

下一阶段将实现最显着的改进。我们需要在重新启动期间执行（写入）本地检查点，以确保数据节点可以独立恢复数据。数据节点必须等待检查点完成。在这种特定情况下，一个完整的LCP可能要花费20分钟。通过新的检查点执行速度更快，等待时间可以减少到只有大约2分钟。

最后的切换阶段非常短暂，新旧检查点算法都将花费6至7秒钟。

权衡？

列出了所有优点之后，我还要提及新检查点算法的权衡：从新的部分检查点之前的版本进行在线版本升级需要对所有数据节点进行初始滚动重启。并且这一次初始节点重新启动可能需要更长的时间。