이번에 작업하면서 확인한 부분을 정리해서 똑같은 문제가 발생되었을 때 조금 더 기억하기 쉽게 해보려고 한다.
AWS RDS 의 Aurora 는 Cluster database 다.
그리고 Cluster 아래에는 instance 가 있다.
기본적으로 2개의 instance 를 둬서 하나는 writer, 하나는 reader 로 두고, 더 많은 reader 를 둘 수 있다.
보통 instance 는 다른 AZ 에 두어서 하나의 zone 이 죽으면 다른 zone 에서 대응하도록 만든다.
이번에 확인했던 부분은 Application 에서 Connection pool 을 만들고, 거기서 idleConnection 을 유지할 경우 발생될 수 있는 문제였다.
idleConnection 이 Writer instance 에 연결되어있는 상태에서 writer 가 응답이 없어서 reader 가 promote, writer 가 demote 된 상황이라고 하자.
이제 idleConnection 은 demote 된 reader 를 바라보게된다.
그리고 서비스가 살아났고, idleConnection 의 lifeSpan 이 유지되는동안 reader 와 다시 연결되었다.
Application 에서 write query 가 발생되면 과연 promote 된 writer 로 연결될까?
정답은 아니다였다.
기존 연결을 유지하게되고, reader 로 쿼리를 날려서 결론적으로는 다음 에러가 발생된다.
Cannot execute statement in a READ ONLY transaction.이렇게 되는 이유는 처음에 연결을 진행할때는 DNS(Endpoint) 를 통해 ip 를 받아와 TCP 연결을 맺고,
TCP 가 유지된 상태에서 instance 가 failover 가 발생되는경우 AWS 는 DNS 정보를 업데이트 하지만,
이미 연결된 idleConnection 들은 수정되지 않은 이 IP 를 사용하기 때문이다.
따라서 health check 는 좀 더 자주 진행하는것이 필요할것으로 보인다.
또는 health check 시 쿼리를 날려서 writer instance 인지 체크하는 로직을 사용할 수도 있다.
추천하는 쿼리는
SELECT @@innodb_read_only