•Only two NDB Clusters in a birectional “active-active”  configuration are currently supported when using NDB$EPOCH()  or NDB$EPOCH_TRANS()  for conflict detection. 

•Tables having BLOB  or TEXT  columns are not currently supported with NDB$EPOCH()  or NDB $EPOCH_TRANS() . 

## Conflict Resolution Exceptions Table 

To use the NDB$OLD()  conflict resolution function, it is also necessary to create an exceptions table corresponding to each NDB  table for which this type of conflict resolution is to be employed. This is also true when using NDB$EPOCH()  or NDB$EPOCH_TRANS() . The name of this table is that of the table for which conflict resolution is to be applied, with the string $EX  appended. (For example, if the name of the original table is mytable , the name of the corresponding exceptions table name should be mytable$EX .) The syntax for creating the exceptions table is as shown here: 

CREATE TABLE original_table $EX ( [NDB$]server_id INT UNSIGNED, [NDB$]source_server_id INT UNSIGNED, [NDB$]source_epoch BIGINT UNSIGNED, [NDB$]count INT UNSIGNED, [NDB$OP_TYPE ENUM(’WRITE_ROW’,’UPDATE_ROW’, ’DELETE_ROW’, ’REFRESH_ROW’, ’READ_ROW’) NOT NULL,] [NDB$CFT_CAUSE ENUM(’ROW_DOES_NOT_EXIST’, ’ROW_ALREADY_EXISTS’, ’DATA_IN_CONFLICT’, ’TRANS_IN_CONFLICT’) NOT NULL,] [NDB$ORIG_TRANSID BIGINT UNSIGNED NOT NULL,] original_table_pk_columns , [ orig_table_column | orig_table_column $OLD| orig_table_column $NEW,] [ additional_columns ,] PRIMARY KEY([NDB$]server_id, [NDB$]source_server_id, [NDB$]source_epoch, [NDB$]count) ) ENGINE=NDB; 

The first four columns are required. The names of the first four columns and the columns matching the original table’s primary key columns are not critical; however, we suggest for reasons of clarity and consistency, that you use the names shown here for the server_id , source_server_id , source_epoch , and count  columns, and that you use the same names as in the original table for the columns matching those in the original table’s primary key. 

If the exceptions table uses one or more of the optional columns NDB$OP_TYPE , NDB$CFT_CAUSE , or NDB $ORIG_TRANSID  discussed later in this section, then each of the required columns must also be named using the prefix NDB$ . If desired, you can use the NDB$  prefix to name the required columns even if you do not define any optional columns, but in this case, all four of the required columns must be named using the prefix. 

Following these columns, the columns making up the original table’s primary key should be copied in the order in which they are used to define the primary key of the original table. The data types for the columns duplicating the primary key columns of the original table should be the same as (or larger than) those of the original columns. A subset of the primary key columns may be used. 

The exceptions table must use the NDB  storage engine. (An example that uses NDB$OLD()  with an exceptions table is shown later in this section.) 

Additional columns may optionally be defined following the copied primary key columns, but not before any of them; any such extra columns cannot be NOT NULL . NDB Cluster supports three additional, predefined optional columns NDB$OP_TYPE , NDB$CFT_CAUSE , and NDB$ORIG_TRANSID , which are described in the next few paragraphs. 

