20240901-jdbc-set-readonly-issue/

[giscus[bot]]

20240901-jdbc-set-readonly-issue/

https://tech.inflab.com/20240901-jdbc-set-readonly-issue/

[havefunatcode]

아무 생각 없이 JDBC를 사용하고 있었는데 해당 글을 읽고나니 주의해서 써야겠다는 경각심이 드네요...
좋은 글 감사합니다!

[mooowu]

간혈적으로 발생하더라도 문제를 해결하려는 모습이 프로다워서 너무 보기 좋네요 🥳 !

[mooowu]

물론 문제 해결 과정도 인상깊고 멋져요!

[hojongs]

잘 읽었습니다 :) 상세한 디버깅 과정 공유와 문제 해결이 인상적이네요

[leedoing]

무슨 말인지 잘 모르겠지만 재밌다...

[namhokim]

AWS Advanced JDBC Wrapper를 사용하고 있다면 Read/Write 분리 기능을 플러그인을 적용하면 클러스터 정보만 제공하면 래퍼가 분리를 해줍니다.

• https://namocom.tistory.com/1085

본문에서는 수동으로 writerDataSource와 readerDataSource 로 구성을 하여 데이터소스를 처리한 것으로 보이는데 이유가 궁금합니다.

[jbl428]

@namhokim 앗 답변이 늦었네요

먼저 readWriteSplitting 플러그인에 대해 공유해주셔서 감사합니다.

말씀하신 것처럼 해당 플러그인으로 read/write 분리를 해주는데 문서를 보니 setReadOnly 호출을 추적해서 하는거로 확인했어요.
그렇게 되면 failover 플러그인과 함께 쓰면, topology 캐시 상태에 따라 간헐적으로 이번에 겪은 에러가 발생하는게 재현될거 같아서 테스트를 해보았는데요.
예상대로 에러가 발생하네요.
이 에러는 블로그에 공유해주신 failover2 플러그인을 쓰거나 setReadOnly 호출 시 topology를 확인하지 않는 작업이 반영된 최신 버전의
드라이버를 쓰면 해결될거 같아요.

이와 별개로 readWriteSplitting를 사용해 dataSource를 하나로 사용할지 read/write 로 분리할지 여부는 상황에 따라 달라질거 같아요.
저희는 read/writer 각 connection pool 설정을 다르게 할 필요가 있어서 나눠서 사용하고 있습니다.

[namhokim]

@jbl428

저도 댓글을 달고 나서 테스트를 진행했는데 readWriteSplitting을 사용해보니 Write Instance에 대해서는 connection pool이 동작하는데 Reader Instance에는 매번 연결을 하는 식으로 동작이 되는 것을 확인했습니다. 조회 이후 바로 요청이 있으면 어느 정도 재사용을 하는 것으로 보입니다.

드라이버 설명에도 나와있는데 (제 블로그에는 하단에 적어두었습니다) Internal connection pools을 사용하지 않을 경우 성능 저하가 발생한다고 적혀있더군요. 아마도 래퍼 드라이버의 내부 연결 풀을 사용하라는 것인데 이렇게 하면 위의 답변처럼 세부적인 설정이 어려워져서 세부적으로 튜닝이 어려워지더군요.

결국 저도 수동으로 Reader/Writer 분리를 해서 운영에 적용을 하였습니다.