Closed binchoo closed 9 months ago
해당 TF에서 필요한 작업 내역입니다.
스프링 어플리케이션
😞 아니 그냥 단순히 MySQL Client로 검증해 보는 걸로 해 보겠습니다.
RDS MySQL Multi-AZ 구성
퍼블릭 서브넷에 놓아 저희 로컬에서 접근합니다.
Master 리부트 하여 Failover 프로세스를 시동합니다.
페일오버 DB 전환은 통상 60-120초 뒤 완료된다고 알려져 있습니다.
전환 완료된 후 기존 연결로 요청을 시도, 오류를 확인합시다.
댕글댕글 커넥션에 대한 우려를 AWS 공식문서 역시 얘기해 주고 있군요 👍🏻
DB와 클라 간 세션이 원활히 종결되지 않았을 수 있기에, 수동 페일오버(리부팅) 전에 트랜잭션을 멈추기 바란다.
클라우드 비용 신경쓰지 마시고 구체적인 구현 방안 의견이나 공수 나누실 분 있다면(?) 적극 협력해주시면 더욱 좋습니다.
dangle.USER
테이블에 열 하나 (Jaebin Joo)만 준비
USE dangle;
SET AUTOCOMMIT=0;
INSERT INTO USER(name) VALUES ('Jaebin Joo 2');
-- DR 전환 완료후
COMMIT;
SELECT * FROM USER;
이상으로 짧은 PoC 결과 보고드렸습니다.
DR 전환 후 보낸 쿼리는 수십초가 지나 결국엔 들어갔습니다..? ✔️ 워크벤치에 연결 재시도 로직이 있다고 유추하게 되었습니다. 이 로직을 증명할 수 있을까요? ✔️ 여러분들은 첫 시도에서 Abort 하는 걸 바라시나요? 아니면 재시도 하기를 바라시나요?
MySQL은 쿼리 중 서버가 날라간 현상을 별도 문서로 남겨두어 이런 가이드를 남겼습니다.
You can also get these errors if you send a query to the server that is incorrect or too large. If mysqld receives a packet that is too large or out of order, it assumes that something has gone wrong with the client and closes the connection. 서버에게 부정확하거나, 너무 큰 쿼리를 보내면 해당 오류를 만날 수 있다. mysql가 크거나 처리할 수 없는 쿼리를 받으면, 클라이언트에 이상이 생긴 걸로 알고 연결을 닫는다.
그러니까 DR DB는 기존 연결이 보낸 COMMIT 명령을 이상하게 여겨 쳐냈을 겁니다.
그러므로 워크벤치가 연결 재수립 로직을 구현하고 있는지 알아보기 위해서
✔️ read_conn_timeout에 의한 연결 재시도 확인 ✔️ conn timeout에 의한 연결 재시도 확인
첫 번째 사항은 아까전 PoC에서 이미 증명됐구요.
다음 PoC에서는 아래 내용을 진행합니다.
RDS 페일오버 시 IP가 변경 될까요?
✔️ 우리의 상황이 책과 동일한 것인지도 확인해 보아요.
✔️ conn timeout에 의한 연결 재시도 확인
1. conn keep-alive를 20초
2. conn timeout을 0초
3. read conn timeout을 30초 구성
4. COMMIT 라인 실행 시 DR DB에게 30초 보다 작은 시간 내로 쿼리가 도달하는 지 확인
이 가정은 참이었습니다. Workbench는 timeout 이벤트가 발생하면 연결 수립을 재시도 합니다.
✔️ 우리의 상황의 책과 동일한 것인지도 확인
1. DR 전환 후 바라보는 IP가 변하는지 nslookup으로 확인합니다.
네 IP가 변화합니다. 그러므로 RDS DR 직후 연결 이슈가 있으면, DNS 해결 이슈 + 댕글링 연결 이슈를 모두 고려해 보아야 합니다.
(끝.)
연관 챕터
2
조사 내용
Active StandBy 전환 간 Dangling Connection 이슈 재현하기 위한 TF
@caffeine-library/readers-release-everything