- Galera Cluster는 안정적이고 신뢰할 수 있는 데이터베이스 복제 클러스터링 시스템입니다.
- InnoDB 스토리지를 갖춘 MySQL과 MariaDB는 모두 Linux를 실행하는 노드 간 통신에 Galera를 활용합니다.
- 하지만 운영하는 측면에서 지속적으로 클러스터 상태를 확인해야 합니다. 또한, 각 노드의 상태를 확인하고 모니터링하여 문제(예: 복제 지연, 네트워크 연결 등)를 방지해야 합니다.
클러스터 활동 및 복제 상태를 모니터링하는 데 사용할 수 있는 방법은 세 가지가 있습니다.
1. MySQL의 상태 변수를 정기적으로 쿼리
2. 상태 변수의 변경에 반응하는 사용자 지정 스크립트를 사용, 상태 변수에 의존하는 타사 모니터링 애플리케이션을 사용할 수 있습니다.
=> Grafana - prometheus 연동한 mysqld_exporter 활용
3. 상태 변수를 직접 확인할 수도 있고 스크립트나 일종의 모니터링 소프트웨어를 사용하여 상태 변수를 확인하고 문제가 있을 때 경고하여 프로세스를 자동화하고 기록할 수도 있습니다.
고려해야 할 필수 상태 변수와 클러스터 및 노드 상태를 기록하는 방법을 자세히 살펴보겠습니다.
상태 변수 사용
MySQL의 표준 상태 변수 외에도 Galera Cluster는 일련의 상태 변수도 제공합니다.
이를 통해 노드 및 클러스터 상태와 복제 상태를 확인할 수 있습니다.
Galera Cluster 변수는 쓰기 세트(write set), 복제(replicate)와 관련이 있으며, 따라서 ' wsrep_'가 접두사로 붙습니다.
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_%';
+-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
+-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| wsrep_local_state_uuid | 5bbc5074-1bfa-11ed-b61f-a6580d1d82cd |
| wsrep_protocol_version | 10 |
| wsrep_last_committed | 1791617828 |
| wsrep_replicated | 569512202 |
| wsrep_replicated_bytes | 808249142576 |
| wsrep_repl_keys | 2732801816 |
| wsrep_repl_keys_bytes | 35530729488 |
| wsrep_repl_data_bytes | 727905813161 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 1117817180 |
| wsrep_received_bytes | 1514867581244 |
| wsrep_local_commits | 569510747 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1048 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.0647549 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 813 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.00411871 |
| wsrep_local_cached_downto | 1790108364 |
| wsrep_flow_control_paused_ns | 70339619451100 |
| wsrep_flow_control_paused | 0.00118933 |
| wsrep_flow_control_sent | 2057 |
| wsrep_flow_control_recv | 12450 |
| wsrep_flow_control_active | false |
| wsrep_flow_control_requested | false |
| wsrep_cert_deps_distance | 64.7887 |
| wsrep_apply_oooe | 0.0392834 |
| wsrep_apply_oool | 0.00284638 |
| wsrep_apply_window | 1.10931 |
| wsrep_apply_waits | 258860 |
| wsrep_commit_oooe | 0 |
| wsrep_commit_oool | 0 |
| wsrep_commit_window | 1.09466 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 330 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 9.80329 |
| wsrep_open_transactions | 0 |
| wsrep_open_connections | 0 |
| wsrep_incoming_addresses | AUTO,AUTO,AUTO |
| wsrep_cluster_weight | 3 |
| wsrep_desync_count | 0 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 9.3223e-05/0.000138572/0.000228205/2.29136e-05/306 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | 3c4c5a75-5f80-11ed-88b2-8bb0c8ab631a |
| wsrep_gmcast_segment | 0 |
| wsrep_applier_thread_count | 60 |
| wsrep_cluster_capabilities | |
| wsrep_cluster_conf_id | 21 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | 5bbc5074-1bfa-11ed-b61f-a6580d1d82cd |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 40 |
| wsrep_local_index | 0 |
| wsrep_provider_capabilities | :MULTI_MASTER:CERTIFICATION:PARALLEL_APPLYING:TRX_REPLAY:ISOLATION:PAUSE:CAUSAL_READS:INCREMENTAL_WRITESET:UNORDERED:PREORDERED:STREAMING:NBO: |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 26.4.9(r819f29c) |
| wsrep_ready | ON |
| wsrep_rollbacker_thread_count | 1 |
| wsrep_thread_count | 61 |
+-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
69 rows in set (0.000 sec)
60개의 변수 중에서 정기적으로 확인해야 할 변수도 있습니다.
이를 클러스터 무결성, 노드 상태, 복제 상태의 세 가지로 그룹화할 수 있습니다.
클러스터의 무결성
클러스터는 각 노드(클러스터의 모든 노드)가 다른 모든 노드에서 쓰기 세트를 수신하고 복제할 때 무결성이 있다고 합니다. 수신 및 복제 시에 문제가 생기면 클러스터가 무결성을 잃기 시작합니다. 이는 클러스터가 다운되거나 분할되거나 스플릿 브레인 상황이 발생할 수 있습니다.
클러스터 무결성 손실이 있는지 여부를 나타내는 상태 변수는 wsrep_cluster_state_uuid, wsrep_cluster_conf_id, wsrep_cluster_size 입니다.
UUID 비교
모든 노드가 서로 동기화되면 모든 동일한 트랜잭션을 실행하게 됩니다.
각 트랜잭션에는 식별을 위한 UUID가 포함됩니다. 따라서 각 노드의 마지막 UUID는 동일해야 합니다.
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_cluster_state_uuid' \G
*************************** 1. row ***************************
Variable_name: wsrep_cluster_state_uuid
Value: 5bbc5074-1bfa-11ed-b61f-a6580d1d82cd
1 row in set (0.000 sec)
마지막 노드가 다른 노드와 다른 uuid를 가지고 있다면, SQL 문을 실행하는 동안 트랜잭션이 들어왔을 수 있습니다.
하나 이상의 노드가 다른 노드와 다른 UUID를 가지고 있다면, 클러스터에 무결성이 없습니다.
즉, 두 개 이상의 클러스터가 형성되었고 노드가 모두 서로 통신하지 않는다는 뜻입니다.
클러스터 상태 변수 값 비교
클러스터에 포함된 노드에서 wsrep_cluster_conf_id라는 변수의 값을 조회하면 클러스터에서 발생한 총 변경 횟수가 표시됩니다. 즉, 실행된 노드에서 인식하는 변경 사항입니다. 기본적으로 이 변수를 비교하면 노드가 기본 구성 요소의 일부인지 여부를 판별할 수 있습니다.
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_cluster_conf_id';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| wsrep_cluster_conf_id | 21 |
+-----------------------+-------+
1 row in set (0.000 sec)
클러스터의 각 노드는 동일한 값을 나타내야 합니다. 그렇지 않으면 클러스터가 제대로 이루어지지 않았음을 나타냅니다. 값이 터무니없이 높은 숫자(예: 1조 이상)인 경우 노드가 계속해서 삭제되고 다시 시작되고 있음을 나타낼 수 있습니다.
클러스터 노드 동기화 확인
네트워크 연결에 문제가 있거나 클러스터가 여러 개의 클러스터로 분할되었을 수 있다고 생각되면 각 클러스터에서 wsrep_cluster_size 를 확인하여 일치하는지 확인합니다.
클러스터에 연결된 노드가 5개라고 가정할 때, 한 노드에서는 클러스터 크기에 3개가 있다고 하고 다른 노드에서는 2개라고 하면 문제가 있는 것입니다.
만약 실행 중인 노드 수와 일치하지 않는다면 네트워크 연결 문제가 있거나 MySQL이 한 노드에서 다운되었을 수 있음을 나타냅니다.
하지만 하나의 노드만 동기화되지 않은 경우, 해당 노드를 다운시키고, 발생한 네트워크 문제를 해결한 다음 다시 시작하면 문제를 해결할 수 있습니다.
클러스터에 제대로 가입하면 데이터베이스의 전체 교체인 State Snapshot Transfer(SST)를 거치게 됩니다.
MariaDB [(none)]> show global status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.000 sec)
각 노드의 상태
클러스터 무결성을 확인하는 것 외에도 개별 노드의 상태도 모니터링해야 합니다. 즉, 반드시 클러스터 전체와 관련해서 모니터링할 필요는 없습니다.
기본적으로 노드가 클러스터 쓰기 세트(write set)에서 업데이트를 수신하고 처리했는지 확인합니다.
이와 관련된 변수로는 wsrep_ready, wsrep_connected, wsrep_local_state_comment가 있습니다.
처음 두 상태 변수는 매우 간단합니다. ON 또는 OFF이며, wsrep_ready가 OFF를 반환하는 경우 준비가 되지 않았으며 거의 모든 쿼리가 실패합니다. 다음과 같은 오류 메시지가 표시됩니다.
ERROR 1047 (08501) Unknown Command
wsrep_connected가 OFF 값을 반환하는 경우 노드는 다른 노드나 클러스터 구성 요소에 연결되어 있지 않다고 볼 수 있습니다. 연결이 끊어진 이유는 아래와 같은 이유일 수 있습니다.
1. 노드의 구성 파일이 잘못되었거나 다른 노드와 동기화되지 않은 상태일 수 있습니다.
2. wsrep_cluster_name , wsrep_cluster_address 변수 값이 MySQL 구성 파일에 잘못 입력되었을 수 있습니다.
3. 네트워크 다운, 케이블 분리 등 물리적인 이유
오류 로그는 일반적으로 /var/log/mysqld.log입니다 .
노드 상태를 쉽게 확인하는 법
노드 상태를 훨씬 더 명확하게 하려면 wsrep_local_state_comment 변수의 값을 확인할 수 있습니다.
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
1 row in set (0.000 sec)=> 값이 Synced라면, 정상적으로 동기화된 것입니다. 이 외의 값이 있다면 기다리거나 조치가 필요할 것입니다.
다음 글은 galera 복제 상태 및 서버 로그를 활용하는 법에 대해 알아보도록 하겠습니다.
[참고 링크]
https://galeracluster.com/library/training/tutorials/galera-monitoring.html
'DB > MariaDB' 카테고리의 다른 글
| [MariaDB] mysql 데이터 타입 (1) | 2024.09.26 |
|---|---|
| [MariaDB] Galera Cluster 모니터링 - 2 (1) | 2024.09.24 |
| [MariaDB] Galera Cluster 구성변경 테스트 (gcomm 설정) (0) | 2024.08.30 |
| [MariaDB] Mysql 디렉토리 접근 사용자/그룹 권한 장애 테스트 (0) | 2024.08.26 |
| [MariaDB] 서버 장애테스트 (0) | 2024.08.26 |