CUBRID HA
HA (고 가용성)는 하드웨어, 소프트웨어 또는 네트워크 장애시 중단없는 서비스를 제공하는 기능을 말합니다. 이 기능은 서비스를 24 시간 제공해야하는 네트워크 컴퓨팅 영역에서 중요한 요소입니다. HA 시스템은 둘 이상의 서버 시스템으로 구성되며 각 시스템은 장애가 발생하더라도 중단없는 서비스를 제공합니다.
CUBRID HA는 고 가용성 구현입니다. CUBRID HA는 서비스 제공시 여러 서버 간의 데이터베이스 동기화를 보장합니다. 서비스를 운영하는 시스템에서 예기치 않은 장애가 발생하면이 기능은 다른 시스템이 서비스를 자동으로 수행 할 수 있도록하여 서비스 중단 시간을 최소화합니다.
CUBRID HA는 비공유 구조입니다. CUBRID HA는 활성 서버에서 대기 서버로 데이터를 동기화하기 위해 다음 두 단계를 수행한다.
트랜잭션 로그 멀티플렉싱 : 활성 서버에서 만든 트랜잭션 로그를 다른 노드로 실시간 복제합니다.
트랜잭션 로그 반영 : 복제 된 트랜잭션 로그를 실시간으로 분석하고 데이터를 대기 서버에 반영합니다.
CUBRID HA는 활성 서버와 대기 서버 간의 데이터 동기화를 항상 유지하기 위해 위에서 설명한 단계를 수행한다. 이러한 이유로, 서비스를 제공 한 마스터 노드에서 장애가 발생하여 활성 서버가 제대로 작동하지 않으면 슬레이브 노드의 대기 서버는 장애가 발생한 서버 대신 서비스를 제공합니다. CUBRID HA는 시스템 및 CUBRID의 상태를 실시간으로 모니터링합니다. 장애 발생시 하트 비트 메시지를 사용하여 자동 장애 조치를 실행합니다.
_images / image13.png
CUBRID HA 개념
노드와 그룹
노드는 CUBRID HA를 구성하는 논리적 단위입니다. 상태에 따라 마스터 노드, 슬레이브 노드 또는 복제본 노드 중 하나가 될 수 있습니다.
마스터 노드 : 복제 할 노드. 활성 서버를 사용하여 읽고 쓰는 등의 모든 서비스를 제공합니다.
슬레이브 노드 : 마스터 노드와 동일한 정보를 갖는 노드. 마스터 노드에서 변경 한 내용은 슬레이브 노드에 자동으로 반영됩니다. 대기 서버를 사용하여 읽기 서비스를 제공하며 마스터 노드가 실패하면 장애 조치가 발생합니다.
Replica node : 마스터 노드와 동일한 정보를 갖는 노드. 마스터 노드에서 변경 한 내용은 자동으로 복제본 노드에 반영됩니다. 대기 서버를 사용하여 읽기 서비스를 제공하며 마스터 노드가 실패해도 장애 조치가 발생하지 않습니다.
CUBRID HA 그룹은 위에서 설명한 노드들로 구성된다. cubrid_ha.conf 파일에서 ha_node_list 및 ha_replica_list를 사용하여이 그룹의 구성원을 구성 할 수 있습니다. 그룹의 노드는 동일한 정보를 갖습니다. 상태 점검 메시지를 주기적으로 교환하며 마스터 노드가 실패하면 장애 조치가 발생합니다.
노드에는 마스터 프로세스 (cub_master), 데이터베이스 서버 프로세스 (cub_server), 복제 로그 복사 프로세스 (copylogdb), 복제 로그 반영 프로세스 (applylogdb) 등이 포함됩니다.
_images / image14.png
프로세스
CUBRID HA 노드는 하나의 마스터 프로세스 (cub_master), 하나 이상의 데이터베이스 서버 프로세스 (cub_server), 하나 이상의 복제 로그 복사 프로세스 (copylogdb) 및 하나 이상의 복제 로그 반영 프로세스 (applylogdb)로 구성됩니다. 데이터베이스가 구성되면 데이터베이스 서버 프로세스, 복제 로그 복사 프로세스 및 복제 로그 반영 프로세스가 시작됩니다. 복제 로그의 복사 및 반영은 다른 프로세스에 의해 실행되므로 반영 복제 지연은 실행중인 트랜잭션에 영향을 미치지 않습니다.
마스터 프로세스 (cub_master) : 하트 비트 메시지를 교환하여 CUBRID HA의 내부 관리 프로세스를 제어한다.
데이터베이스 서버 프로세스 (cub_server) : 사용자에게 읽기 또는 쓰기와 같은 서비스를 제공합니다. 자세한 내용은 서버를 참조하십시오.
복제 로그 복사 프로세스 (copylogdb) : 그룹의 모든 트랜잭션 로그를 복사합니다. 복제 로그 복사 프로세스가 대상 노드의 데이터베이스 서버 프로세스에서 트랜잭션 로그를 요청하면 데이터베이스 서버 프로세스는 해당 로그를 리턴합니다. 복사 된 트랜잭션 로그의 위치는 cubrid_ha.conf의 ha_copy_log_base에서 구성 할 수 있습니다. applyinfo 유틸리티를 사용하여 복사 된 복제 로그 정보를 확인하십시오. 복제 로그 복사 프로세스에는 SYNC 및 ASYNC의 두 가지 모드가 있습니다. cubrid_ha.conf의 ha_copy_sync_mode를 사용하여 구성 할 수 있습니다. 이러한 모드에 대한 자세한 내용은 로그 멀티플렉싱을 참조하십시오.
_images / image15.png
복제 로그 반영 프로세스 (applylogdb) : 복제 로그 복사 프로세스에서 복사 한 로그를 노드에 반영합니다. 반영된 복제 정보는 내부 카탈로그 (db_ha_apply_info)에 저장됩니다. applyinfo 유틸리티를 사용하여이 정보를 확인할 수 있습니다.
_images / image16.png
서버
여기서 "서버"라는 단어는 데이터베이스 서버 프로세스의 논리적 표현입니다. 상태에 따라 서버는 활성 서버 또는 대기 서버 일 수 있습니다.
CUBRID HA is in a shared-nothing structure. To synchronize data from an active server to a standby server, CUBRID HA executes the following two steps.
Transaction log multiplexing: Replicates the transaction logs created by an active server to another node in real time.
Transaction log reflection: Analyzes replicated transaction logs in real time and reflects the data to a standby server.
CUBRID HA executes the steps described above in order to always maintain data synchronization between an active server and a standby server. For this reason, if an active server is not working properly because of a failure occurring in the master node that had been providing service, the standby server of the slave node provides service instead of the failed server. CUBRID HA monitors the status of the system and CUBRID in real time. It uses heartbeat messages to execute an automatic failover when a failure occurs.
_images/image13.png
CUBRID HA Concept
Nodes and Groups
A node is a logical unit that makes up CUBRID HA. It can become one of the following nodes according to its status: master node, slave node, or replica node.
Master node : A node to be replicated. It provides all services which are read, write, etc. using an active server.
Slave node : A node that has the same information as a master node. Changes made in the master node are automatically reflected to the slave node. It provides the read service using a standby server, and a failover will occur when the master node fails.
Replica node : A node that has the same information as a master node. Changes made in the master node are automatically reflected to the replica node. It provides the read service using a standby server, and no failover will occur when the master node fails.
The CUBRID HA group consists of the nodes described above. You can configure the members of this group by using the ha_node_list and ha_replica_list in the cubrid_ha.conf file. Nodes in a group have the same information. They exchange status checking messages periodically and a failover will occurs when the master node fails.
A node includes the master process (cub_master), the database server process (cub_server), the replication log copy process (copylogdb), the replication log reflection process (applylogdb), etc.
_images/image14.png
Processes
A CUBRID HA node consists of one master process (cub_master), one or more database server processes (cub_server), one or more replication log copy processes (copylogdb), and one or more replication log reflection processes (applylogdb). When a database is configured, database server processes, replication log copy processes, and replication log reflection processes will start. Because copy and reflection of a replication log are executed by different processes, the delay in replicating reflections does not affect the transaction that is being executed.
Master process (cub_master) : Exchanges heartbeat messages to control the internal management processes of CUBRID HA.
Database server process (cub_server) : Provides services such as read or write to the user. For details, see Servers.
Replication log copy process (copylogdb) : Copies all transaction logs in a group. When the replication log copy process requests a transaction log from the database server process of the target node, the database server process returns the corresponding log. The location of copied transaction logs can be configured in the ha_copy_log_base of cubrid_ha.conf. Use applyinfo utility to verify the information of copied replication logs. The replication log copy process has following two modes: SYNC and ASYNC. You can configure it with the ha_copy_sync_mode of cubrid_ha.conf. For details on these modes, see Log Multiplexing.
_images/image15.png
Replication log reflection process (applylogdb) : Reflects the log that has been copied by the replication log copy process to a node. The information of reflected replications is stored in the internal catalog (db_ha_apply_info). You can use the applyinfo utility to verify this information.
_images/image16.png
Servers
Here, the word "server" is a logical representation of database server processes. Depending on its status, a server can be either an active server or a standby server.
Active server : A server that belongs to a master node; the status is active. An active server provides all services, including read, write, etc. to the user.
Standby server : A standby server that belongs to a non-master node; the status is standby. A standby server provides only the read service to the user.
The server status changes based on the status of the node. You can use the cubrid changemode utility to verify server status. The maintenance mode exists for operational convenience and you can change it by using the cubrid changemode utility.
_images/image17.png
active : The status of servers that run on a master node is usually active. In this status, all services including read, write, etc. are provided.
standby : The status of servers that run on a slave node or a replica node is standby. In this status, only the read service is provided.
maintenance : The status of servers can be manually changed for operational convenience is maintenance. In this status, only a csql can access and no service is provided to the user.
to-be-active : The status in which a standby server will become active for reasons such as failover, etc. is to-be-active. In this status, servers prepare to become active by reflecting transaction logs from the existing master node to its own server. The node in this status can accept only SELECT query.
Other : This status is internally used.
When the node status is changed, on cub_master process log and cub_server process log, following error messages are saved. But, they are saved only when the value of error_log_level in cubrid.conf is error or less.
The following log information of cub_master process is saved on $CUBRID/log/<hostname>_master.err file.
HA generic: Send changemode request to the server. (state:1[active], args:[cub_server demodb ], pid:25728).
HA generic: Receive changemode response from the server. (state:1[active], args:[cub_server demodb ], pid:25728).
The following log information of cub_server is saved on $CUBRID/log/server/<db_name>_<date>_<time>.err file.
Server HA mode is changed from 'to-be-active' to 'active'.
참고하세요..
안전링크
https://www.cubrid.org/manual/en/10.0/ha.html
아주 멋진 기술이네요..
CUBRID HA
HA (고 가용성)는 하드웨어, 소프트웨어 또는 네트워크 장애시 중단없는 서비스를 제공하는 기능을 말합니다. 이 기능은 서비스를 24 시간 제공해야하는 네트워크 컴퓨팅 영역에서 중요한 요소입니다. HA 시스템은 둘 이상의 서버 시스템으로 구성되며 각 시스템은 장애가 발생하더라도 중단없는 서비스를 제공합니다.
CUBRID HA는 고 가용성 구현입니다. CUBRID HA는 서비스 제공시 여러 서버 간의 데이터베이스 동기화를 보장합니다. 서비스를 운영하는 시스템에서 예기치 않은 장애가 발생하면이 기능은 다른 시스템이 서비스를 자동으로 수행 할 수 있도록하여 서비스 중단 시간을 최소화합니다.
CUBRID HA는 비공유 구조입니다. CUBRID HA는 활성 서버에서 대기 서버로 데이터를 동기화하기 위해 다음 두 단계를 수행한다.
트랜잭션 로그 멀티플렉싱 : 활성 서버에서 만든 트랜잭션 로그를 다른 노드로 실시간 복제합니다.
트랜잭션 로그 반영 : 복제 된 트랜잭션 로그를 실시간으로 분석하고 데이터를 대기 서버에 반영합니다.
CUBRID HA는 활성 서버와 대기 서버 간의 데이터 동기화를 항상 유지하기 위해 위에서 설명한 단계를 수행한다. 이러한 이유로, 서비스를 제공 한 마스터 노드에서 장애가 발생하여 활성 서버가 제대로 작동하지 않으면 슬레이브 노드의 대기 서버는 장애가 발생한 서버 대신 서비스를 제공합니다. CUBRID HA는 시스템 및 CUBRID의 상태를 실시간으로 모니터링합니다. 장애 발생시 하트 비트 메시지를 사용하여 자동 장애 조치를 실행합니다.
_images / image13.png
CUBRID HA 개념
노드와 그룹
노드는 CUBRID HA를 구성하는 논리적 단위입니다. 상태에 따라 마스터 노드, 슬레이브 노드 또는 복제본 노드 중 하나가 될 수 있습니다.
마스터 노드 : 복제 할 노드. 활성 서버를 사용하여 읽고 쓰는 등의 모든 서비스를 제공합니다.
슬레이브 노드 : 마스터 노드와 동일한 정보를 갖는 노드. 마스터 노드에서 변경 한 내용은 슬레이브 노드에 자동으로 반영됩니다. 대기 서버를 사용하여 읽기 서비스를 제공하며 마스터 노드가 실패하면 장애 조치가 발생합니다.
Replica node : 마스터 노드와 동일한 정보를 갖는 노드. 마스터 노드에서 변경 한 내용은 자동으로 복제본 노드에 반영됩니다. 대기 서버를 사용하여 읽기 서비스를 제공하며 마스터 노드가 실패해도 장애 조치가 발생하지 않습니다.
CUBRID HA 그룹은 위에서 설명한 노드들로 구성된다. cubrid_ha.conf 파일에서 ha_node_list 및 ha_replica_list를 사용하여이 그룹의 구성원을 구성 할 수 있습니다. 그룹의 노드는 동일한 정보를 갖습니다. 상태 점검 메시지를 주기적으로 교환하며 마스터 노드가 실패하면 장애 조치가 발생합니다.
노드에는 마스터 프로세스 (cub_master), 데이터베이스 서버 프로세스 (cub_server), 복제 로그 복사 프로세스 (copylogdb), 복제 로그 반영 프로세스 (applylogdb) 등이 포함됩니다.
_images / image14.png
프로세스
CUBRID HA 노드는 하나의 마스터 프로세스 (cub_master), 하나 이상의 데이터베이스 서버 프로세스 (cub_server), 하나 이상의 복제 로그 복사 프로세스 (copylogdb) 및 하나 이상의 복제 로그 반영 프로세스 (applylogdb)로 구성됩니다. 데이터베이스가 구성되면 데이터베이스 서버 프로세스, 복제 로그 복사 프로세스 및 복제 로그 반영 프로세스가 시작됩니다. 복제 로그의 복사 및 반영은 다른 프로세스에 의해 실행되므로 반영 복제 지연은 실행중인 트랜잭션에 영향을 미치지 않습니다.
마스터 프로세스 (cub_master) : 하트 비트 메시지를 교환하여 CUBRID HA의 내부 관리 프로세스를 제어한다.
데이터베이스 서버 프로세스 (cub_server) : 사용자에게 읽기 또는 쓰기와 같은 서비스를 제공합니다. 자세한 내용은 서버를 참조하십시오.
복제 로그 복사 프로세스 (copylogdb) : 그룹의 모든 트랜잭션 로그를 복사합니다. 복제 로그 복사 프로세스가 대상 노드의 데이터베이스 서버 프로세스에서 트랜잭션 로그를 요청하면 데이터베이스 서버 프로세스는 해당 로그를 리턴합니다. 복사 된 트랜잭션 로그의 위치는 cubrid_ha.conf의 ha_copy_log_base에서 구성 할 수 있습니다. applyinfo 유틸리티를 사용하여 복사 된 복제 로그 정보를 확인하십시오. 복제 로그 복사 프로세스에는 SYNC 및 ASYNC의 두 가지 모드가 있습니다. cubrid_ha.conf의 ha_copy_sync_mode를 사용하여 구성 할 수 있습니다. 이러한 모드에 대한 자세한 내용은 로그 멀티플렉싱을 참조하십시오.
_images / image15.png
복제 로그 반영 프로세스 (applylogdb) : 복제 로그 복사 프로세스에서 복사 한 로그를 노드에 반영합니다. 반영된 복제 정보는 내부 카탈로그 (db_ha_apply_info)에 저장됩니다. applyinfo 유틸리티를 사용하여이 정보를 확인할 수 있습니다.
_images / image16.png
서버
여기서 "서버"라는 단어는 데이터베이스 서버 프로세스의 논리적 표현입니다. 상태에 따라 서버는 활성 서버 또는 대기 서버 일 수 있습니다.
CUBRID HA is in a shared-nothing structure. To synchronize data from an active server to a standby server, CUBRID HA executes the following two steps.
Transaction log multiplexing: Replicates the transaction logs created by an active server to another node in real time.
Transaction log reflection: Analyzes replicated transaction logs in real time and reflects the data to a standby server.
CUBRID HA executes the steps described above in order to always maintain data synchronization between an active server and a standby server. For this reason, if an active server is not working properly because of a failure occurring in the master node that had been providing service, the standby server of the slave node provides service instead of the failed server. CUBRID HA monitors the status of the system and CUBRID in real time. It uses heartbeat messages to execute an automatic failover when a failure occurs.
_images/image13.png
CUBRID HA Concept
Nodes and Groups
A node is a logical unit that makes up CUBRID HA. It can become one of the following nodes according to its status: master node, slave node, or replica node.
Master node : A node to be replicated. It provides all services which are read, write, etc. using an active server.
Slave node : A node that has the same information as a master node. Changes made in the master node are automatically reflected to the slave node. It provides the read service using a standby server, and a failover will occur when the master node fails.
Replica node : A node that has the same information as a master node. Changes made in the master node are automatically reflected to the replica node. It provides the read service using a standby server, and no failover will occur when the master node fails.
The CUBRID HA group consists of the nodes described above. You can configure the members of this group by using the ha_node_list and ha_replica_list in the cubrid_ha.conf file. Nodes in a group have the same information. They exchange status checking messages periodically and a failover will occurs when the master node fails.
A node includes the master process (cub_master), the database server process (cub_server), the replication log copy process (copylogdb), the replication log reflection process (applylogdb), etc.
_images/image14.png
Processes
A CUBRID HA node consists of one master process (cub_master), one or more database server processes (cub_server), one or more replication log copy processes (copylogdb), and one or more replication log reflection processes (applylogdb). When a database is configured, database server processes, replication log copy processes, and replication log reflection processes will start. Because copy and reflection of a replication log are executed by different processes, the delay in replicating reflections does not affect the transaction that is being executed.
Master process (cub_master) : Exchanges heartbeat messages to control the internal management processes of CUBRID HA.
Database server process (cub_server) : Provides services such as read or write to the user. For details, see Servers.
Replication log copy process (copylogdb) : Copies all transaction logs in a group. When the replication log copy process requests a transaction log from the database server process of the target node, the database server process returns the corresponding log. The location of copied transaction logs can be configured in the ha_copy_log_base of cubrid_ha.conf. Use applyinfo utility to verify the information of copied replication logs. The replication log copy process has following two modes: SYNC and ASYNC. You can configure it with the ha_copy_sync_mode of cubrid_ha.conf. For details on these modes, see Log Multiplexing.
_images/image15.png
Replication log reflection process (applylogdb) : Reflects the log that has been copied by the replication log copy process to a node. The information of reflected replications is stored in the internal catalog (db_ha_apply_info). You can use the applyinfo utility to verify this information.
_images/image16.png
Servers
Here, the word "server" is a logical representation of database server processes. Depending on its status, a server can be either an active server or a standby server.
Active server : A server that belongs to a master node; the status is active. An active server provides all services, including read, write, etc. to the user.
Standby server : A standby server that belongs to a non-master node; the status is standby. A standby server provides only the read service to the user.
The server status changes based on the status of the node. You can use the cubrid changemode utility to verify server status. The maintenance mode exists for operational convenience and you can change it by using the cubrid changemode utility.
_images/image17.png
active : The status of servers that run on a master node is usually active. In this status, all services including read, write, etc. are provided.
standby : The status of servers that run on a slave node or a replica node is standby. In this status, only the read service is provided.
maintenance : The status of servers can be manually changed for operational convenience is maintenance. In this status, only a csql can access and no service is provided to the user.
to-be-active : The status in which a standby server will become active for reasons such as failover, etc. is to-be-active. In this status, servers prepare to become active by reflecting transaction logs from the existing master node to its own server. The node in this status can accept only SELECT query.
Other : This status is internally used.
When the node status is changed, on cub_master process log and cub_server process log, following error messages are saved. But, they are saved only when the value of error_log_level in cubrid.conf is error or less.
The following log information of cub_master process is saved on $CUBRID/log/<hostname>_master.err file.
HA generic: Send changemode request to the server. (state:1[active], args:[cub_server demodb ], pid:25728).
HA generic: Receive changemode response from the server. (state:1[active], args:[cub_server demodb ], pid:25728).
The following log information of cub_server is saved on $CUBRID/log/server/<db_name>_<date>_<time>.err file.
Server HA mode is changed from 'to-be-active' to 'active'.
이게 필요했습니다.