column. However, the data type of this column is never  TIMESTAMP ; instead, its data type should be  INT ( INTEGER ) or  BIGINT . The “timestamp”  column should also be  UNSIGNED  and  NOT NULL . The  NDB$EPOCH()  and  NDB$EPOCH_TRANS()  functions discussed later in this section work by comparing the relative order of replication epochs applied on a primary and secondary NDB Cluster, and do not make use of timestamps. Source Column Control Important Conflict Resolution Control 4643 NBT_UPDATED_ONLY_MINIMAL  and  NBT_UPDATED_FULL_MINIMAL  can be used with  NDB$EPOCH() , NDB$EPOCH2() , and  NDB$EPOCH_TRANS() , because these do not require “before”  values of columns which are not primary keys. Conflict resolution algorithms requiring the old values, such as  NDB$MAX() and  NDB$OLD() , do not work correctly with these  binlog_type  values.  Conflict resolution is usually enabled on the server where conflicts can occur. Like logging method selection, it is enabled by entries in the  mysql.ndb_replication  table. To disable the option, start the source  mysqld  with  --ndb-log-update-as-write=0  or  --ndb- log-update-as-write=OFF . You must do this when replicating from NDB tables to tables using a different storage engine; see Replication from NDB to other storage engines, and Replication from NDB to a nontransactional storage engine, for more information. Logging Changed Data as Updates.   The setting of the MySQL Server’s  --ndb-log-update-as- write  option determines whether logging is performed with or without the “before”  image. Because conflict resolution is done in the MySQL Server’s update handler, it is necessary to control logging performed by the replication source such that updates are updates and not writes; that is, such that updates are treated as changes in existing rows rather than the writing of new rows, even though these replace existing rows. This option is turned on by default; in other words, updates are treated as writes. That is, updates are by default written as  write_row  events in the binary log, rather than as  update_row  events. It is usually sufficient—and more efficient—to log updated columns only; however, if you need to log full rows, you can do so by setting  --ndb-log-updated-only  to  0  or  OFF . Logging Full or Partial Rows.  For purposes of conflict resolution, there are two basic methods of logging rows, as determined by the setting of the  --ndb-log-updated-only  option for  mysqld : Whether logging of complete rows or of updated columns only is done is decided when the MySQL server is started, and cannot be changed online; you must either restart  mysqld , or start a new  mysqld  instance with different logging options.  We can see update operations in terms of “before”  and “after”  images—that is, the states of the table before and after the update is applied. Normally, when updating a table with a primary key, the “before” image is not of great interest; however, when we need to determine on a per-update basis whether or not to use the updated values on a replica, we need to make sure that both images are written to the source’s binary log. This is done with the  --ndb-log-update-as-write  option for  mysqld , as described later in this section. NDB Cluster Replication Conflict Resolution •Log only column data that has been updated—that is, column data whose value has been set, regardless of whether or not this value was actually changed. This is the default behavior (option set to OFF ). •Log complete rows (option set to  ON )