content_image/779553.jpg
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. 

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

## 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 

