MySQL8 中文参考（八十七）（5）

MySQL8 中文参考（八十七）（4）https://developer.aliyun.com/article/1565939

• 此参数设置了为打开文件分配的内部线程的上限。任何需要更改此参数的情况都应报告为错误。
  默认值为 0。但是，此参数可以设置的最小值为 20。
• MaxNoOfSavedMessages

• 此参数设置了在错误日志中写入的最大错误数以及在覆盖现有文件之前保留的最大跟踪文件数。当节点崩溃时会生成跟踪文件。
  默认值为 25，这将设置这些最大值为 25 个错误消息和 25 个跟踪文件。
• MaxLCPStartDelay

• 在并行数据节点恢复中，只有表数据实际上是并行复制和同步的；词典和检查点信息等元数据的同步是串行进行的。此外，词典和检查点信息的恢复不能与执行本地检查点并行执行。这意味着，当同时启动或重新启动许多数据节点时，数据节点可能被迫等待本地检查点的执行，这可能导致更长的节点恢复时间。
  可以强制延迟本地检查点，以允许更多（甚至可能所有）数据节点完成元数据同步；一旦每个数据节点的元数据同步完成，所有数据节点都可以并行恢复表数据，即使本地检查点正在执行。要强制这样的延迟，请设置MaxLCPStartDelay，该参数确定集群在数据节点继续同步元数据的同时等待开始本地检查点的秒数。此参数应设置在config.ini文件的[ndbd default]部分中，以便所有数据节点都相同。最大值为 600；默认值为 0。
• NoOfFragmentLogFiles

• 此参数设置节点的  REDO 日志文件数量，从而分配给 REDO 日志记录的空间量。由于 REDO  日志文件是以环形方式组织的，因此非常重要的是集合中的第一个和最后一个日志文件（有时分别称为“头”和“尾”日志文件）不要相遇。当这些文件彼此靠近时，由于没有足够的空间来存储新的日志记录，节点开始中止所有涵盖更新的事务。
  直到插入该日志记录时所需的两个本地检查点都已完成，REDO日志记录才会被删除。检查点频率由本章其他地方讨论的一组配置参数确定。
  默认参数值为 16，默认情况下表示 16 组 4 个 16MB 文件，总共 1024MB。可以使用FragmentLogFileSize参数配置单个日志文件的大小。在需要大量更新的情况下，NoOfFragmentLogFiles的值可能需要设置得更高，甚至高达 300 或更高，以提供足够的 REDO 日志空间。
  如果检查点速度慢，数据库写入太多，日志文件已满且无法裁剪日志尾部而不危及恢复，所有更新事务都将中止，并显示内部错误代码 410（Out of log file space temporarily）。这种情况会持续，直到检查点完成并且日志尾部可以向前移动。
  重要提示
  无法“即时”更改此参数；您必须使用--initial重新启动节点。如果您希望为运行中的集群中的所有数据节点更改此值，可以使用滚动节点重新启动（在启动每个数据节点时使用--initial）。
• RecoveryWork

• LCP 文件的存储开销百分比。此参数仅在EnablePartialLcp为 true 时有效，即仅在启用部分本地检查点时有效。较高的值意味着：

• 每个 LCP 写入更少记录，LCP 使用更多空间
  
• 重新启动期间需要更多工作
  

• RecoveryWork的较低值意味着：
  

• 每个 LCP 写入更多记录，但 LCP 在磁盘上占用的空间更少。
  
• 重新启动期间的工作量减少，因此重新启动更快，但在正常操作期间需要更多工作
  

• 例如，将RecoveryWork设置为  60 意味着 LCP 的总大小大约是数据要检查点的大小的 1 + 0.6 = 1.6  倍。这意味着与使用完整检查点进行重新启动期间所需的工作相比，使用部分 LCP 进行重新启动期间需要多  60％的工作（在重新启动的其他阶段进行了更多的补偿，使得整体重新启动速度仍然比使用完整 LCP 时更快）。为了不填满重做日志，需要以 1 +（1  / RecoveryWork）倍的数据更改速率写入检查点—因此，当RecoveryWork = 60 时，需要以大约 1 +（1 / 0.6）= 2.67 倍的变化速率进行写入。换句话说，如果更改速率为每秒 10 兆字节，那么检查点需要以大约每秒 26.7 兆字节的速度写入。
  设置RecoveryWork = 40 意味着只需要总 LCP 大小的 1.4 倍（因此恢复阶段需要的时间减少了 10 到 15％）。在这种情况下，检查点写入速率是变化速率的 3.5 倍。
  NDB 源代码分发包含用于模拟 LCP 的测试程序。lcp_simulator.cc可以在storage/ndb/src/kernel/blocks/backup/中找到。要在 Unix 平台上编译和运行它，请执行以下命令：

$> gcc lcp_simulator.cc
$> ./a.out

• 此程序除了stdio.h之外没有任何依赖项，并且不需要连接到 NDB 集群或 MySQL 服务器。默认情况下，它模拟 300 个 LCP（三组 100 个 LCP，每个 LCP 由插入、更新和删除组成，依次报告每个 LCP 的大小）。您可以通过更改源代码中的recovery_work、insert_work和delete_work的值并重新编译来更改模拟。有关更多信息，请参阅程序的源代码。
• InsertRecoveryWork

• 用于插入行的RecoveryWork百分比。较高的值会增加本地检查点期间的写入次数，并减少 LCP 的总大小。较低的值会减少本地检查点期间的写入次数，但会导致更多的空间用于 LCP，这意味着恢复时间更长。此参数仅在EnablePartialLcp为 true 时生效，即仅在启用部分本地检查点时生效。
• EnableRedoControl

• 启用自适应检查点速度以控制重做日志使用情况。
  当启用（默认情况下），EnableRedoControl 允许数据节点更灵活地写入 LCP 到磁盘的速率。更具体地说，启用此参数意味着可以使用更高的写入速率，以便 LCP  可以更快完成并修剪重做日志，从而减少恢复时间和磁盘空间需求。此功能允许数据节点更好地利用现代固态存储设备和协议（例如使用非易失性内存表达式（NVMe）的固态驱动器（SSD））提供的更高  I/O 速率和更大带宽。
  当NDB部署在 I/O 或带宽相对受限的系统上，相对于使用固态技术的系统，例如使用传统硬盘（HDD）的系统时，EnableRedoControl 机制很容易导致 I/O 子系统饱和，增加数据节点输入和输出的等待时间。特别是，这可能会导致 NDB Disk Data  表出现问题，这些表的表空间或日志文件组与数据节点 LCP 和重做日志文件共享受限的 I/O 子系统；这些问题可能包括由于 GCP  停止错误而导致节点或集群故障。在这种情况下将 EnableRedoControl 设置为 false 以禁用它。将EnablePartialLcp设置为 false 也会禁用自适应计算。

元数据对象。 下一组[ndbd]参数定义了用于定义属性、表、索引和触发器对象的池大小的元数据对象的最大数量，这些对象用于索引、事件和集群之间的复制。

注意

这些仅仅是对集群的“建议”，任何未指定的值都会恢复到显示的默认值。

• MaxNoOfAttributes

• 此参数设置了集群中可以定义的建议最大属性数量；与MaxNoOfTables一样，它并不打算作为一个硬性上限。
  (在旧版 NDB 集群中，这个参数有时被视为某些操作的硬性限制。这在 NDB 集群复制时会导致问题，当可以创建的表多于可以复制的表时，有时会导致混乱，有时会导致[或不会导致，取决于情况]可以创建超过MaxNoOfAttributes属性。)
  默认值为 1000，最小可能值为 32。最大值为 4294967039。每个属性消耗大约 200 字节的存储空间，因为所有元数据都完全复制在服务器上。
  在设置MaxNoOfAttributes时，重要的是提前准备好你可能想要在未来执行的任何ALTER TABLE语句。这是因为，在对 Cluster 表执行ALTER TABLE时，使用的属性数量是原始表中属性数量的 3 倍，一个良好的做法是允许这个数量的两倍。例如，如果具有最多属性数量的 NDB 集群表（greatest_number_of_attributes）有 100 个属性，那么MaxNoOfAttributes的一个良好起点将是6 * *greatest_number_of_attributes* = 600。
  你还应该估算每个表的平均属性数量，并将其乘以MaxNoOfTables。如果这个值大于前一段中获得的值，则应该使用较大的值。
  假设您可以无问题地创建所有所需的表，还应通过在配置参数后尝试实际的ALTER TABLE来验证此数字是否足够。如果不成功，请再次增加MaxNoOfAttributes的倍数，并再次测试。
