☰

MongoDB가 자동으로 다시 시작되지 않는 이유는 무엇입니까?

tag-icon • tag-icon ubuntu mongodb systemd
MongoDB가 자동으로 다시 시작되지 않는 이유는 무엇입니까?

MongoDB 3.6은 충돌 시 다시 시작하도록 자동으로 구성되지 않은 것 같습니다. Ubuntu 16.04LTS용 최신 .deb 패키지와 함께 번들로 제공되는 systemd 서비스를 보면 재시작이 구성되어 있지 않은 것 같습니다.

$ sudo systemctl cat mongod
# /lib/systemd/system/mongod.service
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual

[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
PIDFile=/var/run/mongodb/mongod.pid
# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# locked memory
LimitMEMLOCK=infinity
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false

# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings

[Install]
WantedBy=multi-user.target

SIGKILL 및 SIGSEGV를 보내면 프로세스가 모두 종료되고 다시 시작되지 않습니다. 그러나 이것이 systemd에 의해 "포착"되었는지, 단지 다시 시작되었는지는 확실하지 않습니다.

몇 가지 질문이 있습니다. 이것이 데이터베이스와 같은 고가용성 서비스에 중요한가요? 확실히 그럴 것 같습니다. MongoDB가 이를 기본적으로 구성하지 않은 이유가 있습니까?

답변1

배포에 대한 서비스 기본값을 언제든지 변경할 수 있지만 예기치 않은 종료는 확실히 관리자 개입이 강력히 권장되는 경우입니다.

프로세스 종료 이유가 mongod수동 개입 없이는 해결할 수 없는 불변적인 경우(예: 디스크 공간 부족 또는 데이터 파일 손상) 자동 다시 시작은 도움이 되지 않으며 잠재적으로 상황을 더 악화시킬 수 있습니다. 일반적으로 mongod복구 가능한 오류가 발생한 경우 종료하면 안 됩니다. 몽고DB서버 예외 아키텍처작업별 치명적인 오류와 전체 프로세스에 치명적인 오류를 구별합니다. 프로세스에 치명적인 오류는 계속 진행하면 데이터 손실이나 디스크의 데이터 손상과 같은 심각한 결과를 초래할 수 있는 상황입니다. 프로세스를 종료하기 위해 사용자 또는 O/S가 시작한 신호(예:메모리 부족(OOM Killer라고도 함)Linux의 경우)도 종료됩니다 mongod.

의견에 언급된 오류의 예로는 이전 버전의 MongoDB를 사용하는 일부 보조 데이터베이스에서 세그폴트가 발생한 인덱스 빌드가 있었습니다. 자동 서비스 재시작을 사용하면 이 시나리오는 잠재적으로 보조 서버가 충돌하고, 다시 시작하고, 인덱스 빌드를 재개하고, 동일한 조건이 발생하고, 다시 시작하여 운명이 정해진 인덱스 빌드를 재개할 수 있는 무한 루프로 이어질 수 있습니다. 이 다시 시작 루프가 진행되는 동안 보조의 간헐적인 가용성은 보조 읽기 기본 설정 또는 복제본 세트의 다른 구성원을 사용하는 클라이언트에 영향을 미칠 수 있습니다(예: 동기화를 재개하기 위해 업스트림 oplog에서 반복적으로 검색).

시스템 관리자로서 저는 MongoDB 로그를 검토하고 프로세스가 종료된 이유를 이해하여 근본 원인을 해결하는 것을 선호합니다. 이상적으로 배포에는 충분합니다.결함 허용회원이 부재중일 때 대처할 수 있도록 상황을 조사하고 해결할 시간을 갖습니다.

문제 및 배포의 성격(독립 실행형, 복제본 세트 또는 분할된 클러스터)에 따라 자동 또는 수동 복구를 시도하기 전에 데이터 파일을 백업할 수도 있습니다. 예를 들어, 비정상적으로 종료된 후 다시 시작하면 mongod미해결 저널 항목을 적용하고 dbPath. 독립형 서버의 경우 복구/복구를 시도하기 전에 수정되지 않은 데이터 파일의 복사본을 만드는 것이 좋습니다. 복제본 세트 배포를 사용하면 데이터가 이미 복제본 세트의 다른 구성원에 복제되어 있으므로 표준 복구가 실패하면이 구성원을 다시 동기화하세요.수리를 시도하는 것보다.

답변2

systemd를 사용하는 경우 섹션 Restart=always에서 [Service]충돌 후 서비스를 다시 시작할 수 있도록 허용해야 합니다.

답변3

고가용성에 대해 정말로 관심이 있다면 복제본 세트를 실행하고 1개 이상의 노드 실패를 처리할 수 있습니다.

5년 동안 프로덕션 환경에서 샤딩된 대규모 mongodb 배포를 개인적으로 관리해 온 저는 인스턴스가 자동으로 다시 시작되지 않는 것을 선호합니다. 복제본 세트에서 다시 순환되기 전에 모든 문제를 조사하고 싶기 때문입니다.

https://docs.mongodb.com/manual/core/replica-set-high-availability/

관련 정보