[mongoDB] write 이후 read 시, write 하기 전 데이터가 조회되는 현상 해결

[hyoseok0]

개괄

문제 상황

• DB write 이후 read 시, write 하기 전 데이터가 조회되는 경우가 있음

예시

1. 주문내역 저장
2. 저장한 주문내역의 사용자와 상품에 대한 전체 주문 건수, 최근주문내역을 계산 ** 이때 직전에 저장한 주문내역이 조회되지 않는 경우가 있음

원인

• DB write 이후 read 해야 하는 상황에서 아래처럼 설정

구분	값
write concern	w:1, j:true
read concern	majority
read preference	primary

해결

• DB write 이후 read 해야 하는 상황에서 아래처럼 설정

구분	값
write concern	w:majority, j: true
read concern	majority
read preference	primary

해결 상세

• consumer, api, admin
  • default 로 write concern 을 w:majority, j: true 로 설정
  • 건별 처리가 대부분으로, write 응답 속도가 critical 하지 않아 보입니다.
• batch
  • 필요시 write concern 을 w:majority, j: true 한 ReactiveMongoDatabaseFactory, MongoDatabaseFactory bean 추가해서 사용
  • write concern 을 w:majority, j: true 로 설정 시, consistency 가 증가하지만, write 응답이 느려짐
    • 복제지연 발생 시, 응답이 더 느려질 수 있음

---

상세

원인

write 이후 read 시, write 한 데이터를 조회하려면 mongoDB connect 설정이 아래와 같아야 함

• write, read 가 같은 thread 에서 수행 시

구분	값
write concern	w:majority, j:true
read concern	majority

• write, read 가 다른 thread 에서 수행 시

구분	값
write concern	w:majority, j: true
read concern	majority
read preference	primary

현재 shopping-server 설정은 아래와 같고, write concern 조건이 맞지 않습니다.

구분	값
write concern	w:1, j:true
read concern	majority
read preference	secondaryPreferred 가 기본. primary 는 필요 시 설정

참고) 상태값 설명

• read concern
  • majority
    • read query 시, 과반수 이상의 replica set members 에 durable 상태가 된 data 를 return
• write concern
  • w:1, j: true
    • write query 시, primary 에 durable 상태가 되면, 완료됐다고 return
  • majority, j: true
    • write query 시, 과반수 이상의 replica set members 에 durable 상태가 되면, 완료됐다고 return
• read preference
  • primary
    • replica set member 중 primary 에서 조회
  • secondaryPreferred
    • replica set member 중 secondary 에서 조회. 단 secondary 가 불가상태거나, 복제지연이 90초를 넘는 경우 primary 에서 조회

원인 상세

• write concern 이 w:1. j:true 일 때의 write 후 read

  • 참고) t0~t6 까지의 과정은 https://docs.mongodb.com/manual/reference/read-concern-majority/#example 참고
  • t0 때 client 는 write 가 완료됐다고 DB server로부터 acknowledgement 를 받기 때문에, t0 이후 다음process 진행
  • t3 이전까지는 primary 는 secondary1 에 W0 가 durable 가 된 상태를 모르기 때문에, 조회 시 Wprev 를 return
  • t3 이후에 조회하면 write 한 데이터(W0)가 조회되지만, t3 이전에 조회하면 write 하기 전 데이터(Wprev)가 조회됨

• write concern 이 w:majority, j:true 일 때의 write 후 read

  • t3 때 client 는 write 가 완료됐다고 DB server로부터 acknowledgement 를 받기 때문에, t3 이후 다음 process 진행
  • read 가 t3 이후에 수행되므로, 항상 write 한 데이터(W0) 조회

해결

write 이후 read 시, write 한 데이터를 조회하려면 mongoDB connect 설정이 아래와 같이 설정

• write, read 가 같은 thread 에서 수행 시

구분	값
write concern	w:majority, j:true
read concern	majority

• write, read 가 다른 thread 에서 수행 시

구분	값
write concern	w:majority, j: true
read concern	majority
read preference	primary

해결 상세

• consumer, api, admin
  • default 로 write concern 을 w:majority, j: true 로 설정
  • 건별 처리가 대부분으로, write 응답 속도가 critical 하지 않아 보입니다.
• batch
  • 필요시 write concern 을 w:majority, j: true 한 ReactiveMongoDatabaseFactory, MongoDatabaseFactory bean 추가해서 사용
  • write concern 을 w:majority, j: true 로 설정 시, consistency 가 증가하지만, write 응답이 느려짐
    • 복제지연 발생 시, 응답이 더 느려질 수 있음

---

참고자료

• https://docs.mongodb.com/manual/reference/read-concern/
• https://docs.mongodb.com/manual/reference/write-concern/
• https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/
• https://docs.mongodb.com/manual/core/causal-consistency-read-write-concerns/

[hyoseok0]

DB 설정 변경 후, write 이후 read 시, 직전에 write 한 데이터가 조회되는 걸 어떻게 검증할까?

• 로직마다 다를 수 있을 거 같지만, 아래 예시는 저장된 값과 저장되어야 하는 값을 비교하는 배치를 통해 검증했습니다.

  예시

  1. 주문내역 저장
  2. 저장한 주문내역의 사용자와 상품에 대한 전체 주문 건수, 최근주문내역을 계산해서 저장 ** 이때 직전에 저장한 주문내역이 조회되지 않는 경우가 있음

     배치 로직 상세

  3. 저장된 전체 사용자와 상품에 대한 전체 주문건수, 최근주문내역 조회
  4. 주문내역을 통해 저장되어야 할 사용자와 상품에 대한 전체 주문건수, 최근주문내역 계산
  5. 저장된 값과 저장되어야 할 값 비교

     배치 구현 시 고려했던 사항

• 실제로 저장된 값과 저장되어야 할 값이 같지만, 배치의 한계로 두개의 값이 다르게 나올 수 있음
  • 예시 상황
    • 특정 사용자(nidNo:a)가 특정상품(productNo:1) 을 2회 구매했고, 빨간 점선에서 비교 배치 수행 시, 저장된 값과 저장될 값이 달라짐

• 아래와 같이 보완
  • 다음번 배치 수행 결과에서 이전에 달랐던 값이 같아지는지 확인
  • 저장된 값과 저장되어야 할 값이 다른 경우가 적은 경우, 배치 수행 이후 수동으로 데이터 확인
  • 값 비교를 위한 추가 로직 및 flag 설정은 하지 않음
    • 보완 방법이 있으므로, 영향도 최소화를 위해 하지 않음