Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.2.1 |  CUBRID 8.3.0 |  CUBRID 8.3.1 | 

HA Utilities

CUBRID utilities used for the HA feature are as follows. The following utilities can be used only in servers where the ha_mode parameter is configured to on.

cubrid changemode

cubrid copylogdb

cubrid applylogdb

Outputting/Configuring the Operation Mode of the Database Server
Description

The syntax for the cubrid changemode utility, which is used to output or change the state of the database server, is as follows. The history of the server error log is output every time the operation mode of the server changes. The current operation mode is output if the -m option is not specified.

Syntax

cubrid changemode [option] <database_name>@<hostname>

option:

-m, --mode=<MODE> : Specifies the mode to change. Available values are active, standby and maintenance.

Example 1

[ha_user1@server_s1 ~]$ cubrid changemode tdb01@server_s1

The server 'tdb01@server_s1''s current HA running mode is active.

 

[ha_user1@server_s1 ~]$ cubrid changemode tdb01@server_s2

The server 'tdb01@server_s2''s current HA running mode is standby.

Example 2

You can check the HA mode of database currently connected by entering ;database command in the CSQL session.

csql> ;database

     demodb@localhost (active)

Saving the Transaction Log of the Database Server
Description

The syntax for the cubrid copylogdb utility, which is used to copy the transaction log created by the remote database server to a specified path, is as follows:

There are three ways of sending the transaction log as follows: You should choose one that meets your operation policy.

  • Synchronous : A database server sends all transaction logs to the copylog process; it does not perform commit until the logs are written to a disk. That is, this method guarantees both to send and write logs. sync is specified for the cubrid copylogdb -m value.
  • Semi-Synchronous : A database server sends all transaction logs to the copylogdb process; it performs commit when it gets response.
    That is, this method guarantees only to send logs; it does not guarantee to write logs. semisync is specified for the cubrid copylogdb -m value.
  • Asynchronous : A database server performs commit right after it sending transaction logs to the copylog log. That is, this method even does not guarantee to send logs. async is specified for the cubrid copylogdb -m value.
Syntax

cubrid copylogdb [option] <database_name>@<hostname>

option:

-L, --log-path=<PATH>: A file path to which the copied transaction log is to be stored.

-m, --mode=<MODE>: Specifies the method by which the transaction log page is to be copied. The one of following options are available: sync, semisync, async. Guaranteeing sending and writing logs jobs is determined by selected mode.

Reflecting the Stored Transaction Log to the Database
Description

The syntax for the cubrid applylogdb utility, which reads the copied transaction log file from the specified path, analyzes it, and then reflects it to the local database server, is as follows:

Syntax

cubrid applylogdb [option] <database_name>@<hostname>

option:

-L, --log-path=<PATH> : The path to the transaction log file to be read.
--max-mem-size=<SIZE> : The maximum memory size available for process. The memory unit is MB; up to 1,000 MB is allowed.

Note The restart condition of the applylogdb process can be configured with the --max-mem-size option. For information about configuring the restart condition of the CAS process according to current memory usage, see the APPL_SERVER_MAX_SIZE parameter in Parameter by Broker. The applylogdb process restarts when the current memory size reaches the size specified in the --max-mem-size, or reaches twice the size of the memory at the start of the process, whichever is larger.