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 | 

Operation Scenario during Read/Write Service

Because this operation scenario is not affected by service read/write, its impact on service during CUBRID operation is very limited. Operation scenarios during read/write service are divided into operation scenarios with failover and operation scenarios without failover.

Operation Scenarios without Failover

You can perform the following task without restarting a node after terminating the node in the CUBRID HA group.

Most common operation task

Scenario

Considerations

Online Backup

Operation task is performed at each master node and slave node each during operation.

Note that there may be a delay in the transaction of master node due to the operation task.

Schema change (excluding basic key change), index change, authorization change

When an operation task occurs at a master node, it is automatically replication reflected to a slave node.

Because replication log is copied and reflected to a slave node after an operation task is completed in a master node, operation task time is doubled.
If operation task time becomes an issue, operation task may be performed in the following operation scenario where failover is used.

Add volume, Delete volume

Operation task is performed at each DB regardless of HA structure.

Note that there may be a delay in the transaction of master node due to the operation task.
If operation task time becomes an issue, operation task may be performed in the following operation scenario where failover is used.

Failure node server replacement

It can be replaced without restarting the CUBRID HA group when a failure occurs.

The failure node must be registered in the ha_node_list of CUBRID HA group, and the node name must not be changed during replacement.

Failure broker server replacement

It can be replaced without restarting the broker when a failure occurs.

The connection to a broker replaced at a client can be made by rctime which is configured in URL string.

DB server expansion

You can execute cubrid heartbeat reload after configuration change (ha_node_list, ha_replica_list) without restarting the previously configured CUBRID HA group.

Note that all the management processes of a node are stopped when cubrid heartbeat reload is failed.

Broker server expansion

Run additional brokers without restarting existing brokers.

Modify the URL string to connect to a broker where a client is added.

Operation Scenario with Failover

Run the following task after completing the operation task following the stopping of a node in CUBRID HA group.

Most common operation task

Scenario

Considerations

DB server configuration change

A node whose configuration is changed is restarted when the configuration in cubrid.conf is changed.

 

Change broker configuration, add broker, and delete broker

A broker whose configuration is changed is restarted when the configuration in cubrid_broker.conf is changed.

 

DBMS version patch

Restart nodes and brokers in HA group after version patch.

Version patch means there is no change in the internal protocol, volume, and log of CUBRID.