NDB Cluster Replication Schema and Tables This keeps the source  mysqld  process updated to changes performed by the  NDB  storage engine. The NDB binlog injector thread  receives events directly from the  NDB  storage engine. The  NDB  injector is responsible for capturing all the data events within the cluster, and ensures that all events which change, insert, or delete data are recorded in the  ndb_binlog_index  table. The replica I/O thread transfers the events from the source’s binary log to the replica’s relay log. The  ndb_replication  table must be created manually. This table can be updated by the user to perform filtering by database or table. See ndb_replication Table, for more information.  ndb_replication  is also used in NDB Replication conflict detection and resolution for conflict resolution control; see Conflict Resolution Control. Even though  ndb_binlog_index  and  ndb_apply_status  are created and maintained automatically, it is advisable to check for the existence and integrity of these tables as an initial step in preparing an NDB Cluster for replication. It is possible to view event data recorded in the binary log by querying the mysql.ndb_binlog_index  table directly on the source. This can be also be accomplished using the SHOW BINLOG EVENTS  statement on either the source or replica SQL node. (See Section 13.7.7.2, “SHOW BINLOG EVENTS Statement” .) You can also obtain useful information from the output of  SHOW ENGINE NDB STATUS . When performing schema changes on  NDB  tables, applications should wait until the ALTER TABLE  statement has returned in the MySQL client connection that issued the statement before attempting to use the updated definition of the table. ndb_apply_status  is used to keep a record of the operations that have been replicated from the source to the replica. If the  ndb_apply_status  table does not exist on the replica,  ndb_restore  re-creates it. Note ndb_apply_status Table Unlike the case with  ndb_binlog_index , the data in this table is not specific to any one SQL node in the (replica) cluster, and so  ndb_apply_status  can use the  NDBCLUSTER  storage 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; The  ndb_apply_status  table is populated only on replicas, which means that, on the source, this table never contains any rows; thus, there is no need to allot any  DataMemory  to  ndb_apply_status  there. 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 updating ndb_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, see Replication and binary log filtering rules with replication between NDB Clusters. NDB Cluster Replication uses the  ndb_binlog_index  table 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 the  InnoDB storage engine. This means that it must be created separately on each  mysqld  participating in the source cluster. (The binary log itself contains updates from all MySQL servers in the cluster.) This table is defined as follows: ndb_binlog_index Table 4619