MariaDB 앞에 MaxScale 을 두고 auto_failover 를 붙이는 작업이었다. 얼마나 빨리 넘어가느냐는 질문에 답해야 했다.
Table of contents
Open Table of contents
배경 — 곱하고 더해지는 네 설정
관련 설정을 전부 찾으니 monitor_interval 과 backend_connect_timeout 과 failcount 와 전환 자체에 드는 시간 넷이었다. MaxScale 공식 문서는 failcount 를 마스터가 죽었다고 보기까지 연속으로 실패해야 하는 모니터 회차 수로 적는다. monitor_interval 기본값은 2초다. 이 값들이 서로 곱해지고 더해지면서 최종 지연을 만든다.
동작 흐름을 따라가면 감시가 돌 때마다 연결을 시도하고 타임아웃까지 기다렸다가 실패로 센다. 그것을 정해진 횟수만큼 반복한 뒤 마지막 대기 시간을 더 기다리고 전환한다. 그래서 감시 주기와 연결 타임아웃의 합에 실패 횟수를 곱하고 마지막 대기 시간을 더하면 최악 지연이 된다.
검증 — 값을 넣어 얻은 답
정한 설정값을 공식에 넣으니 최악 25초가 나왔다. 얼마나 빨리 넘어가느냐는 질문에 숫자로 답할 수 있게 됐다.
값을 바꾸면 얼마가 되는지도 바로 계산된다. 두 가지 방법이 있었는데 failcount 를 줄이는 것과 monitor_interval 을 줄이는 것이다. 앞쪽을 골랐다. 이유는 감시 주기를 줄이면 정상일 때도 매초 서버를 두드려서다. 대신 순간적인 네트워크 끊김에 전환이 한 번 더 일어날 수 있는 것을 감수했다. 각각 몇 초씩 짧아지는데 빨리 넘어갈수록 오탐이 늘어나므로 공식이 그 교환까지 보여 준다.
원인 — 대칭이어야 하는 설정
전환 자체 말고 하나가 더 걸렸다. 전환 후에 새 마스터가 복제 소스 역할을 하려면 log_bin 과 log_slave_updates 와 GTID 설정 셋이 양쪽 서버에 다 있어야 한다.
한쪽에만 있으면 전환은 되는데 그다음 복제가 안 붙는다. 전환 직후에 단일 서버가 된다. 원래 마스터를 복구해도 다시 못 붙으므로 대칭이 아니면 전환이 반쪽이 된다.
조치 — 계정 자체를 지우기
보안 항목도 하나 있었는데 REST API 의 기본 관리 계정이 문서에 적힌 admin:mariadb 로 들어 있다는 것이었다. 첫 배포 직후에 처리해야 하는 항목이다.
maxctrl create user 로 새 관리 계정을 만들고 maxctrl destroy user admin 으로 기본 계정을 삭제하는 두 단계로 했다. 비밀번호만 바꾸는 것이 아니라 계정 자체를 지우는데 계정 이름이 알려져 있는 것도 공격 표면이기 때문이다.
주의 — 근거의 출처를 밝히기
설정을 컨테이너 환경변수로 주려 했는데 지원하지 않았고 대신 maxscale.cnf 에 substitute_variables=true 로 변수 치환 기능이 있었다. 그 옵션을 켜야 $SOME_VALUE 치환이 동작하고 안 켜면 변수 표기가 문자열 그대로 들어간다.
이 정리를 하면서 판별 공식 자체는 공식 문서에 없어 동작 흐름과 실측을 근거로 세웠고 그 사실을 문서에 적었다. 이 작업에서 가장 유용했던 것이 공식인데 실측은 마스터를 실제로 죽여야 해서 운영에서는 못 하므로 계산으로 예측하고 한 번만 실측으로 검증하면 된다.
정리
- 장애 전환 지연은 설정값들의 공식으로 계산된다
- 감시 주기와 연결 타임아웃의 합에 실패 횟수를 곱하고 대기를 더한다
- 공식이 있으면 설정을 바꿀 때 다시 계산된다
- 매번 실측하지 않아도 된다
- 전환 후 복제가 붙으려면 양쪽 설정이 대칭이어야 한다
- 기본 관리 계정은 비밀번호만 바꾸지 말고 삭제한다
- 환경변수 미지원이면 설정 파일의 치환 옵션을 켠다
- 근거의 출처를 밝힌다