승인 모듈이 Slave DB를 직접 바라본 결과 - 시퀀스 매칭 오류
시스템 구성
VIP 192.168.0.10
- 가상 IP, Active/Standby 전환 시 자동으로 Active DB를 가리킴
Master DB (Active) 192.168.0.11
- 읽기/쓰기 담당
Slave DB (Standby) 192.168.0.12
- Master 장애 시 Active 역할을 대체
Active/Standby 이중화 구조로, Master(11번)가 죽으면 Slave(12번)가 Active로 승격된다. VIP(10번)는 항상 현재 Active DB를 가리키기 때문에, 애플리케이션은 VIP만 바라보면 된다.
문제 발생
인지 시점
- 서비스 오픈 초기, 승인 모듈 운영 중 데이터 정합성 이슈 발견
증상
승인 모듈에서 데이터를 쓰고 읽는 과정에서 싱크가 안 맞았다.
1
2
3
승인 처리 → DB에 INSERT
→ 직후 SELECT 시 데이터가 없거나 이전 데이터가 조회됨
→ 시퀀스 매칭 오류 발생
원인 분석
승인 모듈의 DB 연결 확인
승인 모듈이 바라보고 있던 DB를 확인해보니 Slave DB(192.168.0.12)를 직접 바라보고 있었다.
1
승인 모듈 → 192.168.0.12 (Slave DB)
이중화 구조를 모르는 상태에서 DB 연결 설정을 했기 때문에, VIP가 아닌 Slave IP를 직접 지정한 것이 원인이었다.
왜 문제가 되는가
Slave는 Standby 역할이다. Master에서 발생한 트랜잭션이 복제되어 오는 구조인데, 여기에 직접 쓰기를 하면:
1
2
3
4
1. Master에서 발생한 GTID와 Slave에서 직접 발생한 GTID가 충돌
2. 시퀀스 번호 불일치 → 복제 중단
3. 데이터 싱크가 안 맞는 상태에서 읽기/쓰기 반복
→ 시퀀스 매칭 오류
Slave에 직접 쓰기가 발생하면 GTID가 꼬이고, 이게 시퀀스 매칭 오류로 이어진 것이다.
해결
1. DB 연결 대상을 VIP로 변경
1
2
변경 전: 승인 모듈 → 192.168.0.12 (Slave 직접 연결)
변경 후: 승인 모듈 → 192.168.0.10 (VIP)
VIP를 바라보면 현재 Active인 Master(11번)로 연결된다. Master가 죽어도 Slave가 Active로 승격되면서 VIP가 자동으로 전환되기 때문에, 애플리케이션 설정 변경 없이 HA가 동작한다.
2. 시퀀스 보정
꼬여버린 GTID와 시퀀스는 DBA가 직접 보정 작업을 진행했다. 이 시점에서는 GTID 충돌의 정확한 메커니즘을 이해하지 못한 상태였기 때문에, DBA에게 맡기는 것이 맞는 판단이었다.
마무리
이후 MaxScale GTID 복제 중단 트러블슈팅 이슈를 겪으면서 GTID 충돌의 원인과 해결 방법을 직접 파악할 수 있게 됐다.
돌이켜보면 이 문제의 본질은 단순했다. 이중화 구조를 모르는 상태에서 DB 연결을 설정했고, Slave에 직접 쓰기가 들어가면서 GTID가 꼬였고, VIP가 왜 있는지 이해를 못 하고 있었다.
인프라 구조를 모르면 코드가 맞아도 장애는 난다. DB 연결 하나 설정하는 것도 시스템 전체 구조를 알아야 한다는 걸 이때 배웠다.