Data consistency
ALTIBASE Replication sender thread tries to transfer XLOG as soon as the changed transaction is issued.
However if there're numerous changed transactions, there may be unsent transaction log although sender thread works hard.
It can cause data inconsistency between ALTIBASE instances. In order to overcome this issue, ALTIBASE inroduce EAGER Replication.
ALTIBASE does not support 2-phase commit protocol, therefore, the order of transactions may not be kept.
DDL Execution in the replicated environment
DDL statements cannot be executed on tables for which the replication recovery option has been
specified.
To execute DDL statements in such a case, drop the tables from the replication object and
execute the DDL statements.
Futhermore, DDL statements cannot be executed while replication is running in EAGER mode.
To execute DDL statements in such a case, stop replication, execute the
DDL statements, and start replication again.
Supposing that the name of a replication target table is t1, A user can execute DDL statements
using REPLICATION_DDL_ENABLE option as follows.
Foreign key constraint
Because parent key makes a pair with child key in the foreign key, even in the event of change occurrence, it can be operated within a range of table having a parent key.
It has few advantages in that it searches for a table which own parent key before change in a table having child key.
We don't recommend you to choose this constraint in a replicated environment as in the filelds of communication which has a high priority in performance.
It can cause problem of data consistency with a mixture of the local transaction and replicated transaction as well as performance degradation.
A consistency problem will be likely to happen in a active:active(Refer to this page) environment which can cause a conflict.
But, there is a way to use a foreign key in a replication environment by modifying a property.
We don't recommend you to use this property as well.
Trigger
Change operation using trigger is not replicated, Because it doesn't pass change to a remote server on a replicated environment.
Even if rows of table, replication target table, is not modified by a triggering event, change will not be applied on the remotely replicated machine.
That's why a trigger doesn't pass the QP step internally, Trigger should be made on a remotely replicated machine.