MySQL Replication 도입 후 Failover 테스트

모두·2025년 3월 22일

오늘은 MySQL Replication 을 사용하면서 Failover 가 일어나는 상황에 따라 테스트를 해보는 글을 작성하려 한다.

Failover 테스트

  • 상황별로 어떤 일이 벌어지는지 구경
    • Master를 죽여보자
    • Slave를 죽여보자
    • 트랜잭션 처리가 잘되는지 보자

일단 트랜잭션 처리가 잘 되는지 부터 보자

보통 트랜잭션은 쓰기 작업에서 많이 사용한다.
master로 가서 transaction 시작하고

앞선 글에서 test 용으로 작성한 공지 사항의 삭제 사항을 True 변경 해보겠다. 쿼리를 날려보고

쿼리를 날린 상태에서 공지 사항 디비 새로고침 해서 보면 아직 트랜잭션 commit 이 안된 상태이기 때문에 아직 상태가 false 이다.

  • 당연히 아직 slave 도 false 상태

이 상태에서 COMMIT 해서 반영하게 되면

Master, Slave 둘다 true로 바뀌었다.

그러면 어떻게 가져왔나 Slave 쪽 log 보면

relay log 가 이 경로에 쌓이고 있었다고 하니까 이 경로 한번 가보자.

보면 efe78f96b797-relay-bin.000001 여기서 받아온 것 같고 index 가 현재 위치 계속 여기서 copy 하고 있다는 의미

바이너리 로그이니까 cat으로 열어보면

  • 포지션이 증가하는 걸 간단하게 볼 수 있다.

그러면 지금까지 트랜잭션은 잘 되는 걸 확인했고 이 때 Slave 를 꺼보자 .

그러면 master 만 남았고

이 상태에서 data를 넣어보겠다.

  • master 쪽 공지사항 가서 data 추가

그러면 master 디비에 반영되었다.

과연 이 상태에서 slave 가 살아나면 이 두번째 추가한 데이터에 대해서 싱크 해올까??

다시 slave 키고

log 보면 깨어나자 마자 싱크가 된 거 같다.

slave 디비가서 새로고침 해보면 우와 들어있다!!!

그러면 slave 가 죽어도 master 싱크 받는구나 알 수 있다.

이제 slave를 살리고 master 를 죽여보자

이후 master에서 새로고침 해보면 당연히 실패 뜨고

slave에서 새로고침 해보면 데이터 조회는 된다.

근데 그러면 master가 죽었으니까 slave에 쓰면 써질까?? 궁금하다.

slave쪽에 가서 쿼리 실행해보자

  • 아까 바꿔던 true를 다시 false 로 바꿔는 쿼리 실행
  • 어??? 실행이 된다.

slave쪽 디비 가서 조회해보면 심지어 false로 값 바뀌었다.

어??? 근데 slave는 읽기 전용 아니야???
slave 상태를 한번 보자


I/O 계속 파일 받아오는거 시도 중이지만 connecting 상태로 못 받아오고 있다.


그래서 master 쪽에서 연결하는거 실패한 상태다라고 뜬다.

그러면 이 상태에서 master 살리면 어떻게 될까?

slave에서 1번 data에 대해서 false 해으니까 master에서 조회해보면 바뀌었을까?

  • 아직 true 이다. 안바뀌었다.

하지만 slave 쪽에서는 flase

서로의 데이터가 안맞는 상태이다.

이 상태에서 master에서 다시 데이터 수정해보자.

  • content 수정

slave 에서 조회해보면 안바뀌었다. 정확성 깨졌다.

어..? 그러면 Failover 가 자동으로 된게 아니다.
slave는 떨어졌다 다시 붙으면 자동으로 되는데
master는 떨어졌다 붙으면 동기화가 안된다.

master에서 데이터 하나 더 추가

하고 slave에서 보면 데이터가 나온다. 갑자기 동기화를 했네?

이런 식으로 비동기적으로 복제가 일어 나기 때문에 지연이 발생 할 수 있다.

  • 운이 좋은 케이스 다시 맞추어서 무결성이 보장되었다.
  • 데이터 수가 적어서 잘 된 것같다.

다시 slave에서 데이터 수정 쿼리 날려보자 true -> false로

slave 디비에서 보면 false 로 바뀌었고

master는 true 인 상태

즉 slave 쪽에만 처리 되어 있다.

lonoDB 이기에 log 단위로만 체크를 한다. 그래서 만약 1번 id의 다른 항목에 데이터가 변경 일어날 때 새로고침 해보면 false로 맞추어 줘서 무결성 보장될 것이다.

master가 죽더라도 데이터가 slave에 반영됬다라고 하더라도
master가 다시 살아나면 slave가 master에 맞게 끔 데이터 무결성을 맞춰준다.

이상한 건 slave 쪽에서 계속 쓰기 작업이 되고 있다.

  • 사실 이걸 막아줘야 한다.

그래서 원래 Slave 쪽에서는 read_only 켜줘야 한다.

만약 master 죽어도 read_only 를 off 해서 굳이 slave에서 쓰기 작업을 한다하면 master가 돌아왔을 때 정확성이 떨어지게 된다.

만약 이렇게 read_only 를 꺼버리게 되면 끈다하더 라도 master가 살아나면 slave는 master에 있는 데이터를 바라보고 있기 때문에 거기 맞춘다.

지금 여기서는 바닐라 MySQL 을 사용하고 있기 때문에 여기서는 Failover 일어났을 때 자체 승격이 없다.

  • 즉 master 죽었을 때 slave master로 바꾸어 주는 기능 없다.

그걸 할려면 서드파티 힘 빌려야 하고 대표적으로 옵저버 역할을 하는 MHA 가 있다.

0개의 댓글