- (대부분의 장애 상황을 회피 할 수 있습니다. 특히 17번 18번)
- createuser 시 DB acl 기능 사용하지 말기 -> 개인정보 보호법 관련 등은 다른 방안 마련 필요
- initial sync 시 hidden true 반드시 활성화 (세컨더리 리드시)
- 세컨더리 추가시 반드시 1대씩 또는 majority 넘지 않는 수치만
- 세컨더리 추가시 가장 속편한 거는 기존 정상 세컨더리 죽이고 data 영역 file copy 하는 것
( EBS 스냅샷도 가능할 것으로 보이나 - oplog catch up 이슈로 권장하긴 힘듬)
- 멀티 도큐먼트 트랜잭션 사용중인지 항상 염두할 필요 있음
-> 클러스터에 아비터 데몬을 추가하는 순간 멀티 도큐먼트 옵션 쿼리 다 실패함
- 4.2 이하 버전에서 인덱스 생성 시 primary 생성 후 secondary 생성됨 (완료 메시지는 primary 생성되면 옴)
-> 인덱스 생성 완료되었다고 바로 세컨더리 read 트래픽 유입시키면 장애 발생
- getmore 쿼리는 mongodb 의 cursor 발생 spinlock 발생 하며 이거는 DB log 에서 lock 으로 안 잡힘
- 테이블 변경 /샤딩 룰 추가 등을 할 경우 mongos 에서 캐쉬 리프레시 하는 것을 추천
- 세로운 멤버 변경 의 경우 mongos 에서 꼭 로그 확인할 것 에러 없이 에러발생 할 수 있음
이 경우 8번의 캐쉬 리프레쉬 하거나 이래도 안되면 mongos 재시작 할것 (사실 이런 작업 시 mongos 재시작 하는게 속편함)
- secondary read 시 해당 세컨더리 중단해야 하는 경우 hidden 으로 변경 후 작업 할것
- array 에 index 만들시 주의 필요
-> 생성된 인덱스는 1개이지만 실제로는 array entry 갯수만큼 인덱스 생성된 것과 같은 부하 발생
- primary 중단시 해당 primary 를 재시작 하면 rollback 이라는 폴더가 생기며 프라이머리 죽은 시점의 commit 된 데이터 확인가능
-> 데이터 유실 방지
- TTL 인덱스 사용시 disable 하지 말고 TTL 인덱스를 삭제 할것 추천
- 신규 컬렉션 추가 하고 샤딩 룰 적용할때 서비스 피크시간 피할 것 - config server 에서 meta lock 이 잡힘 몇초 걸리는 경우도 발생
- 청크 마이그레이션에 대한 스케쥴 전략 필요
- rs.conf 에서 priority 되도록이면 설정하지 말기
- 샤딩에서 세컨더리 read 는 되도록이면 하지 말기 - 모든 장애의 시작점
샤딩에서 브로드캐스트 쿼리 발생하지 않게 하기 -> 그게 안되면 프라이머리에서라도 읽기
-> 브로드캐스트 쿼리에 세컨더리 리드를 하는 서비스라면 절대 무거운 쿼리 실행하지 않도록 할것 (예 : 페이징 쿼리 , heavy aggregation query)
- 경험적으로 대락 마이너 패치 12 이하 버전은 사용하면 트러블 발생 확률 있음
예 ) 4.0 버전의 경우 4.0.14 , 4.2 버전의 경우 4.2.12 에서 매우 크리티컬한 이슈가 패치되었음
신규 버전 도입시 반드시 12 내지 14 정도의 마이너 패치가 진행된 버전을 사용하는 것을 추천드립니다.