content_image/793753.jpg
•Conflict Resolution Exceptions Table 

•Conflict Detection Status Variables 

•Examples 

When using a replication setup involving multiple sources (including circular replication), it is possible that different sources may try to update the same row on the replica with different data. Conflict resolution in NDB Cluster Replication provides a means of resolving such conflicts by permitting a user-defined resolution column to be used to determine whether or not an update on a given source should be applied on the replica. 

Some types of conflict resolution supported by NDB Cluster ( NDB$OLD() , NDB$MAX() , NDB $MAX_DELETE_WIN() ) implement this user-defined column as a “timestamp”  column (although its type cannot be TIMESTAMP , as explained later in this section). These types of conflict resolution are always applied a row-by-row basis rather than a transactional basis. The epoch-based conflict resolution functions NDB$EPOCH()  and NDB$EPOCH_TRANS()  compare the order in which epochs are replicated (and thus these functions are transactional). Different methods can be used to compare resolution column values on the replica when conflicts occur, as explained later in this section; the method used can be set on a per- table basis. 

You should also keep in mind that it is the application’s responsibility to ensure that the resolution column is correctly populated with relevant values, so that the resolution function can make the appropriate choice when determining whether to apply an update. 

## Requirements 

Preparations for conflict resolution must be made on both the source and the replica. These tasks are described in the following list: 

•On the source writing the binary logs, you must determine which columns are sent (all columns or only those that have been updated). This is done for the MySQL Server as a whole by applying the mysqld startup option --ndb-log-updated-only  (described later in this section) or on a per-table basis by entries in the mysql.ndb_replication  table (see ndb_replication Table). 

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

## Note 

If you are replicating tables with very large columns (such as TEXT  or BLOB columns), --ndb-log-updated-only  can also be useful for reducing the size of the binary logs and avoiding possible replication failures due to exceeding max_allowed_packet . 

See Section 17.5.1.20, “Replication and max_allowed_packet” , for more information about this issue. 

•On the replica, you must determine which type of conflict resolution to apply (“latest timestamp wins” , “same timestamp wins” , “primary wins” , “primary wins, complete transaction” , or none). This is done using the mysql.ndb_replication  system table, on a per-table basis (see ndb_replication Table). 

•NDB Cluster also supports read conflict detection, that is, detecting conflicts between reads of a given row in one cluster and updates or deletes of the same row in another cluster. This requires exclusive read locks obtained by setting ndb_log_exclusive_reads  equal to 1 on the replica. All rows read by a conflicting read are logged in the exceptions table. For more information, see Read conflict detection and resolution. 

When using the functions NDB$OLD() , NDB$MAX() , and NDB$MAX_DELETE_WIN()  for timestamp- based conflict resolution, we often refer to the column used for determining updates as a “timestamp” 

