Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why-db-replication-is-set-up/ #4

Open
utterances-bot opened this issue Oct 27, 2021 · 2 comments
Open

why-db-replication-is-set-up/ #4

utterances-bot opened this issue Oct 27, 2021 · 2 comments

Comments

@utterances-bot
Copy link

DB Replication을 구성한 이유 - BingheCompany 🇰🇷

깃-들다에서 DB Replication을 구성한 이유를 알아봐요.

https://tech.pick-git.com/why-db-replication-is-set-up/

Copy link

Rebwon commented Oct 27, 2021

성능을 위해서 이중화를 구성하셨는데, 만약 실시간으로 계속 글이 작성되고, 조회되는 환경이라는 가정을 한다면 마스터 - 슬레이브 간의 데이터 동기화 시점 이전에 조회를 하게 되어, 가져온 게시글이 NPE가 발생할 여지가 있지 않을까요? 만약 이런 상황이라면 어떻게 처리하실 계획이신가요?

Copy link
Member

da-nyee commented Oct 28, 2021

@Rebwon
현재는 Replication이 비동기 방식으로 진행되기 때문에 말씀하신 상황이면 데이터 정합성 문제가 발생할 수 있겠네요!
이를 해결하기 위해 Replication을 준동기 방식으로 변경하는 등의 조치를 취할 수 있을 것 같아요.
그런데 준동기 방식을 쓰면, Master가 Slave의 응답을 기다려야 돼서 성능이 저하될 수 있어요.
그리고 Replication은 Command와 Query를 분리하기 위해서 또는 Master에 장애가 발생했을 때 Slave로 대체하기 위해서 사용하는데, Master에게 Slave의 상태가 영향을 주는 건 주객이 전도되는 상황인 것 같아요.
서비스 운영의 안정성이 데이터 정합성보다 우선순위가 높기 때문에 일종의 trade-off라고 판단했어요 !
또, 사용자는 데이터 불일치를 인지하기 어렵다고 봐요. 만약 알아차려도, 화면을 새로고침하는 등의 다른 액션을 취해서 확인할 것 같아요.
그래서 말씀하신 상황이 발생한다고 해도, 지금과 같은 방식을 유지할 거 같아요.

댓글 달아주셔서 감사합니다 ㅎㅎ 🙇‍♀️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants