21.1.4.2 NDB Cluster 7.6 的新增功能
以下列 table 中列出了 NDB Cluster 7.6 中可能令人感兴趣的新功能和其他重要更改:
- 新的磁盘数据 table 文件格式. NDB 7.6.2 中为 NDB 磁盘数据 table 引入了一种新的文件格式,这使得每个磁盘数据 table 都可以唯一标识,而无需重新使用任何 tableID。 NDB 7.6.4 中对该格式进行了进一步改进。这应该有助于解决页面和扩展区处理方面的问题,这些问题对于用户来说是快速创建和删除磁盘数据 table 时遇到的问题,而旧格式并没有提供解决问题的快速方法。
现在,只要创建新的撤消日志文件组和 table 空间数据文件,就使用新格式。与现有磁盘数据 table 相关的文件将 continue 使用旧格式,直到重新创建它们的 table 空间和撤消日志文件组为止。
Important
新旧格式不兼容;同一磁盘数据 table 或 table 空间使用的不同数据文件或撤消日志文件不能使用多种格式。
为避免与格式更改有关的问题,升级到 NDB 7.6.2 或 NDB 7.6.4 时,应重新创建任何现有的 table 空间并撤消日志文件组。您可以通过在升级过程中对每个数据节点进行初始重新启动(即使用--initial选项)来完成此操作。从 NDB 7.5 或更早版本的发行版升级到 NDB 7.6 或更高版本的一部分,您可以期望该步骤是强制性的。
如果使用的是磁盘数据 table,则从* any * NDB 7.6 发行版(不考虑发行版状态)降级到任何 NDB 7.5 或更早的发行版都需要在降级过程中使用--initial重新启动所有数据节点。这是因为 NDB 7.5 和早期版本系列无法读取新的磁盘数据文件格式。
有关更多信息,请参见第 21.2.9 节“升级和降级 NDB 集群”。
- 数据内存池和动态索引内存.
NDB
table 列上的索引所需的内存现在从为DataMemory分配的内存中动态分配。由于这个原因,现在不建议使用IndexMemory配置参数,并且在以后的发行系列中可能会删除该参数。
Important
从 NDB 7.6.2 开始,如果在config.ini
文件中设置了IndexMemory
,则 Management 服务器将发出警告:不建议使用 IndexMemory,请在分配用于存储索引的每个 ndbd(DB)节点上使用 Number 字节代替启动时使用的字节数,以及为此分配的任何内存参数会自动添加到DataMemory
。
此外,DataMemory
的默认值已增加到 98M; IndexMemory
的默认值已降至 0.
索引存储器与数据存储器的汇集简化了NDB
的配置;这些更改的另一个好处是,不再通过为IndexMemory
设置足够大的值来限制通过增加 LDM 线程数进行扩展。这是因为索引内存不再是仅分配一次的静态数量(当群集启动),但现在可以根据需要分配和取消分配。以前,有时会出现这样的情况:增加 LDM 线程数可能导致索引内存耗尽,而仍然有大量DataMemory
可用。
作为这项工作的一部分,许多与 table 数据的存储没有直接关系的DataMemory用法实例现在使用事务存储器。
因此,在某些系统上可能有必要增加SharedGlobalMemory以允许在需要时增加事务内存,例如在使用 NDB 群集复制时,这需要在数据节点上进行大量缓冲。在执行初始大量数据加载的系统上,可能有必要将非常大的事务分解为较小的部分。
此外,数据节点现在会生成MemoryUsage
个事件(请参见第 21.5.3.2 节“ NDB 群集日志事件”),并在资源使用率达到 99%时以及与以前一样达到 80%,90%或 100%时在群集日志中写入适当的消息。
其他相关更改在此处列出:
-
IndexMemory
不再是ndbinfo.memoryusagetable 的memory_type
列中显示的值之一;也不再显示在ndb_config的输出中。-
REPORT MEMORYUSAGE和其他公开内存消耗的命令现在显示使用 32K 页(以前是 8K 页)的索引内存消耗。
-
现在,ndbinfo.resourcestable 将
DISK_OPERATIONS
资源显示为TRANSACTION_MEMORY
,并且已删除RESERVED
资源。
-
-
ndbinfo 进程和 config_nodestable. NDB 7.6.2 在ndbinfo信息数据库中添加了两个 table,以提供有关群集节点的信息;这些 table 在这里列出:
-
config_nodes:该 table 列出了 NDB 群集的配置文件中列出的每个节点的节点 ID,进程类型和主机名。
- processes显示有关当前连接到集群的节点的信息;该信息包括进程名称和系统进程 ID;对于每个数据节点和 SQL 节点,它还显示该节点的 angel 进程的进程 ID。此外,该 table 还显示了每个连接节点的服务地址。可以使用Ndb_cluster_connection::set_service_uri()方法在 NDB API 应用程序中设置此地址,该方法也在 NDB 7.6.2 中添加。
-
系统名称. NDB 群集的系统名称可用于标识特定群集。从 NDB 7.6.2 开始,MySQL Server 将此名称显示为Ndb_system_name状态变量的值。 NDB API 应用程序可以使用同一版本中添加的Ndb_cluster_connection::get_system_name()方法。
将自动生成基于 Management 服务器启动时间的系统名称。您可以通过在群集的配置文件中添加[system]
部分并将Name
参数设置为该部分中您选择的值(在启动 Management 服务器之前)来覆盖此值。
-
改进的 GUI 安装程序. NDB 群集自动安装程序已在多个方面进行了增强,如下 table 所示:
-
现在,安装程序将在加密的
.mcc
文件中提供永久存储,以替代基于 cookie 的存储。现在默认使用永久性存储。-
现在,默认情况下,安装程序将在浏览器 Client 端和 Web 服务器后端之间使用安全(HTTPS)连接。
-
安装程序使用的 Paramiko 安全库已升级到版本 2.安装程序的 SSH 功能的其他改进包括使用密码加密的私钥和对不同主机使用不同凭据的能力。
-
主机信息的检索已得到改进,现在安装程序会提供有关主机上可用磁盘空间量的准确数字。
-
配置得到了改进,现在可以在 GUI 中设置大多数节点参数。另外,枚举允许值的参数会在设置时显示这些值以供选择。现在,还可以在全局或每个节点的基础上切换高级配置参数的显示。
-
有关更多详细信息和用法信息,请参阅第 21.2.2 节“ NDB 群集自动安装程序(NDB 7.6)”。
- ndb_import CSV 导入工具. NDB Cluster 7.6.2 中添加的ndb_import使用 NDB API 将 CSV 格式的数据直接加载到NDBtable 中(仅 MySQL 服务器才需要创建 table 和数据库.位于)。 ndb_import可被视为mysqlimport或LOAD DATA SQL 语句的类似物,并支持许多相同或相似的数据格式化选项。
假设数据库和目标NDB
table 存在,则ndb_import仅需要与集群的 Management 服务器(ndb_mgmd)构建连接即可执行导入;因此,群集的config.ini
文件用途中必须为该工具提供[api]
插槽。
有关更多信息,请参见第 21.4.14 节“ ndb_import —将 CSV 数据导入到 NDB”。
- ndb_top 监视工具. 添加了ndb_topUtil,该 Util 实时显示
NDB
数据节点的 CPU 负载和使用情况信息。此信息可以以文本格式,ASCII 图或两者同时显示。图形可以用彩色显示,也可以使用灰度显示。
ndb_top连接到 NDB 群集 SQL 节点(即 MySQL 服务器)。因此,该程序必须能够以对ndbinfo数据库中的 table 具有SELECT特权的 MySQL 用户身份进行连接。
从 NDB 7.6.3 开始,ndb_top适用于 Linux,Solaris 和 macOS 平台。当前不适用于 Windows 平台。
有关更多信息,请参见第 21.4.30 节,“ ndb_top-查看 NDB 线程的 CPU 使用率信息”。
-
代码清除. 大量常规操作不需要的调试语句和打印输出已移入仅在测试或调试
NDB
时使用的代码,或完全省去了。在许多情况下,这种开销减少将导致 LDM 和 TC 线程的性能显着提高大约 10%。 -
LDM 线程和 LCP 改进. 以前,当本地数据 Management 线程遇到 I/O 滞后时,它写入本地检查点的速度更慢。例如,在磁盘过载情况下可能会发生这种情况。可能会出现问题,因为其他 LDM 线程并不总是遵守此状态,或者也是如此。
NDB
现在全局跟踪 I/O 延迟模式,以便在至少一个线程以 I/O 延迟模式写入时立即报告此状态;然后,它确保在减速条件持续时间内,对所有 LDM 线程强制执行此 LCP 降低的写入速度。因为现在其他 LDM 实例也观察到写入速度降低,所以总容量增加了;这样可以比以前更快地克服磁盘过载(或其他引起 I/O 延迟的情况)。 -
NDB 错误识别. 可以使用 NDB 7.6.4 中的mysqlClient 端获取错误消息和信息,以后可以从ndbinfo信息数据库中的新error_messagestable 中获取错误消息和信息。另外,7.6.4 版本引入了命令行 Client 端ndb_perror,用于从 NDB 错误代码中获取信息。这将使用perror和--ndb替换,现在已弃用该版本,并且在将来的发行版中会删除它。
有关更多信息,请参见第 21.5.14.21 节,“ ndbinfo error_messagestable”和第 21.4.17 节“ ndb_perror-获取 NDB 错误消息信息”。
- SPJ 的改进. 当以推送连接的方式执行扫描时(即查询的根是扫描),
DBTC
块向与要扫描的片段相同的节点上的DBSPJ
实例发送 SPJ 请求。以前,对于每个节点的碎片都发送了一个这样的请求。由于通常将DBTC
和DBSPJ
实例的数量设置为小于 LDM 实例的数量,因此这意味着所有 SPJ 实例都参与单个查询的执行,并且实际上,某些 SPJ 实例可以(并且确实)接收多个来自同一查询的请求。在 NDB 7.6.4 中,单个 SPJ 请求可以处理一组要扫描的根片段,因此仅一个 SPJ 请求(SCAN_FRAGREQ
)需要发送到每个 SPJ 实例(DBSPJ
块)上。节点。
由于评估推入联接时DBSPJ
消耗的 CPU 总量相对较小,这与 LDM 块(大多数 CPU 使用率是合理的)不同,因此引入多个 SPJ 块会增加一些并行性,但是额外的开销也会增加。通过启用单个 SPJ 请求来处理一组要扫描的根片段,从而仅将单个 SPJ 请求发送到每个节点上的每个DBSPJ
实例,并为每个片段分配批处理大小,则多片段扫描可以获得更大的总批大小,允许在 SPJ 块内完成一些调度优化,它可以一次扫描单个片段(为其分配总批大小),使用较小的子批并行扫描所有片段,或进行某些组合在两个中。
由于以下原因,预期这项工作将提高下推式联接的性能:
-
由于可以为每个 SPJ 请求扫描多个根片段,因此在执行强制连接时需要请求更少的 SPJ 实例
- 在大多数情况下,对于每个片段,增加可用的批处理大小分配也应导致完成连接所需的请求减少
-
改进了对重做日志的 O_DIRECT 处理. NDB 7.6.4 实施了一个新的数据节点配置参数ODirectSyncFlag,该参数使使用
O_DIRECT
完成的重做日志写入被处理为fsync
调用。ODirectSyncFlag
默认为禁用;要启用它,请将其设置为true
。
您应该记住,当至少满足以下条件之一时,将忽略此参数的设置:
-
ODirect未启用。
InitFragmentLogFiles
设置为SPARSE
。
-
将 CPU 锁定到脱机索引构建线程. 在 NDB 7.6.4 和更高版本中,脱机索引构建默认情况下使用ndbmtd可用的所有内核,而不仅限于为 I/O 线程保留的单个内核。还可以指定一组所需的内核,这些内核将用于执行有序索引的脱机多线程构建的 I/O 线程。这可以改善重新启动和还原的时间,性能以及可用性。
Note
此处使用的“脱机”是指未写入给定 table 时发生的有序索引构建。此类索引构建发生在节点或系统重新启动期间,或使用ndb_restore --rebuild-indexes从备份还原群集时。
此改进涉及几个相关的更改。第一个是更改BuildIndexThreads配置参数的默认值(从 0 到 128),这意味着现在默认情况下脱机有序索引构建是多线程的。 TwoPassInitialNodeRestartCopy的默认值也已更改(从false
到true
),以便初始节点重新启动时首先复制所有数据,而无需从“活动”节点向正在启动的节点创建索引,从而离线构建有序索引复制数据后,再次与活动节点同步;这可以大大减少构建索引所需的时间。此外,为了便于将脱机索引构建线程显式锁定到特定的 CPU,为ThreadConfig配置参数定义了新的线程类型(idxbld
)。
作为这项工作的一部分,NDB
现在可以区分执行线程类型和其他类型的线程,以及永久分配给特定任务的线程类型,以及仅分配给临时任务的线程类型。
NDB 7.6.4 还为ThreadCOnfig引入了nosend
参数。通过将此设置为 1,可以防止main
,ldm
,rep
或tc
线程协助发送线程。默认情况下,此参数为 0,并且不能与 I/O 线程,发送线程,索引生成线程或看门狗线程一起使用。
有关其他信息,请参见参数说明。
-
DDL 批量数据操作的批量大小可变. 在通过ndbmtd优化批量 DDL 性能的工作中,现在可以通过增加 DDL 操作处理数据的批量数据部分的批量大小来获得性能改进。扫描。现在,通过设置以下列出的各个数据节点配置参数,可以将批次大小配置为可用于唯一索引构建,外键构建和联机重组。
-
MaxUIBuildBatchSize:用于构建唯一密钥的最大扫描批处理大小。
-
MaxFKBuildBatchSize:用于构建外键的最大扫描批处理大小。
-
MaxReorgBuildBatchSize:用于重组 table 分区的最大扫描批处理大小。
-
对于刚刚列出的每个参数,默认值为 64,最小值为 16,最大值为 512.
增加适当的批处理大小可以帮助分摊线程间和节点间的延迟,并利用更多的并行资源(本地和远程)来帮助扩展 DDL 性能。在每种情况下,都可能需要权衡持续的流量。
- 部分 LCP. NDB 7.6.4 实现部分局部检查点。以前,LCP 总是复制整个数据库。当使用 TB 级数据时,此过程可能需要大量时间,特别是对节点和群集重新启动产生不利影响,并为重做日志提供更多空间。现在,不再严格要求 LCP 执行此操作,而是默认情况下,LCP 现在仅保存许多记录,这些记录基于自上一个 LCP 以来更改的数据量。这可以在一个完整的检查点和一个完全不变的检查点之间变化。如果检查点反映了任何更改,则最低要求是写入 2048 的一部分以组成本地 LCP。
作为此更改的一部分,此版本中引入了两个新的数据节点配置参数:EnablePartialLcp(默认为true
或已启用)启用部分 LCP。 RecoveryWork控制分配给 LCP 的空间百分比;与正常操作期间在重新启动期间必须在 LCP 上执行的工作量相比,它会增加。提高该值会导致 LCP 在正常操作期间需要写入更少的记录,因此减少了通常的工作量。增大此值还意味着重新启动可能需要更长的时间。
您必须通过设置EnablePartialLcp=false
显式禁用部分 LCP。这使用最少的磁盘,但也趋于使 LCP 的写负载最大化。要在正常运行期间优化 LCP 的最低工作负载,请使用EnablePartialLcp=true
和RecoveryWork=100
。要为部分 LCP 使用最少的磁盘空间,但要进行写操作,请使用EnablePartialLcp=true
和RecoveryWork=25
(这是RecoveryWork
的最小值)。默认值为EnablePartialLcp=true
和RecoveryWork=50
,这意味着 LCP 文件大约需要DataMemory的 1.5 倍;使用CompressedLcp=1,可以进一步减少一半。使用默认设置的恢复时间也应该比EnablePartialLcp
设置为false
时要快得多。
Note
在 NDB 7.6.5 中,RecoveryWork
的默认值从 50 增加到 60.
另外,现在不推荐使用数据节点配置参数BackupDataBufferSize,BackupWriteSize和BackupMaxWriteSize,并且在以后的 MySQL NDB Cluster 版本中会删除它们。
作为此增强功能的一部分,已经进行了一些工作来纠正节点重新启动的几个问题,其中在各种情况下都可能用完撤消日志,最常见的情况是还原密集时间段内长时间停机的节点写活动。
通过在此过程中更新 LCP 看门狗,并更好地跟踪磁盘数据同步进度,还进行了其他工作以提高数据节点长时间同步的生存性,而不会超时。以前,如果同步花费的时间长于 LCP 看门狗超时,则可能会出现虚假警告甚至节点故障。
Important
将使用磁盘数据 table 的 NDB 群集升级到 NDB 7.6.4 或将其从 NDB 7.6.4 降级时,必须使用--initial重新启动所有数据节点。
- 并行撤消日志记录处理. 以前,数据节点
LGMAN
内核块按 Sequences 处理撤消日志记录;现在,这是并行完成的。将撤消记录交给 LDM 线程的 rep 线程 awaitLDM 完成记录的应用,然后再获取下一个记录。现在 rep 线程不再 await,而是立即进入下一条记录和 LDM。
保留LGMAN
中每个 LDM 的未完成日志记录的数量,并在 LDM 完成记录的执行时递减。属于一个页面的所有记录都发送到同一个 LDM 线程,但是不能保证按 Sequences 进行处理,因此具有出色记录的页面的哈希图会为每个页面维护一个队列。当页面缓存中的页面可用时,队列中所有未决记录将按 Sequences 应用。
几种记录类型将 continue 按 Sequences 处理:UNDO_LCP
,UNDO_LCP_FIRST
,UNDO_LOCAL_LCP
,UNDO_LOCAL_LCP_FIRST
,UNDO_DROP
和UNDO_END
。
与该性能增强没有直接关系的用户可见的功能更改;这是改善还原长时处理工作的一部分,以支持 NDB Cluster 7.6.4 中的局部本地检查点。
- 从扩展区读取 table 和碎片 ID,以应用撤消日志. 应用撤消日志时,有必要从页面 ID 中获取 tableID 和碎片 ID。这是通过使用额外的
PGMAN
工作线程从PGMAN
内核块读取页面来完成的,但是在应用撤消日志时,有必要再次读取该页面。
使用O_DIRECT
时,效率很低,因为该页面未缓存在 OS 内核中。为了解决此问题,现在使用来自扩展区头的信息,给定扩展区中使用的页面的 tableID 和分片 ID,来完成从页面 ID 到 tableID 和分片 ID 的 Map。扩展页页面始终存在于页面缓存中,因此执行 Map 不需要磁盘额外的读取。此外,使用现有的TSMAN
内核块数据结构已经可以读取信息。
有关更多信息,请参见ODirect数据节点配置参数的描述。
- NDB Cluster Auto-Installer 的改进. 在 NDB 7.6.4 中,节点配置参数,其默认值和在 Auto-Installer 中找到的文档已与 NDB Cluster 软件版本中的更好地保持一致。 SSH 支持和配置也得到了改进。另外,默认情况下,HTTPS 现在默认用于 Web 连接,并且 cookie 不再用作持久数据存储机制。在接下来的几段中,将提供有关自动安装程序中这些以及其他更改的更多信息。
现在,自动安装程序实现了一种机制,用于设置采用离散值的配置参数。例如,现在必须将数据节点参数Arbitration设置为其允许值Default
,Disabled
或WaitExternal
之一。
现在,自动安装程序还将获取并显示每个主机可用于群集的磁盘空间量(如DiskFree
),并使用此信息获取依赖于此配置参数的实际值。
在 NDB Cluster 7.6.4 中,MySQL NDB Cluster Auto-Installer 中的安全连接支持已更新或改进,如下所示:
-
添加了为每个主机设置 SSH 成员资格的机制。
-
将 Paramiko Python 模块更新为最新的可用版本(2.6.1)。
-
在 GUI 中为加密的私钥密码提供了一个位置,并停止使用诸如
Password=None
之类的硬编码密码。
-
NDB 7.6.4 中实现的与数据安全性有关的其他增强功能包括:
-
不再使用 cookie 作为 NDB 群集配置信息的永久存储;这些都是不安全的,并且具有严格的存储上限。现在,自动安装程序为此目的使用了加密文件。
- 为了确保用户 Web 浏览器中的 JavaScript 前端与后端中的 Python Web 服务器之间的数据传输安全,已将其默认通信协议从 HTTP 切换为 HTTPS。
有关更多信息,请参见第 21.2.1 节“ NDB 群集自动安装程序(NDB 7.5)”。
- 共享内存传输器. NDB 7.6.6 和更高版本支持在同一主机上的数据节点和 API 节点之间的用户定义的共享内存(SHM)连接,并且不再被视为试验性的。您可以通过将相关数据节点的UseShm配置参数设置为
1
来启用显式共享内存连接。当显式定义共享内存作为连接方法时,还必须用HostName
标识数据节点和 API 节点。
通过在群集配置文件(config.ini
)的[shm]
或[shm default]
部分中设置诸如ShmSize,ShmSpintime和SendBufferMemory之类的参数,可以增强 SHM 连接的性能。 SHM 的配置与 TCP 传输器的配置类似。
SigNum参数未在新的 SHM 实现中使用,现在已忽略对其所做的任何设置。 第 21.3.3.12 节“ NDB 群集共享内存连接”,提供有关这些参数的更多信息。另外,作为这项工作的一部分,与旧 SCI 传输器有关的NDB
代码已被删除。
有关更多信息,请参见第 21.3.3.12 节“ NDB 群集共享内存连接”。
- SPJ 块内部联接优化. 在 NDB 7.6.6 和更高版本中,当
SPJ
内核块在评估其中至少某些 table 是 INNER-joined 的联接请求时可以考虑。这意味着,一旦知道前面的一个或多个请求未返回父行的任何结果,就可以消除对行,范围或两者的请求。这样可以节省数据节点和SPJ
块,而不必处理从不参与 INNER 联接的结果行的请求和结果行。
考虑以下联接查询,其中pk
是 tablet2,t3 和 t4 的主键,而 x,y 和 z 列是未索引的列:
SELECT * FROM t1
JOIN t2 ON t2.pk = t1.x
JOIN t3 ON t3.pk = t1.y
JOIN t4 ON t4.pk = t1.z;
以前,这导致了SPJ
请求,其中包括对 tablet1
的扫描以及对 tablet2
,t3
和t4
的查找;对从t1
返回的每一行进行评估。为此,SPJ
为 tablet2
,t3
和t4
创建了LQHKEYREQ
个请求。现在SPJ
考虑到以下要求:要产生任何结果行,内部联接必须在所有联接的 table 中找到一个匹配项。一旦未找到任何一个 table 的匹配项,就立即跳过对具有相同父 table 或 table 的 table 的任何其他请求。
Note
在集群中的所有数据节点和所有 API 节点都已升级到 NDB 7.6.6 或更高版本之前,无法应用此优化。
- NDB 唤醒线程.
NDB
使用轮询接收器从套接字读取,执行来自套接字的消息以及唤醒其他线程。当仅间歇使用接收线程时,在开始唤醒其他线程之前放弃轮询所有权,这在接收线程中提供了一定程度的并行性,但是,如果不断使用接收线程,则可能使该线程负担过重通过任务包括唤醒其他线程。
NDB 7.6.6 及更高版本支持接收方线程将唤醒其他线程的任务卸载到新线程,该任务根据请求唤醒其他线程(否则只是休眠),从而有可能提高单个群集连接的容量大约减少百分之十到百分之二十。
-
自适应 LCP 控制. NDB 7.6.7 实现了自适应 LCP 控制机制,该机制响应重做日志空间使用情况的变化而起作用。通过控制 LCP 磁盘的写入速度,可以帮助防止许多与资源相关的问题,包括:
-
CPU 资源不足,无法进行流量应用
-
Disk overload
-
重做日志缓冲区不足
-
GCP 停止条件
-
重做日志空间不足
-
撤消日志空间不足
-
这项工作包括与NDB配置参数有关的以下更改:
-
RecoveryWork数据节点参数的默认值从 50 增加到 60;也就是说,
NDB
现在使用数据大小的 1.6 倍来存储 LCP。- 新的数据节点配置参数InsertRecoveryWork通过控制为插入操作保留的
RecoveryWork
的百分比,提供了其他调整功能。默认值为 40(即RecoveryWork
已保留的存储空间的 40%);最小值和最大值分别为 0 和 70.增大此值可以在 LCP 期间执行更多写操作,同时限制 LCP 的总大小。减小InsertRecoveryWork
会限制 LCP 期间使用的写入次数,但会导致 LCP 使用更多的空间,这意味着恢复需要更长的时间。
- 新的数据节点配置参数InsertRecoveryWork通过控制为插入操作保留的
这项工作主要是实现 LCP 速度的控制,以最大程度地减少用尽重做日志的风险。根据使用的重做日志空间的数量(使用警报级别)以及达到这些级别时所采取的响应,以适应性方式完成此操作,如下所示:
-
低 :重做日志空间使用率大于 25%,或者估计的使用率显示以很高的事务处理率出现的重做日志空间不足。作为响应,在 LCP 扫描期间增加了 LCP 数据缓冲区的使用,增加了 LCP 扫描的优先级,并且在 LCP 扫描中每个实时中断可写入的数据量也增加了。
-
高 :重做日志空间使用率大于 40%,或估计以高事务处理率用完重做日志空间。当达到使用水平时,MaxDiskWriteSpeed增加到MaxDiskWriteSpeedOtherNodeRestart的值。此外,最小速度提高了一倍,LCP 扫描的优先级以及每个实时中断可以写入的内容都进一步增加。
-
严重 :重做日志空间使用率大于 60%,或估计的使用率显示在正常事务速率下重做日志空间不足。在此级别上,
MaxDiskWriteSpeed
增加到MaxDiskWriteSpeedOwnRestart的值; MinDiskWriteSpeed也设置为此值。 LCP 扫描的优先级和每个实时中断可以写入的数据量进一步增加,并且 LCP 数据缓冲区在 LCP 扫描期间完全可用。
-
升高级别还具有提高计算出的目标检查点速度的效果。
对于NDB
安装,LCP 控制具有以下好处:
-
现在,使用默认配置,群集应该可以承受非常重的负载,比以前更好。
- 现在,
NDB
应该可以在可用磁盘空间(至少)为分配给它的内存量(DataMemory)的 2.1 倍的系统上可靠地运行。您应注意,该图不包含用于磁盘数据 table 的任何磁盘空间。
- 现在,
-
ndb_restore 选项. 从 NDB 7.6.9 开始,调用ndb_restore时都需要--nodeid和--backupid选项。
-
按切片还原. 从 NDB 7.6.13 开始,可以将备份分为大致相等的部分(切片),并使用为ndb_restore实现的两个新选项并行还原这些切片:
-
--num-slices确定应将备份划分为多个片。
- --slice-id提供要由ndb_restore的当前实例还原的切片的 ID。
这使得可以使用多个ndb_restore实例并行还原备份的子集,从而有可能减少执行还原操作所需的时间。
有关更多信息,请参见ndb_restore --num-slices选项的描述。
- ndb_restore:主键架构更改. 当使用--allow-pk-changes选项运行_时,使用ndb_restore还原
NDB
本机备份时,NDB 7.6.14(及更高版本)支持源 table 和目标 table 的不同主键定义。支持增加和减少构成原始主键的列数。
当主键扩展有一个或多个附加列时,必须将添加的任何列定义为NOT NULL
,并且在进行备份的过程中任何此类列中的值都不得更改。由于某些应用程序在更新时将所有列值设置为一行,因此无论是否实际更改了所有值,即使未更改要添加到主键的列中的值,这也可能导致还原操作失败。您可以使用也在 NDB 7.6.14 中添加的--ignore-extended-pk-updates选项来覆盖此行为;在这种情况下,必须确保不更改任何此类值。
无论该列是否仍是 table 的一部分,都可以从 table 的主键中删除该列。
有关更多信息,请参见ndb_restore的--allow-pk-changes选项的描述。
- ndb_blob_tool 增强功能. 从 NDB 7.6.14 开始,ndb_blob_toolUtil 可以检测到存在内联部分的丢失的 blob 部分,并用正确长度的占位符 blob 部分(由空格字符组成)替换。要检查是否缺少斑点部分,请在此程序中使用--check-missing选项。要将所有丢失的 BlobComponent 替换为占位符,请使用--add-missing选项。
有关更多信息,请参见第 21.4.6 节“ ndb_blob_tool —检查和修复 NDB 群集 table 的 BLOB 和 TEXT 列”。
- 使用 ndb_restore 合并备份. 在某些情况下,可能希望将最初存储在 NDB Cluster 的不同实例中的数据(都使用相同的架构)合并到单个目标 NDB Cluster 中。现在,当使用在ndb_mgmClient 端(请参阅第 21.5.8.2 节“使用 NDB 群集 ManagementClient 端创建备份”)中创建的备份并使用ndb_restore还原备份时,使用 NDB 7.6.14 中添加的--remap-column选项和--restore-data(以及根据需要或期望的其他兼容选项)来支持此功能。
--remap-column
可用于处理主键值和唯一键值在源群集之间重叠的情况,并且有必要使它们在目标群集中不重叠,以及保留 table 之间的其他关系(例如外键)。
--remap-column以其格式为db.tbl.col:fn:args
的字符串作为参数,其中* db
, tbl
和 col
分别是数据库,table 和列的名称, fn
是重 Map 函数的名称和 args
是 fn
的一个或多个参数。没有默认值。仅支持offset
作为函数名, args
*是从备份插入到目标 table 中时应用于列值的整数偏移量。此列必须为INT或BIGINT之一;偏移值的允许范围与该类型的带符号版本相同(如果需要,这可以使偏移值为负)。
可以在ndb_restore的同一调用中多次使用 new 选项,以便可以将同一 table,不同 table 或这两者的多个列重新 Map 到新值。偏移值不必对于该选项的所有实例都相同。
另外,为ndb_desc提供了两个新选项,它们也从 NDB 7.6.14 开始:
-
--auto-inc(缩写为
-a
):如果 table 具有AUTO_INCREMENT
列,则在输出中包括下一个自动增量值。- --context(缩写为
-x
):提供有关 table 的其他信息,包括架构,数据库名称,table 名称和内部 ID。
- --context(缩写为
有关更多信息和示例,请参见--remap-column选项的描述。
- -ndb-log-fail-terminate 选项. 从 NDB 7.6.14 开始,只要无法完全记录所有行事件,就可以使 SQL 节点终止。这可以通过使用--ndb-log-fail-terminate选项启动mysqld来完成。