Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.4.0 |  CUBRID 8.4.1 |  CUBRID 8.4.3 |  CUBRID 9.0.0 | 

Load Balancing Structure

The load balancing structure increases the availability of the CUBRID servie by placing several nodes in the HA configuration (one master node and one slave node) and distributes read-load.

Because the replica nodes receive replication logs from the nodes in the HA configuration and maintain the same data, and because the nodes in the HA configuration do not receive replication logs from the replica nodes, its network and disk usage rate is lower than that of the multiple-slave structure.

Because replica nodes are not included in the HA structure, they provide read service without failover, even when all other nodes in the HA structure fail.

admin_ha_comp_replica.png

An Example of Node Configuration

You can configure each node in the basic structure of HA as shown below:

  • node A (master node)
    • Configure the ha_mode of the cubrid.conf file to on.
    • ha_mode=on
    • The following is an example of configuring cubrid_ha.conf:
    • ha_port_id=12345
    • ha_node_list=cubrid@nodeA:nodeB 
    • ha_replica_list=cubrid@nodeC:nodeD
    • ha_db_list=testdb1,testdb2
  • node B (slave node): Configure this node in the same manner as nodeA.
  • node C (replica node)
    • Configure the ha_mode of the cubrid.conf file to replica.
    • ha_mode=replica
    • You can configure the cubrid_ha.conf file in the same manner as nodeA.
  • node D (replica node): Configure this node in the same manner as nodeC.

You must enter the list of DB server hosts in the order so that each broker can be connected appropriate HA or load balancing server in the databases.txt file of a broker node. The following is an example of the databases.txt file:

#db-name    vol-path                  db-host       log-path

testdb1     /home/cubrid/DB/testdb1   nodeA:nodeB   /home/cubrid/DB/testdb1/log

testdb2     /home/cubrid/DB/testdb2   nodeC:nodeD   /home/cubrid/DB/testdb2/log

Caution

The data in the CUBRID HA group may lose integrity when there are multiple failures in this structure.

  • In a situation where a failover occurs in the first slave node while replication in the second slave node is being delayed due to restart
  • In a situation where a failover re-occurs before replication reflection of a new master node is not complete due to frequent failover

In addition, if the mode of replication log copy process is ASYNC, the data in the CUBRID HA group may lose integrity.

If the data in the CUBRID HA group loses integrity for any of the reasons above, you can fix it by using Rebuilding Replications.