Glossary

Master Database

The source database that becomes the target of the replication. All operations including a read and write operations are performed in this database.

Slave Database

A replicated database (replica) with the same contents as the master database. Changes in the master database are automatically reflected in the slave database. Unlike the master database, the slave database can be used for read operations only.

Active Server

A server (also called a "primary server") that provides users with services. An active server provides all services including read and write by using the master database.

Standby Server

A server (called called a "secondary," "passive" or "failover" server) that provides services in place of an active server when it cannot provide services due to failure. A standby server provides a read service by using a slave database.

Failover

A feature that allows a standby server to perform the failover and continue to provide services when the failure of an active server or the system running the active server is detected.

Failback

A feature that allows the restored active server to resume services when it is restored to the original state.

Role Change

A feature that allows services to be provided continuously even when the failure in the previous active server is restored.

Heartbeat

An essential element for providing HA features. The CUBRID Heartbeat feature is included in the cub_master process. It exchanges heartbeat messages with cub_master processes of other nodes and executes failover on the standby server when a failure is detected. It also monitors the availability of the HA related processes (cub_server, copylogdb, applylogdb) on a regular basis.

Server Duplication

Building the system with duplicate server hardware to provide HA functionalities. Two methods are used: to allow the standby server to perform the functionality of the active server upon failure (Active-Standby, see the figure below) and to build a duplicate system that provides services while additionally performing the roles of the server upon failure (Active-Active).

Database Server Multiplication

An architecture with multiple database servers so that the service will be provided without interruption even when a database failure occurs. If a failure occurs in an active database providing a service, a standby database with the same data can provide the service.

Broker Multiplication Architecture

An architecture built with broker multiplication so that a service can be provided without interruption by another broker when a failure occurs in a certain broker. In addition, each broker can have different characteristics as described below.

• Read-only broker : A broker that performs read operations only. It provides services through the connection with a standby server. If a standby server does not exist, it can send a read request to an active server. That is, the order of attempting to connect to a database server is as follows: first it attempts to connect to a standby server; if it fails, it can be connected to an active server.
• Slave-only broker : Unlike the read-only broker, a slave-only broker can send a request only to a standby server. It does not attempt to connect to an active server even when a standby server does not exist.

Transaction Log Multiplication

A feature that allows the transaction log created in an active server to be sent in real time to one or more standby servers so that the same log will be recorded in all the servers.

HA Mode of the CUBRID Database Server

• active : A state that provides a service for common read and write requests and creates transaction logs required for replication.
• to-be active : When the state of the server changes from standby to active, it goes through the to-be-active stage before it becomes active. In a to-be-active state, all incoming requests are suspended, and the server changes to an active state after reflecting the unapplied replication log.
• standby : A state that provides a service for read requests only, but denies write requests.
• to-be standby : When the state of the server changes to standby, it goes through the to-be-standby stage before it becomes standby. In a to-be-standby state, incoming requests are denied, and the server changes to a standby state when the transaction being performed is complete.
• maintenance : A mode for database maintenance operations (schema change, configuration change, etc.). You can perform necessary maintenance operations by temporarily excluding the given database from the HA configuration and then running the database in maintenance mode. This mode behaves as follows:
  • Only clients of the local host can connect; copylogdb and applylogdb utilities which replicate or apply the transaction log cannot connect.
  • The database can be modified with write operations, but the replication logs for the changes are not created.

• State change of the database server during failover
  • active server: active -> dead
  • standby server: standby -> to-be-active -> active