[MariaDB] Galera Cluster 모니터링 - 2

이번 포스팅에서는 복제 상태 및 서버 로그를 활용한 Galera Cluster 모니터링에 대해 알아보겠습니다.

 

복제 상태

클러스터 무결성 및 노드 상태를 모니터링하면 복제를 방해하거나 차단할 수 있는 문제가 생길 수 있습니다.

노드가 너무 바빠지지 않도록 Galera는 Flow Control 이라는 피드백 메커니즘을 트리거 하여 복제 프로세스를 관리합니다. 대기열에 쓰기 세트가 너무 많으면 노드는 Flow Control을 사용하여 복제를 일시 중지한 다음 따라잡을 수 있을 때까지 기다립니다.

 

이를 위해 확인할 상태 변수는 아래 세가지 입니다.

 

wsrep_local_recv_queue_avg

wsrep_flow_control_paused

wsrep_cert_deps_distance

 

이 변수들은 서버가 재시작되거나 FLUSH STATUS 명령문이 실행될 때 재설정됩니다.

 

쓰기의 묶음

wsrep_local_recv_queue_avg변수는 마지막 상태 쿼리 이후 로컬 수신 대기열의 평균 크기를 보여줍니다.

이 값이 0보다 큰 경우 노드가 수신하는 것만큼 빠르게 쓰기 세트를 적용할 수 없음을 나타냅니다.

여기서 문제가 감지되면 평균이 아닌 값 범위를 얻기 위해 wsrep_local_recv_queue_min, wsrep_local_recv_queue_max  를 확인할 수도 있습니다.

들어오는 쓰기 세트와 관련된 노드의 상태를 확인하는 것 외에도 나가는 연결이 어떻게 보이는지 확인할 수 있습니다.

주로 wsrep_local_send_queue_avg를 확인하여 마지막으로 플러시된 이후의 전송 대기열 길이의 평균을 얻습니다. 하지만 전송은 거의 병목 현상이 일어나지 않습니다.

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_local_send_queue_avg';
+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| wsrep_local_send_queue_avg | 0.0647458 |
+----------------------------+-----------+
1 row in set (0.000 sec)

 

 

Flow Control 일시 중지

노드가 과부하 상태라고 느낀다면, 노드를 실행한 다음 기다리다가 wsrep_flow_control_paused 변수 값을 확인할 수 있습니다. 상태를 플러시한 이후로 Flow Control로 인해 노드가 일시 중지된 시간의 백분율이 반환됩니다.

 

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_flow_control_paused';
+---------------------------+------------+
| Variable_name             | Value      |
+---------------------------+------------+
| wsrep_flow_control_paused | 0.00118931 |
+---------------------------+------------+
1 row in set (0.000 sec)

=>  현재 경과 시간의 0.1%이상의 시간동안 Flow Control이 일시 중지되었다고 보면 됩니다.

 

이 값이 1이면 노드가 100%의 시간 동안 일시 중지되었음을 나타냅니다.

또한 0 이상의 값은 노드의 복제 상태가 약할 수 있음을 나타냅니다.

0 값이 표시되기 시작할 때까지 가끔씩 플러싱하여 주의 깊게 모니터링해야 합니다.

스스로 해결되지 않으면 슬레이브 스레드 수(예: wsrep_slave_threads)를 늘릴 수 있습니다.

 

 

순차적 병렬 전환

마지막으로,  wsrep_cert_deps_distance, wsrep_slave_threads, wsrep_applier_threads 를 모니터링할 수 있습니다.

wsrep_cert_deps_distance 는 가장 낮은 시퀀스 번호와 가장 높은 시퀀스 번호 사이의 평균 거리를 알려줍니다.

노드가 잠재적으로 병렬로 적용할 수 있는 값입니다.

 

 

문제 해결을 위한 서버 로그 활용

상태 변수는 문제를 감지하는 데 필요한 많은 정보를 제공합니다. 그러나 일반적으로 패턴을 나타내지는 않습니다.

대부분 우연히 볼 때의 현재 상태입니다. 그러나 과거 정보는 문제가 발생하는 것을 더 쉽게 볼 수 있도록 해줍니다. 또한 상태 변수는 문제의 원인을 파악하거나 문제를 해결하는 방법에 대한 권장 사항을 제공하는 데 거의 도움이 되지 않습니다.

패턴을 보려면 정기적으로 상태 변수를 쿼리하여 결과를 기록하고 나중에 검토할 수 있도록 데이터베이스나 로그에 기록해야 합니다. 간격의 일관성을 위해 자동화해야 합니다. 이를 위해 직접 스크립트를 작성하거나 여러 데이터베이스 모니터링 프로그램(예: Monyog) 중 하나를 사용할 수 있습니다.

 

 

오류 로그 및 특수 로깅 활성화

문제의 원인을 파악하기 위해 서버 로그를 확인하는 것이 가장 유용합니다.

변수 값을 확인 하고 로그 파일의 경로와 이름을 확인하는 데 사용합니다.

오류 로그에 기록된 정보 외에도 복제에 특정한 이벤트에 대한 오류 로깅을 활성화하는 데 사용할 수 있는 매개변수와 옵션이 있습니다. wsrep_log_conflicts, cert.log_conflicts, wsrep_debug를 설정하면 MySQL이 복제 프로세스의 충돌에 대한 정보를 기록하게 됩니다.

 

wsrep_log_conflicts는 오류 로그에 대한 충돌 로깅을 활성화합니다.

예를 들어, 두 노드가 동시에 같은 테이블의 같은 행에 쓰려고 할 때 기록합니다.

충돌이 커밋되기 전에 해결된 경우에도 이를 수행합니다. 이 정보를 로깅하지 않으면 일시적으로 충돌이 발생했다는 것을 알지 못할 것입니다.

 

cert.log_conflicts는 복제 중에 인증 실패를 로깅할 수 있는 wsrep 공급자 옵션입니다.

 

wsrep_debug 매개변수는 디버깅 정보를 활성화하여 로그 파일에 훨씬 더 자세한 항목을 제공합니다.

그러나 이 매개변수는 데이터베이스 서버가 오류 로그에 비밀번호 및 유사한 인증 데이터를 기록하게 할 수도 있습니다.

보안 취약성이 있으므로 운영 환경에서는 활성화하지 않는 것을 권장드립니다.

 

위 항목들은 MySQL 구성 파일에 아래와 같이 표시됩니다.

wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON

 

 

노드가 트랜잭션이나 다른 이벤트를 완료할 수 없는 경우, 데이터베이스 서버는 해당 실패에 대한 세부 정보가 포함된 특수 바이너리 로그 파일인 GRA_*.log을 생성합니다. 이 파일은 데이터 디렉터리에 저장됩니다.

로그 파일이 생성되는지 주기적으로 확인해야 합니다. 확인된다면 바로 검토하는 것을 추천드립니다.

 

 

[참고 링크]

https://galeracluster.com/library/training/tutorials/galera-monitoring.html