• MaxNoOfTables

• 为每个表和集群中每个唯一的哈希索引分配一个表对象。此参数设置了集群作为整体的建议最大表对象数；与MaxNoOfAttributes一样，它并不打算作为一个硬性上限。
  （在旧版 NDB Cluster 中，此参数有时被视为某些操作的硬性限制。这导致 NDB Cluster 复制出现问题，当可以创建的表多于可复制的表时，有时会导致混乱，有时会导致[根据情况]无法创建超过MaxNoOfTables表。）
  对于每个具有BLOB数据类型的属性，额外使用一个表来存储大部分BLOB数据。在定义总表数时，这些表也必须考虑在内。
  此参数的默认值为 128。最小值为 8，最大值为 20320。每个表对象在每个节点上大约消耗 20KB。
  注意
  MaxNoOfTables、MaxNoOfOrderedIndexes和MaxNoOfUniqueHashIndexes的总和不得超过2³² − 2（4294967294）。
• MaxNoOfOrderedIndexes

• 对于集群中的每个有序索引，都会分配一个描述正在索引的内容及其存储段的对象。默认情况下，每个这样定义的索引也定义了一个有序索引。每个唯一索引和主键都有一个有序索引和一个哈希索引。MaxNoOfOrderedIndexes设置了系统中可以同时使用的有序索���的总数。
  此参数的默认值为 128。每个索引对象每个节点大约消耗 10KB 的数据。
  注意
  MaxNoOfTables、MaxNoOfOrderedIndexes和MaxNoOfUniqueHashIndexes的总和不能超过2³² − 2（4294967294）。
• MaxNoOfUniqueHashIndexes

• 对于每个不是主键的唯一索引，都会分配一个特殊表，将唯一键映射到索引表的主键。默认情况下，每个唯一索引也定义了一个有序索引。要防止这种情况，必须在定义唯一索引时指定USING HASH选项。
  默认值为 64。每个索引大约消耗 15KB 每个节点。
  注意
  MaxNoOfTables、MaxNoOfOrderedIndexes和MaxNoOfUniqueHashIndexes的总和不能超过2³² − 2（4294967294）。
• MaxNoOfTriggers

• 每个唯一哈希索引都分配了内部更新、插入和删除触发器。（这意味着每个唯一哈希索引都创建了三个触发器。）然而，有序索引只需要一个触发器对象。备份还为集群中的每个普通表使用三个触发器对象。
  集群之间的复制也使用内部触发器。
  此参数设置了集群中触发器对象的最大数量。
  默认值为 768。
• MaxNoOfSubscriptions

• NDB 集群中的每个 NDB 表都需要在 NDB 内核中进行订阅。对于一些 NDB API 应用程序，可能需要或希望更改此参数。但是，对于正常使用 MySQL 服务器作为 SQL 节点的情况，没有必要这样做。
  MaxNoOfSubscriptions 的默认值为 0，被视为等于 MaxNoOfTables。每个订阅者消耗 108 字节。
• MaxNoOfSubscribers

• 当使用 NDB 集群复制时，此参数才有意义。默认值为 0。在 NDB 8.0.26 之前，此值被视为 2 * MaxNoOfTables；从 NDB 8.0.26 开始，它被视为 2 * MaxNoOfTables + 2 * [API 节点数]。每个 MySQL 服务器（一个作为复制源，另一个作为副本）的每个 NDB 表都有一个订阅者，每个订阅者使用 16 字节的内存。
  在使用循环复制、多源复制和涉及超过 2 个 MySQL 服务器的其他复制设置时，应将此参数增加到包含在复制中的 mysqld 进程的数量（通常与集群数量相同，但并非总是如此）。例如，如果您有一个使用三个 NDB 集群的循环复制设置，每个集群附加一个 mysqld，并且每个 mysqld 进程既是源又是副本，则应将 MaxNoOfSubscribers 设置为 3 * MaxNoOfTables。
  欲了解更多信息，请参阅第 25.7 节“NDB 集群复制”。
