This document describes the causes and solutions of replication conflicts.
When data conflicts occur in a replication environment
A replication conflict occurs when insert/update/delete is executed on the same key value at the same time.
● insert conflict: When an INSERT conflict occurs, the INSERT fails and a conflict error message is an output to altibase_rp.log. Use the REPLICATION_INSERT_REPLACE property to set a policy that resolves conflicts that occur when inserting data with the same key as an existing record. REPLICATION_INSERT_REPLACE=1: Insert after deletion. REPLICATION_INSERT_REPLACE=0: Do not delete or insert, and output an error message.
● update conflict: When an UPDATE conflict occurs, the UPDATE fails and a conflict error message is displayed in altibase_rp.log. The REPLICATION_UPDATE_REPLACE property can be used for conflict resolution. This occurs when the previous image changes other data or attempts to change to a primary key that does not exist. For example, if it currently has data of 10 and a replication transaction has an update to change from 20 to 30, the following policy can be used depending on the situation: REPLICATION_UPDATE_REPLACE=1: Update. REPLICATION_UPDATE_REPLACE=0: Does not update and displays a conflict error message.
● delete conflict: When a DELETE conflict occurs, the DELETE fails and a conflict error message is displayed in altibase_rp.log.
For example in the case of insert:
1) After data with key=1 is inserted in server A, before transmitting the replication data to server B
2) When the same key=1 data is inserted in server B, the replication data received later in server B already has data with the same key=1 in server B, so a conflict occurs.
Measures to prevent conflict as much as possible
The best way is to avoid insert/update/delete with the same Key value on both servers.
For example, if the sequence is the primary key for a specific table, if the user inserts/updates/deletes data only with odd numbers on one side and even numbers on the other server, there will be no replication conflict.
In addition, do not do bulk insert/update/delete.
There are three solutions for replication conflict provided by Altibase.
1) User-Oriented Scheme
(1) Insert conflict: If you try to insert data with the same key, it is not reflected. (Output Conflict Error Message to altibase_rp.log)
(2) delete conflict: If you want to delete data with the same key, it is not reflected. (Output Conflict Error Message to altibase_rp.log)
(3) Update conflict: In the case of updating data with the same key, it is specified whether or not it is reflected according to the following attribute values.
-REPLICATION_UPDATE_REPLACE=0: Do not update and it is a conflict
Error message output
2) Master-slave Scheme
When declaring a replication object, if as a master or as a slave is specified in the syntax, the replication conflict is handled as follows.
(1) Master's processing method: All Insert/Update/Delete conflicts are not reflected.
(2) Slave processing method
-Insert conflict: Delete an existing record and add a new record.
-Update conflict: The conflict is ignored and unconditionally reflected.
-Insert conflict: Not reflected.
3) Timestamp-based Scheme
After setting the REPLICATION_TIMESTAMP_RESOLUTION property value to 1, a timestamp column is used in the replication table to reflect the latest value. In this method, there is a limitation that the timestamp column must be added to all of the replication target tables, and the time between both servers being replicated must be set equally.
When a conflict occurs, a log is recorded in $ALTIBASE_HOME/trc/altibase_rp.log.
● Insert conflict: Occurs when the same PK (Primary Key) already exists.
● update conflict: Occurs when the PK (Primary Key) is the same, but the pre-change value from the remote server is different from the current value.