복제 구성을 장비와 같이 적었다

DB 복제가 걸려 있다고만 들었고 어느 장비가 어느 장비를 따라가는지는 아무도 몰랐다.

Open Table of contents

상황 — 상태만으로는 모자랐다
검증 — 전부 돌면서 봤다
결과 — 장비 정보를 붙인 표
판단 기준 — 무엇이 무엇을 읽는지
주의 — 지연과 용도별 기준
조치 — 2단계 복제 정리와 절차
정리

상황 — 상태만으로는 모자랐다

한 장비에서 복제 상태부터 봤다.

SHOW SLAVE STATUS\G

Master_Host: 10.0.0.20
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

Slave_IO_Running 은 정상이지만 Master_Host 하나로는 전체 구조를 모른다.

장비가 다섯인데 어느 것이 원본이고 어느 것이 사본인지 이것만으로는 알 수 없었다. 사본이 또 사본을 갖는지도 그 장비에 붙어서 다시 봐야 나온다.

검증 — 전부 돌면서 봤다

다섯 장비를 한 번에 돌면서 봤다.

$ for h in 10.0.0.20 10.0.0.21 10.0.0.22 10.0.0.23 10.0.0.24; do
    echo "=== $h"
    mysql -h "$h" -e "SHOW SLAVE STATUS\G" | grep -E "Master_Host|Seconds_Behind"
    mysql -h "$h" -e "SHOW MASTER STATUS\G" | grep -E "File|Position"
  done

Master_Host 로 본 관계가 이렇게 나왔다.

=== 10.0.0.20   (Slave 없음, Master 있음)  → 원본
=== 10.0.0.21   Master_Host: 10.0.0.20     → 20 의 사본
=== 10.0.0.22   Master_Host: 10.0.0.20     → 20 의 사본
=== 10.0.0.23   Master_Host: 10.0.0.21     → 21 의 사본 (2단계)
=== 10.0.0.24   Master_Host: 10.0.0.20     → 20 의 사본

10.0.0.23 이 2단계라 10.0.0.21 이 죽으면 함께 멈춘다.

한 단계 구조라고 알고 있었으면 장애가 미치는 곳을 잘못 판단했을 것이다.

결과 — 장비 정보를 붙인 표

관계도만 적어 두는 것으로는 부족했다.

역할     주소         장비      사양              위치      용도
원본     10.0.0.20   물리 서버  16코어 64G SSD    랙 A     쓰기
사본1    10.0.0.21   물리 서버  16코어 64G SSD    랙 B     읽기(주)
사본2    10.0.0.22   가상 머신  4코어 16G         랙 A     통계 조회
사본3    10.0.0.23   가상 머신  4코어 16G         랙 B     백업 추출
사본4    10.0.0.24   물리 서버  8코어 32G         다른 IDC 재해 대비

가상 머신 인 사본은 복제가 더 잘 밀린다.

위치가 다르면 한쪽 랙이 죽었을 때 남는 것이 갈리는데 구조만 있으면 다섯 장비가 다 같아 보인다.

판단 기준 — 무엇이 무엇을 읽는지

무엇이 어느 장비를 읽는지도 함께 적었다.

애플리케이션 쓰기   → 원본(20)
애플리케이션 읽기   → 사본1(21)
통계 배치           → 사본2(22)
백업                → 사본3(23)
재해 대비           → 사본4(24), 평소 아무도 안 읽음

사본1 이 죽으면 서비스 읽기가 멈추고 사본2 가 죽으면 통계만 안 나온다.

어느 장비가 죽었을 때 무엇이 안 되는지가 이 표 하나로 갈렸다. 이것이 없으면 장애 때 무엇부터 봐야 할지를 그 자리에서 다시 조사하게 된다.

주의 — 지연과 용도별 기준

복제 지연은 계속 재서 봤다.

$ for h in $REPLICAS; do
    echo -n "$h "
    mysql -h "$h" -sN -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind | awk '{print $2}'
  done

10.0.0.21  0
10.0.0.22  412   ←
10.0.0.23  0
10.0.0.24  8

10.0.0.22 가 7분 밀려 있었는데 통계 배치가 무거운 조회를 돌려서였다.

밀리는 것 자체는 그 용도에서 괜찮았고 얼마나 밀리는지 알고 있는 것이 중요했다.

사본1  10초 넘으면 알림  (서비스 읽기)
사본2  30분 넘으면 알림  (통계)
사본4  5분 넘으면 알림   (재해 대비)

하나의 기준으로 보면 한쪽은 과하고 한쪽은 모자라서 용도마다 다른 기준을 뒀다.

조치 — 2단계 복제 정리와 절차

10.0.0.23 이 10.0.0.21 을 따라가는 구조를 바꿨다.

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='10.0.0.20', ...;
START SLAVE;

CHANGE MASTER TO 로 원본을 직접 보게 하니 부담은 늘어도 구조가 단순해졌다.

바꾸기 전에 원본이 사본 넷을 감당하는지 확인했다.

SHOW STATUS LIKE 'Binlog_cache%';
SHOW PROCESSLIST;

원본이 죽었을 때 밟을 절차도 적었다.

원본이 죽으면
  1. 사본1(21)의 복제 지연이 0인지 확인
  2. 21 에서 STOP SLAVE; RESET SLAVE ALL;
  3. 애플리케이션 쓰기 대상을 21 로 바꾼다
  4. 나머지 사본을 21 을 보게 바꾼다
  5. 옛 원본은 켜지 말고 조사한다

다섯째를 적은 것은 옛 원본이 살아나 쓰기를 받으면 데이터가 갈리기 때문이다.

시험 환경에서 한 번 해 보니 셋째에서 애플리케이션 설정 자리를 몰라 시간이 걸렸고 그것도 절차에 적었다.

정리

복제는 상태만 봐서는 전체 구조를 모른다
관련 장비를 전부 돌면서 본다
2단계 복제가 있으면 중간이 죽을 때 뒤도 멈춘다
구조에 장비 사양과 위치를 같이 적는다
사양이 낮은 사본은 더 밀리고 위치에 따라 남는 것이 갈린다
무엇이 무엇을 읽는지 적는다
어느 것이 죽으면 무엇이 안 되는지가 그 표로 갈린다
지연을 계속 보되 용도마다 다른 기준을 둔다
원본이 죽었을 때 절차를 적고 실제로 해 본다
해 보면 빠진 것이 나온다