Currently, CUBRID HA is supported only by Linux. All nodes within a CUBRID HA group must be configured with the same platform.
CUBRID HA synchronizes data among nodes with the following method (as known as transaction log shipping): First, it replicates the primary key-based replication logs generated from the server of a master node to a slave node. Second, it reflects the replication logs.
If data of the specific table within a CUBRID HA group is not synchronized, you should check whether the appropriate primary key has specified for the table.
Using triggers and java stored procedures in CUBRID HA can cause duplicate execution because triggers and java stored procedures executed in a master node will be executed in a slave node again. This may cause data inconsistency among nodes within a CUBRID HA group.
It is not recommended to use triggers and java stored procedures in CUBRID HA.
CUBRID HA synchronizes data among nodes within a CUBRID HA group based on replication logs. Therefore, using method that does not generate replication logs or configuring NOT NULL through CUBRID Manager may cause data inconsistency among nodes within a CUBRID HA group.
The replication logs are not generated as for tasks performed in stand-alone mode. For this reason, data inconsistency among nodes in a CUBRID HA group may occur when performing tasks in stand-alone mode.
To enhance performance, a serial cache does not access Heap and does not generate replication logs when retrieving or updating serial information. Therefore, if you use a serial cache, the current values of serial caches will be inconsistent among the nodes in a CUBRID HA group.
This command is used to back up a specified database. If the –r option is used, logs that are not required for recovery will be deleted. This deletion may result in data inconsistency among nodes in a HA group. Therefore, you must not use the -r option.
If you use INCR/DECR (click counter functions) in a slave node of HA configuration, an error is returned.
In a CUBRID HA environment, the meta data (Locator) of a LOB column is replicated and data of a LOB type is not replicated. Therefore, if storage of a LOB type is located on the local machine, no tasks on the columns in a slave node or a master node after failover are allowed.