2025. 4. 14. 16:56ㆍ에러 창고
[Reason]
데이터베이스 Replication을 적용하고 Spring Boot 와 연결하여 데이터를 삭제하고 업데이트하는 과정에서 Master DB에만 반영되고 Slave DB에는 반영되지 않아 Slave DB 상에서 status 를 확인해본 결과 위와 같은 이미지의 내용의 에러가 발생하였다.
status에 나온 에러 메세지 내용대로 Slave DB에서 performance_schema.replication_applier_status_by_worker 테이블을 조회하여 가장 최신의 에러 메세지를 자세히 살펴본 결과, jwt_token 테이블의 특정 행을 찾을 수 없어 SQL Running 끊겼다는 에러였다.
[Solution]
우선 Master DB에 접속하여 status를 확인해준다.
Master DB에서 작업된 내용들을 담고있는 바이너리 로그파일 명을 확인해주고, 해당 파일의 위치값(Position)을 확인해준다.
그 다음, Slave DB 로 다시 넘어가 해당 Slave DB를 stop slave 명령어를 통해 멈춰주고 현 Slave DB와 Master DB를 다시 연결시켜주는 명령어를 통해 연결 설정을 재진행해준다.
(1) Master DB ip 재연결
change master to master_host = '{Master DB 네트워크 ip(나는 docker-compose 를 통해 넣은 해당 DB의 ip값을 넣음)}';
(2) Master DB 로그 파일 연결
change master to master_log_file = '{아까 Master DB에서 확인한 바이너리 로그 파일 명}';
(3) Master DB 로프 파일 post 위치값 수정
change master to master_log_pos = {아까 Master DB에서 확인한 pos 위치 값};
(4) Slave DB 에서 다시 Slave DB 다시 시작
start slave;
Slave DB를 다시 실행하고 status를 확인해보았을 때, 가장 중요한 Slave IO Running, Slave SQL Running 상태 값이 정상적으로 YES로 변경되었는지 확인한다.
이제 연결한 Spring Boot API 를 호출하여 데이터가 두 DB에 똑같이 반영되었는지 확인해주었을 때 위처럼 동일하게 나온 것을 확인할 수 있었다.
## 의문점 ##
추가로, 이 API는 JPA와 QueryDSL을 사용하고 있기 때문에 update와 delete 명령 수행 시 위처럼 EntityManager를 통해 flush로 실 DB에 반영하고 clear를 통해 남아있는 데이터를 깔끔하게 지워주게끔 처리해주었었는데, 내 생각에는 flush로 반영하자마자 clear를 수행했기 때문에 Slave DB에 반영되기도 전에 clear 처리되어 에러가 발생된 것이 아닌가 하는 생각이 들었다.