ndb_apply_statusis used to keep a record of the operations that have been replicated from the source to the replica. If thendb_apply_statustable does not exist on the replica,ndb_restorere-creates it.

Unlike the case withndb_binlog_index, the data in this table is not specific to any one SQL node in the (replica) cluster, and sondb_apply_statuscan use theNDBCLUSTERstorage engine, as shown here:

CREATE TABLE `ndb_apply_status` ( `server_id` INT(10) UNSIGNED NOT NULL, `epoch` BIGINT(20) UNSIGNED NOT NULL, `log_name` VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL, `start_pos` BIGINT(20) UNSIGNED NOT NULL, `end_pos` BIGINT(20) UNSIGNED NOT NULL, PRIMARY KEY (`server_id`) USING HASH ) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1;

Thendb_apply_statustable is populated only on replicas, which means that, on the source, this table never contains any rows; thus, there is no need to allot anyDataMemorytondb_apply_statusthere.

Because this table is populated from data originating on the source, it should be allowed to replicate; any replication filtering or binary log filtering rules that inadvertently prevent the replica from updatingndb_apply_status, or that prevent the source from writing into the binary log may prevent replication between clusters from operating properly. For more information about potential problems arising from such filtering rules, seeReplication and binary log filtering rules with replication between NDB Clusters.

NDB Cluster Replication uses thendb_binlog_indextable for storing the binary log's indexing data. Since this table is local to each MySQL server and does not participate in clustering, it uses theInnoDBstorage engine. This means that it must be created separately on eachmysqldparticipating in the source cluster. (The binary log itself contains updates from all MySQL servers in the cluster.) This table is defined as follows:

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;

The size of thendb_binlog_indextable 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 thendb_binlog_indextable, even when the--ndb-log-empty-epochsoption isOFF, 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=ONcan actually have a much higher number ofndb_binlog_indexrows per file than one with a great deal of activity.

Whenmysqldis started with the--ndb-log-origoption, theorig_server_idandorig_epochcolumns 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. TheSELECTstatement used to find the closest binary log position to the highest applied epoch on the replica in a multi-source setup (seeSection 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:

ALTER TABLE mysql.ndb_binlog_index ADD INDEX orig_lookup USING BTREE (orig_server_id, orig_epoch);

添加这个索引提供副本时没有好处ting from a single source to a single replica, since the query used to get the binary log position in such cases makes no use oforig_server_idororig_epoch.

SeeSection 23.6.8, “Implementing Failover with NDB Cluster Replication”, for more information about using thenext_positionandnext_filecolumns.

The following figure shows the relationship of the NDB Cluster replication source server, its binary log injector thread, and themysql.ndb_binlog_indextable.

Figure 23.35 The Replication Source Cluster

Thendb_replicationtable is used to control binary logging and conflict resolution, and acts on a per-table basis. Each row in this table corresponds to a table being replicated, determines how to log changes to the table and, if a conflict resolution function is specified, and determines how to resolve conflicts for that table.

Unlike thendb_apply_statusandndb_replicationtables, thendb_replicationtable must be created manually. You can do this by using the SQL statement shown here:

CREATE TABLE mysql.ndb_replication ( db VARBINARY(63), table_name VARBINARY(63), server_id INT UNSIGNED, binlog_type INT UNSIGNED, conflict_fn VARBINARY(128), PRIMARY KEY USING HASH (db, table_name, server_id) ) ENGINE=NDB PARTITION BY KEY(db,table_name);

The columns of this table are listed here, with descriptions:

To enable conflict resolution with NDB Replication, it is necessary to create and populate this table with control information on the SQL node or nodes on which the conflict should be resolved. Depending on the conflict resolution type and method to be employed, this may be the source, the replica, or both servers. In a simple source-replica setup where data can also be changed locally on the replica this is typically the replica. In a more complex replication scheme, such as bidirectional replication, this is usually all of the sources involved. SeeSection 23.6.11, “NDB Cluster Replication Conflict Resolution”, for more information.

Thendb_replicationtable allows table-level control over binary logging outside the scope of conflict resolution, in which caseconflict_fnis specified asNULL, while the remaining column values are used to control binary logging for a given table or set of tables matching a wildcard expression. By setting the proper value for thebinlog_typecolumn, you can make logging for a given table or tables use a desired binary log format, or disabling binary logging altogether. Possible values for this column, with internal values and descriptions, are shown in the following table:

Binary logging can be set to different formats for different tables by inserting rows into thendb_replicationtable using the appropriatedb,table_name, andbinlog_typecolumn values. The internal integer value shown in the preceding table should be used when setting the binary logging format. The following two statements set binary logging to logging of full rows (NBT_FULL, internal value 3) for tabletest.a, and to logging of updates only (NBT_UPDATED_ONLY, internal value 2) for tabletest.b:

# Table test.a: Log full rows INSERT INTO mysql.ndb_replication VALUES("test", "a", 0, 3, NULL); # Table test.b: log updates only INSERT INTO mysql.ndb_replication VALUES("test", "b", 0, 2, NULL);

To disable logging for one or more tables, use 1 (NBT_NO_LOGGING) forbinlog_type, as shown here:

# Disable binary logging for table test.t1 INSERT INTO mysql.ndb_replication VALUES("test", "t1", 0, 1, NULL); # Disable binary logging for any table in 'test' whose name begins with 't' INSERT INTO mysql.ndb_replication VALUES("test", "t%", 0, 1, NULL);