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

[1단계 - DB 복제와 캐시] 제리(김민정) 미션 제출합니다. #67

Open
wants to merge 17 commits into
base: mzeong
Choose a base branch
from

Conversation

mzeong
Copy link

@mzeong mzeong commented Oct 18, 2024

안녕하세요 구름! 제리입니다
리뷰로 처음 인사드리는 것 같아요 반갑습니다 👋

저는 복제 지연으로 인한 이슈를 해결하기 위해 쿠폰 조회에 실패하면 Writer DB에서 한 번 더 조회를 수행했습니다.

  • 조회 시 지연 시간만큼 기다렸다 응답하는 방법과 다르게 즉각적인 데이터 일관성을 유지하면서도 단순한 구현이 가능합니다.
  • Writer DB에 대한 부하가 증가할 수도 있으나 도메인 특정 상 쿠폰은 조회가 빈번할 것 같지 않았습니다.
    다만 존재하지 않는 id로의 조회가 많다면 문제가 될 수 있을 것 같아요 🤔

편하게 리뷰 남겨주세요 감사합니다 🙇‍♀️

Copy link
Member

@alstn113 alstn113 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

안녕하세요 제리! 구름 ⛅️입니다.

기본 코드는 잘 구현해주셔서 딱히 드릴 말씀이 없습니다.

읽기에 없으면 쓰기에 조회하는 경우로 해결하신 것 같습니다.
적어주신 것처럼 데이터가 없는 경우 쓰기를 조회해서 쓰기 DB에 부하가 생기는 문제도 있을 것 같습니다.
또한 쓰기 DB에 삭제 쿼리가 적용됐고, 읽기 DB에 삭제가 지연되는 경우 없어졌지만 있다고 결과를 낼 수 도 있을 것 같습니다.

이번 복제 지연은 의도적으로 딜레이를 준 것이 문제였습니다.
실제로는 어떤 경우 복제 지연이 발생할까요?
또한 복제 지연을 해결할 수 있는 다른 방법들은 어떤 것들이 있을까요??

참고: https://repost.aws/ko/knowledge-center/rds-mysql-high-replica-lag

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

Successfully merging this pull request may close these issues.

2 participants