NDB Cluster Replication Schema and Tables PARTITION BY KEY(db,table_name); The columns of this table are listed here, with descriptions: The name of the table to be replicated. The table name may include either or both of the wildcards  _  and % . Matching is similar to what is implemented for the  LIKE  operator. The name of the database containing the table to be replicated. You may employ either or both of the wildcards  _  and  %  as part of the database name. Matching is similar to what is implemented for the  LIKE operator. • db  column • table_name  column • server_id  column • binlog_type  column • conflict_fn  column The unique server ID of the MySQL instance (SQL node) where the table resides. The type of binary logging to be employed. See text for values and descriptions. The conflict resolution function to be applied; one of NDB$OLD(column_name), NDB $MAX(column_name), NDB$MAX_DELETE_WIN(), NDB$EPOCH(), NDB$EPOCH_TRANS(), NDB $EPOCH2(), NDB$EPOCH2_TRANS();  NULL  indicates that conflict resolution is not used for this table. See Conflict Resolution Functions, for more information about these functions and their uses in NDB Replication conflict resolution. Some conflict resolution functions ( NDB$OLD() ,  NDB$EPOCH() ,  NDB$EPOCH_TRANS() ) require the use of one or more user-created exceptions tables. See Conflict Resolution Exceptions Table. 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. See Section 23.6.11, “NDB Cluster Replication Conflict Resolution” , for more information. The  ndb_replication  table allows table-level control over binary logging outside the scope of conflict resolution, in which case  conflict_fn  is specified as  NULL , 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 the  binlog_type  column, 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: Table 23.69 binlog_type values, with internal values and descriptions Value Internal Value Description 0 NBT_DEFAULT Use server default 1 NBT_NO_LOGGING Do not log this table in the binary log 2 NBT_UPDATED_ONLY Only updated attributes are logged 4622