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

The operation scenario written in this page is not affected by read/write services. Therefore, its impact on the services caused by CUBRID operation is very limited. There can be two types of operation scenarios in which failover occurs or it does not occur.

When Failover Does Not Occur

You can perform the following operations without stopping and restarting nodes in CUBRID HA groups.

General Operation

Scenario

Consideration

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.
Changing schema must be processed without any failover.
Index change and authority change other than the schema change can be performed by stopping each node and executing standalone mode (ex: the -S option of the csql utility) when the operation time is important.

Add 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 is an issue, operation task can be performed by stopping each node and executing standalone mode (ex: the -S of the cubrid addvoldb utility).

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 in each node after configuration change (ha_node_list, ha_replica_list) without restarting the previously configured CUBRID HA group.

Starts or stops the copylogdb/applylogdb processes which were added or deleted by loading changed configuration information.

Broker server expansion

Run additional brokers without restarting existing brokers.

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

When Failover Occurs

You must stop nodes in CUBRID HA group and complete operation before performing the following operations. 

General Operation

Scenario

Consideration

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.