Master将最新的GCI设置为重启GCI，然后将自己的系统文件同步到所有其他参与系统重启的节点。

下一步是在系统重启时同步所有节点的架构。这是在 15 次通过中执行的。我们试图在这里解决的问题是，当一个模式对象在节点启动时被创建，但在节点关闭时被删除，甚至可能在该节点不可用时使用相同的模式 ID 创建了一个新对象。为了处理这种情况，首先需要重新创建从起始节点的角度来看应该存在的所有对象。在此之后，集群中其他节点在该节点“死亡”时丢弃的任何对象被丢弃；这也适用于在中断期间删除的任何表。最后，在起始节点不可用时由其他节点创建的任何表都将在起始节点上重新创建。所有这些操作都是起始节点的本地操作。作为这个过程的一部分，是否还需要确保所有需要重新创建的表都已在本地创建，并且已在所有内核块中为它们设置适当的数据结构。

在为主节点执行前面描述的过程后，新的模式文件被发送到系统重启中的所有其他参与者，并且他们执行相同的同步。

重新启动中涉及的所有片段都必须具有从 派生的正确参数 DBDIH。这会导致许多START_FRAGREQ信号从 发送DBDIH到 DBLQH。这也开始了碎片的恢复，在从磁盘读取恢复数据并并行将从磁盘读取的恢复数据应用到主存储器的过程中，一次一个记录地恢复碎片。这仅恢复表的主内存部分。

一旦恢复了所有片段， START_RECREQ就会向起始集群中的所有节点发送一条消息，然后应用表的任何磁盘数据部分的所有撤消日志。

在应用撤消日志后 LGMAN，有必要执行一些恢复工作， TSMAN这需要扫描表空间的扩展头。

接下来，需要准备执行重做日志，该日志最多可以分四个阶段执行。对于每个片段，可能需要从几个不同的节点执行重做日志。DBDIH这是通过在发送START_FRAGREQ信号时决定的特定片段的不同阶段执行重做日志来处理的。EXEC_FRAGREQ为每个阶段和需要在该阶段执行的片段发送一个 信号。发送完这些信号后，会向所有节点发送一个 EXEC_SRREQ信号，告诉它们可以开始执行重做日志了。

在执行redo log之前，需要计算从哪里开始读取，redo log应该到哪里结束。当达到要恢复的最后一个 GCI 时，应该会找到重做日志的末尾。

完成redo logs的执行后，所有在最后一次要恢复的GCI之后写入的redo log page都会失效。考虑到重做日志的循环性质，这可能会将失效带入新的重做日志文件中，超过最后一个执行的日志文件。

完成上一步 后，使用 消息DBLQH将此报告回来 。 DBDIHSTART_RECCONF

当主节点从所有起始节点收到此消息时，它会向 发送NDB_STARTCONF 回信号NDBCNTR。

该NDB_STARTCONF消息将STTOR阶段 4 的结束标记为 NDBCNTR，这是该阶段中唯一涉及到任何重要程度的块。