• MaxNoOfConcurrentSubOperations

• 此参数设置了集群中所有 API 节点可以同时执行的操作数量上限。默认值（256）对于正常操作已经足够，只有在有很多 API 节点同时执行大量操作的情况下才需要调整。

布尔参数。 数据节点的行为也受到一组取布尔值的 [ndbd] 参数的影响。这些参数可以通过将它们设置为 1 或 Y 来指定为 TRUE，通过将它们设置为 0 或 N 来指定为 FALSE。

• CompressedLCP

• 将此参数设置为 1 会导致本地检查点文件被压缩。所使用的压缩方式等同于 gzip --fast，可以节省数据节点上存储未压缩检查点文件所需空间的 50% 或更多。可以为单个数据节点启用压缩的 LCP，也可以为所有数据节点启用（通过在 config.ini 文件的 [ndbd default] 部分设置此参数）。
  重要
  不能将压缩的本地检查点还原到不支持此功能的 MySQL 版本的集群中运行。
  默认值为 0（禁用）。
  在 NDB 8.0.29 之前，此参数在 Windows 平台上没有效果（BUG#106075，BUG#33727690）。
• CrashOnCorruptedTuple

• 当启用此参数（默认情况下），当数据节点遇到损坏的元组时，它会强制关闭。
• Diskless

• 可以将 NDB 集群表指定为无磁盘，这意味着表不会被检查点到磁盘，也不会发生日志记录。这些表仅存在于主内存中。使用无磁盘表的一个后果是，表和表中的记录在崩溃时都不会存活。但是，在无磁盘模式下，可以在无磁盘计算机上运行ndbd。
  重要
  此功能导致整个集群以无磁盘模式运行。
  启用此功能后，NDB 集群在线备份将被禁用。此外，无法进行集群的部分启动。
  默认情况下，无磁盘 是禁用的。
• 加密文件系统

• 加密 LCP 和表空间文件，包括撤销日志和重做日志。默认情况下禁用（0）；设置为 1 以启用。
  重要
  当启用文件系统加密时，您必须在启动每个数据节点时提供密码，可以使用 --filesystem-password 或 --filesystem-password-from-stdin 选项之一。否则，数据节点无法启动。
  更多信息，请参阅第 25.6.14 节，“NDB 集群的文件系统加密”。
• 延迟分配

• 在与管理服务器建立连接后为此数据节点分配内存。默认情况下启用。
• 锁定主内存中的页面

• 对于许多操作系统，包括 Solaris 和 Linux，可以将进程锁定到内存中，从而避免任何交换到磁盘。这可以用来帮助保证集群的实时特性。此参数接受整数值0、1或2，其作用如下所示：

• 0: 禁用锁定。这是默认值。
  
• 1: 在为进程分配内存后执行锁定。
  
• 2: 在为进程分配内存之前执行锁定。
  

• 如果操作系统未配置为允许非特权用户锁定页面，则使用此参数的数据节点进程可能必须以系统根用户身份运行。(LockPagesInMainMemory使用mlockall函数。从 Linux 内核 2.6.9 开始，非特权用户可以锁定内存，受max locked memory限制。有关更多信息，请参见ulimit -l和linux.die.net/man/2/mlock。)
  注意
  在旧版 NDB Cluster 中，此参数是一个布尔值。0或false是默认设置，禁用锁定。1或true启用在为进程分配内存后锁定进程。NDB Cluster 8.0 将此参数的值视为错误。
  重要
  从glibc 2.10 开始，glibc使用每个线程的竞技场来减少共享池上的锁争用，这会消耗实际内存。一般来说，数据节点进程在启动后不需要每个线程的竞技场，因为它在启动后不执行任何内存分配。（这种分配器的差异似乎不会显著影响性能。）
  glibc的行为应通过MALLOC_ARENA_MAX环境变量进行配置，但在glibc 2.16 之前的机制中存在一个错误，这意味着无法将此变量设置为小于 8，因此无法回收浪费的内存。（Bug #15907219；另请参阅sourceware.org/bugzilla/show_bug.cgi?id=13137以获取有关此问题的更多信息。)
  一个可能的解决方法是使用LD_PRELOAD环境变量预加载jemalloc内存分配库，以取代glibc提供的库。
  
