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 Service

The operation scenario written in this page is only applied to read service. It is required to allow read service only or dynamically change mode configuration of broker to Read Only. 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

Schema change (primary key change)

When an operation task is performed at the master node, it is automatically reflected to the slave node.

In order to change the primary key, the existing key must be deleted and a new one added. For this reason, replication reflection may not occur due to the HA internal structure which reflects primary key-based replication logs. Therefore, operation tasks must be performed during the read service.

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

When an operation task is performed at the master node, it is automatically reflected to the 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 span class="keyword">-S option of csql) when the operation time is important.
When Failover Occurs

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

General Operation

Scenario

Consideration

DBMS version upgrade

Restart each node and broker in the CUBRID HA group after they are upgraded.

A version upgrade means that there have been changed in the internal protocol, volume, or log of CUBRID.
Because there are two different versions of the protocols, volumes, and logs of a broker and server during an upgrade, an operation task must be performed to make sure that each client and broker (before/after upgrade) are connected to the corresponding counterpart in the same version.

Massive data processing (INSERT/UPDATE/DELETE)

Stop the node that must be changed, perform an operation task, and then execute the node.

This processes massive data that cannot be segmented.