Mysql中mysql库详解14--ndb_binlog_index表
- 环境基于Centos7.6
1.作用
存储NDB群集复制的二进制日志信息,提供查询NDB集群引擎相关的统计信息。从NDB 7.5.2开始,ndb_binlog_index表使用InnoDB存储引擎。
2.详解
NDB Cluster Replication 使用 ndb_binlog_index
table 来存储二进制 log 的索引数据。由于该表是每个 MySQL 服务器的本地表并且不参与集群,因此它使用 InnoDB
存储引擎。这意味着它必须在参与源集群的每个mysqld上单独创建 。(二进制日志本身包含来自集群中所有 MySQL 服务器的更新。)该表定义如下:
1 | CREATE TABLE `ndb_binlog_index` ( |
在 NDB 7.5.2 之前,此表始终使用 MyISAM
存储引擎。如果您是从早期版本升级,您可以 在启动服务器后使用 mysql_upgrade和 --force
和 --upgrade-system-tables
选项。)系统表升级导致ALTER TABLE ... ENGINE=INNODB
对该表执行语句。MyISAM
继续支持为此表使用存储引擎以实现向后兼容性。
ndb_binlog_index
转换为InnoDB
. 如果这成为一个问题,您可以通过InnoDB
为此表使用表空间、将其更改ROW_FORMAT
为 COMPRESSED
或两者兼而有之来节省空间。
ndb_binlog_index
表 的大小取决于每个二进制日志文件的纪元数和二进制日志文件的数量。每个二进制日志文件的纪元数通常取决于每个纪元生成的二进制日志数量和二进制日志文件的大小,纪元越小,每个文件的纪元越多。您应该知道ndb_binlog_index
,即使--ndb-log-empty-epochs
选项为 OFF
,空时期也会向表中 插入 ,这意味着每个文件的条目数取决于文件使用的时间长度;这种关系可以用此处显示的公式表示:
1 | [number of epochs per file] = [time spent per file] / TimeBetweenEpochs |
繁忙的 NDB Cluster 定期写入二进制日志,并且可能比安静的更快速地旋转二进制日志文件。这意味着一个“安静”的NDB 集群 --ndb-log-empty-epochs=ON
实际上ndb_binlog_index
每个文件的行数比有大量活动的 行数要多得多。
当mysqld使用该--ndb-log-orig
选项启动时 , orig_server_id
和 orig_epoch
列分别存储事件发生的服务器的 ID 和事件发生在原始服务器上的时代,这在使用多个源的 NDB Cluster 复制设置中很有用. SELECT
用于在多源设置中查找副本上最高应用纪元的最接近二进制日志位置的语句,使用这两个未编入索引的列。这可能会在尝试故障转移时导致性能问题,因为查询必须执行表扫描,尤其是当源使用 --ndb-log-empty-epochs=ON
. 您可以通过向这些列添加索引来缩短多源故障转移时间,如下所示:
1 | ALTER TABLE mysql.ndb_binlog_index |
从单个源复制到单个副本时,添加此索引没有任何好处,因为在这种情况下用于获取二进制日志位置的查询不使用 orig_server_id
or orig_epoch
。