• ODirect

• 启用此参数会导致NDB尝试使用O_DIRECT写入进行 LCP、备份和重做日志，通常降低kswapd和 CPU 使用率。在 Linux 上使用 NDB Cluster 时，如果使用的是 2.6 或更高版本的内核，请启���ODirect。
  ODirect 默认情况下被禁用。
• ODirectSyncFlag

• 当启用此参数时，重做日志写入是这样执行的，即每个完成的文件系统写入被处理为调用fsync。如果以下条件之一为真，则忽略此参数的设置：

• ODirect未被启用。
  
• InitFragmentLogFiles设置为SPARSE。
  

• 默认情况下被禁用。
  
• RestartOnErrorInsert

• 该功能仅在构建调试版本时可访问，可以在测试中将错误插入到代码块的执行中。
  该功能默认情况下被禁用。
• StopOnError

• 该参数指定当遇到错误条件时，数据节点进程应退出还是执行自动重启。
  此参数的默认值为 1；这意味着，默认情况下，错误会导致数据节点进程停止。
  当遇到错误并且StopOnError为 0 时，数据节点进程将被重启。
  MySQL Cluster Manager 的用户应注意，当StopOnError等于 1 时，这会阻止 MySQL Cluster Manager 代理在执行自身的重启和恢复后重新启动任何数据节点。有关更多信息，请参阅在 Linux 上启动和停止代理。
• UseShm

• 在此数据节点和在同一主机上运行的 API 节点之间启用共享内存连接。设置为 1 以启用。

控制超时、间隔和磁盘分页

集群数据节点中有许多 [ndbd] 参数指定了各种操作之间的超时和间隔时间。大多数超时值以毫秒为单位指定。任何例外情况都会在适用时提到。

• TimeBetweenWatchDogCheck

• 为了防止主线程在某个时刻陷入无限循环，一个“看门狗”线程会监视主线程。该参数指定了每次检查之间的毫秒数。如果进程在三次检查后仍处于相同状态，则看门狗线程将终止它。
  这个参数可以很容易地进行更改以进行实验或适应本地条件。虽然可以按节点指定，但似乎没有太多理由这样做。
  默认超时时间为 6000 毫秒（6 秒）。
• TimeBetweenWatchDogCheckInitial

• 这与 TimeBetweenWatchDogCheck 参数类似，不同之处在于 TimeBetweenWatchDogCheckInitial 控制了在存储节点的早期启动阶段内存分配时执行检查之间经过的时间。
  默认超时时间为 6000 毫秒（6 秒）。
• StartPartialTimeout

• 此参数指定集群在调用集群初始化程序之前等待所有数据节点启动的时间。此超时用于尽可能避免部分集群启动。
  在执行集群的初始启动或初始重启时，此参数将被覆盖。
  默认值为 30000 毫秒（30 秒）。0 禁用超时，此时只有在所有节点可用时集群才能启动。
• StartPartitionedTimeout

• 如果集群在等待StartPartialTimeout毫秒后准备启动，但仍可能处于分区状态，则集群会等待直到此超时也过去。如果StartPartitionedTimeout设置为 0，则集群会无限期等待（2³²−1 毫秒，约为 49.71 天）。
  在执行集群的初始启动或初始重启时，此参数将被覆盖。
• StartFailureTimeout

• 如果数据节点在此参数指定的时间内未完成启动序列，则节点启动失败。将此参数设置为 0（默认值）意味着不应用任何数据节点超时。
  对于非零值，此参数以毫秒为单位。对于包含大量数据的数据节点，应增加此参数。例如，在数据节点包含数千兆字节数据的情况下，可能需要长达 10−15 分钟（即 600000 至 1000000 毫秒）的时间来执行节点重启。
