NDB Cluster Replication Schema and Tables ALTER TABLE mysql.ndb_binlog_index ADD INDEX orig_lookup USING BTREE (orig_server_id, orig_epoch); Adding this index provides no benefit when replicating from a single source to a single replica, since the query used to get the binary log position in such cases makes no use of  orig_server_id  or orig_epoch . See Section 23.6.8, “Implementing Failover with NDB Cluster Replication” , for more information about using the  next_position  and  next_file  columns. The following figure shows the relationship of the NDB Cluster replication source server, its binary log injector thread, and the  mysql.ndb_binlog_index  table. Figure 23.35 The Replication Source Cluster ndb_replication Table The  ndb_replication  table 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 the  ndb_apply_status  and  ndb_replication  tables, the  ndb_replication  table 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 4621