content_image/830921.jpg
CREATE TABLE ‘ndb_binlog_index‘ ( ‘Position‘ BIGINT(20) UNSIGNED NOT NULL, ‘File‘ VARCHAR(255) NOT NULL, ‘epoch‘ BIGINT(20) UNSIGNED NOT NULL, ‘inserts‘ INT(10) UNSIGNED NOT NULL, ‘updates‘ INT(10) UNSIGNED NOT NULL, ‘deletes‘ INT(10) UNSIGNED NOT NULL, ‘schemaops‘ INT(10) UNSIGNED NOT NULL, ‘orig_server_id‘ INT(10) UNSIGNED NOT NULL, ‘orig_epoch‘ BIGINT(20) UNSIGNED NOT NULL, ‘gci‘ INT(10) UNSIGNED NOT NULL, ‘next_position‘ bigint(20) unsigned NOT NULL, ‘next_file‘ varchar(255) NOT NULL, PRIMARY KEY (‘epoch‘,‘orig_server_id‘,‘orig_epoch‘) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; 

<img src='content_image/830921.jpg'>

## Note 

If you are upgrading from an older release (prior to NDB 7.5.2), perform the MySQL upgrade procedure and ensure that the system tables are upgraded. (As of MySQL 8.0.16, start the server with the --upgrade=FORCE  option. Prior to MySQL 8.0.16, invoke mysql_upgrade  with the --force  and --upgrade-system-tables options after starting the server.) The system table upgrade causes an ALTER TABLE ... ENGINE=INNODB  statement to be executed for this table. Use of the MyISAM  storage engine for this table continues to be supported for backward compatibility. 

ndb_binlog_index  may require additional disk space after being converted to InnoDB . If this becomes an issue, you may be able to conserve space by using an InnoDB  tablespace for this table, changing its ROW_FORMAT  to COMPRESSED , or both. For more information, see Section 13.1.21, “CREATE TABLESPACE Statement” , and Section 13.1.20, “CREATE TABLE Statement” , as well as Section 15.6.3, “Tablespaces” . 

The size of the ndb_binlog_index  table is dependent on the number of epochs per binary log file and the number of binary log files. The number of epochs per binary log file normally depends on the amount of binary log generated per epoch and the size of the binary log file, with smaller epochs resulting in more epochs per file. You should be aware that empty epochs produce inserts to the ndb_binlog_index  table, even when the --ndb-log-empty-epochs  option is OFF , meaning that the number of entries per file depends on the length of time that the file is in use; this relationship can be represented by the formula shown here: 

[number of epochs per file] = [time spent per file] / TimeBetweenEpochs 

A busy NDB Cluster writes to the binary log regularly and presumably rotates binary log files more quickly than a quiet one. This means that a “quiet”  NDB Cluster with --ndb-log-empty-epochs=ON  can actually have a much higher number of ndb_binlog_index  rows per file than one with a great deal of activity. 

When mysqld  is started with the --ndb-log-orig  option, the orig_server_id  and orig_epoch columns store, respectively, the ID of the server on which the event originated and the epoch in which the event took place on the originating server, which is useful in NDB Cluster replication setups employing multiple sources. The SELECT  statement used to find the closest binary log position to the highest applied epoch on the replica in a multi-source setup (see Section 23.6.10, “NDB Cluster Replication: Bidrectional and Circular Replication” ) employs these two columns, which are not indexed. This can lead to performance issues when trying to fail over, since the query must perform a table scan, especially when the source has been running with --ndb-log-empty-epochs=ON . You can improve multi-source failover times by adding an index to these columns, as shown here: 