• StartNoNodeGroupTimeout

• 当数据节点配置为Nodegroup = 65536时，被视为未分配到任何节点组。完成此操作后，集群等待StartNoNodegroupTimeout毫秒，然后将这些节点视为已添加到传递给--nowait-nodes选项的列表中，并启动。默认值为15000（即，管理服务器等待 15 秒）。将此参数设置为0意味着集群无限期等待。
  StartNoNodegroupTimeout必须对集群中的所有数据节点相同；因此，您应始终在config.ini文件的[ndbd default]部分中设置它，而不是为单独的数据节点设置。
  查看第 25.6.7 节，“在线添加 NDB 集群数据节点”，获取更多信息。
• HeartbeatIntervalDbDb

• 发现故障节点的主要方法之一是使用心跳。此参数说明心跳信号发送的频率以及预期接收它们的频率。无法禁用心跳。
  连续错过四个心跳间隔后，节点被宣布死亡。因此，通过心跳机制发现故障的最长时间是心跳间隔的五倍。
  默认心跳间隔为 5000 毫秒（5 秒）。此参数不应大幅更改，并且在节点之间不应有很大差异。如果一个节点使用 5000 毫秒，而监视它的节点使用 1000 毫秒，显然该节点会很快被宣布死亡。此参数可以在在线软件升级期间进行更改，但只能小幅增加。
  另请参阅网络通信和延迟以及ConnectCheckIntervalDelay配置参数的描述。
• HeartbeatIntervalDbApi

• 每个数据节点向每个  MySQL 服务器（SQL 节点）发送心跳信号，以确保保持联系。如果某个 MySQL  服务器未能及时发送心跳，则被声明为“死亡”，在这种情况下，所有正在进行的事务将被完成，所有资源将被释放。直到前一个 MySQL  实例启动的所有活动都完成后，SQL 节点才能重新连接。用于此确定的三个心跳标准与HeartbeatIntervalDbDb中描述的相同。
  默认间隔为 1500 毫秒（1.5 秒）。此间隔可能因为每个数据节点独立监视连接到其上的 MySQL 服务器而在各个数据节点之间有所不同，与其他所有数据节点无关。
  更多信息，请参见网络通信和延迟。
• HeartbeatOrder

• 数据节点以循环方式向彼此发送心跳，每个数据节点监视前一个数据节点。如果某个数据节点未检测到心跳，则该节点将声明循环中的前一个数据节点“死亡”（即，集群不再能访问）。确定数据节点死亡是全局性的；换句话说，一旦某个数据节点被声明为死亡，所有集群中的节点都将这样认为。可能存在数据节点之间的心跳速度与其他节点对之间的心跳速度过慢（例如，由于非常低的心跳间隔或临时连接问题），导致某个数据节点被声明为死亡，尽管该节点仍可作为集群的一部分运行。在这种情况下，数据节点之间传输心跳的顺序可能会影响某个特定数据节点是否被声明为死亡。如果此声明是不必要的，这反过来可能导致节点组的不必要丢失，从而导致集群的失败。考虑一种设置，其中有 4 个数据节点 A、B、C 和 D 分别运行在 2 台主机 host1 和 host2 上，并且这些数据节点组成了 2 个节点组，如下表所示：表 25.10 四个数据节点 A、B、C、D 分别运行在两台主机 host1、host2 上；每个数据节点属于两个节点组中的一个。

• 假设心跳以顺序  A->B->C->D->A 传输。在这种情况下，主机之间心跳丢失导致节点 B 宣布节点 A 死亡，节点 C 宣布节点 B  死亡。这导致节点组 0 的丢失，因此集群失败。另一方面，如果传输顺序为  A->B->D->C->A（并且所有其他条件保持不变），心跳丢失导致节点 A 和 D  被宣布死亡；在这种情况下，每个节点组都有一个存活节点，集群可以继续运行。HeartbeatOrder 配置参数使心跳传输顺序可由用户配置。HeartbeatOrder 的默认值为零；允许在所有数据节点上使用默认值会导致心跳传输顺序由 NDB 决定。如果使用此参数，必须为集群中的每个数据节点设置为非零值（最大 65535），并且每个数据节点的值必须是唯一的；这将导致心跳传输按照它们的 HeartbeatOrder 值从最低到最高的顺序进行（然后直接从具有最高 HeartbeatOrder 值的数据节点到具有最低值的数据节点，以完成循环）。这些值不需要连续。例如，在前面概述的情况下强制心跳传输顺序为 A->B->D->C->A，您可以设置如下的 HeartbeatOrder 值：表 25.11 HeartbeatOrder 值，用于强制心跳传输顺序为 A->B->D->C->A。

• 要在运行中的 NDB 集群中使用此参数来更改心跳传输顺序，您必须首先在全局配置（config.ini）文件（或文件）中为集群中的每个数据节点设置HeartbeatOrder。要使更改生效，您必须执行以下操作之一：

• 整个集群的完全关闭和重启。
  
• 连续 2 次滚动重启集群。所有节点必须按相同顺序在两次滚动重启中重启。
  

• 您可以使用DUMP 908来观察此参数在数据节点日志中的效果。
  
• ConnectCheckIntervalDelay

• 该参数在一个数据节点在未通过 5 个HeartbeatIntervalDbDb毫秒的心跳检查后启用数据节点之间的连接检查。
  如果某个数据节点在ConnectCheckIntervalDelay毫秒的间隔内仍未响应，则被视为可疑，并在两个这样的间隔后被视为死亡。这在存在已知延迟问题的设置中可能很有用。
  该参数的默认值为 0（禁用）。
• TimeBetweenLocalCheckpoints

• 该参数是一个例外，因为它不指定在开始新的本地检查点之前等待的时间；相反，它用于确保在相对更新较少的集群中不执行本地检查点。在大多数更新速率较高的集群中，很可能在上一个本地检查点完成后立即开始新的本地检查点。
  自上一个本地检查点开始执行的所有写操作的大小被累加。该参数也是一个例外，因为它被指定为 4 字节字数的以 2 为底的对数，所以默认值 20 意味着 4MB（4 × 2²⁰)的写操作，21 意味着 8MB，依此类推，最大值为 31，相当于 8GB 的写操作。
  所有集群中的写操作都会被累加。将TimeBetweenLocalCheckpoints设置为 6 或更少意味着本地检查点会持续执行，而不受集群工作负载的影响。
• TimeBetweenGlobalCheckpoints

• 当事务提交时，在所有数据被镜像的节点的主内存中提交。然而，事务日志记录不会作为提交的一部分刷新到磁盘。这种行为背后的理由是，在至少两台自主主机上安全提交事务应该符合合理的耐久性标准。
  重要的是要确保即使在最糟糕的情况下——集群完全崩溃时也能正确处理。为了保证这一点，所有在给定时间间隔内发生的事务都被放入一个全局检查点中，可以将其视为已刷新到磁盘的一组已提交事务。换句话说，在提交过程中，事务被放入一个全局检查点组中。稍后，该组的日志记录被刷新到磁盘，然后整个事务组被安全地提交到集群中所有计算机的磁盘上。
  在使用固态硬盘（特别是采用 NVMe 的硬盘）与磁盘数据表时，我们建议在 NDB 8.0 中减少此值。在这种情况下，您还应确保MaxDiskDataLatency设置为适当的水平。
  此参数定义全局检查点之间的间隔。默认值为 2000 毫秒。
• TimeBetweenGlobalCheckpointsTimeout

• 此参数定义全局检查点之间的最小超时时间。默认值为 120000 毫秒。
• TimeBetweenEpochs

• 此参数定义 NDB 集群复制的同步时期之间的间隔。默认值为 100 毫秒。
  TimeBetweenEpochs 是“微型 GCPs”的实现的一部分，可用于改善 NDB 集群复制的性能。
• TimeBetweenEpochsTimeout

MySQL8 中文参考（八十七）（6）https://developer.aliyun.com/article/1565941