복제본 세트 데이터 동기화

이 페이지의 내용

초기 동기화
복제

공유 데이터 세트의 사본을 최신 상태로 유지하기 위해 복제본 세트의 세컨더리 멤버는 다른 멤버의 데이터를 동기화하거나 복제합니다. MongoDB는 전체 세트로 새 구성원을 채우는 초기 동기화와 전체 세트에 지속적인 변경 사항을 적용하는 복제, 두 가지 형태의 데이터 동기화를 사용합니다.

초기 동기화

초기 동기화는 복제본 세트의 멤버 한 개에 있는 모든 데이터를 다른 멤버로 복사합니다. 초기 동기화 소스 선택 기준에 대해 자세히 알아보려면 초기 동기화 소스 선택을 참조하세요.

데이터베이스 local 는 초기 동기화 프로세스 에서 사용하는 oplog 데이터를 저장합니다. 대상 멤버의 local 데이터베이스 에 초기 동기화 프로세스 를 완료하는 데 필요한 oplog 데이터를 저장 수 있는 충분한 공간이 있는지 확인합니다.

참고

초기 동기화 중에 MongoDB는 대상 멤버의 oplog를 잘라냅니다. 이러한 oplog 잘림은 oplog 데이터에 의존하는 변경 스트림과 같은 프로세스에 영향을 미칠 수 있습니다.

initialSyncSourceReadPreference 파라미터를 사용하여 선호하는 초기 동기화 소스를 지정할 수 있습니다. 이 매개변수는 mongod을(를) 시작할 때만 지정할 수 있습니다.

MongoDB 5.2부터 초기 동기화는 논리적 동기화 또는 파일 복사 기반 동기화 중 하나를 선택할 수 있습니다.

논리적 초기 동기화 프로세스

논리적 초기 동기화를 수행하면 MongoDB는 다음을 수행합니다.

로컬 데이터베이스를 제외한 모든 데이터베이스를 복제합니다. 복제하려면 mongod가 각 소스 데이터베이스의 모든 컬렉션을 스캔하여 모든 데이터를 해당 컬렉션의 자체 복사본에 삽입합니다.
각 컬렉션에 대해 문서가 복사될 때 모든 컬렉션의 인덱스를 빌드합니다.
데이터 복사 중에 새로 추가된 oplog 레코드를 가져옵니다. 대상 노드에 이 데이터 복사 단계 동안 이러한 oplog 레코드를 임시로 저장할 수 있는 충분한 디스크 공간이 local 데이터베이스에 있는지 확인합니다.
데이터 세트에 모든 변경 사항을 적용합니다. mongod는 소스의 oplog를 사용하여 복제본 세트의 현재 상태를 반영하도록 해당 데이터 세트를 업데이트합니다.

초기 동기화가 완료되면 노드가 STARTUP2상태에서 SECONDARY로전환됩니다.

초기 동기화를 수행하려면 자체 관리형 복제본 세트의 멤버 재동기화를 참조하세요.

파일 복사본 기반 초기 동기화

MongoDB Enterprise에서만 사용할 수 있습니다.

파일 복사 기반 초기 동기화는 파일 시스템에서 파일을 복사 및 이동하여 초기 동기화 프로세스를 실행합니다. 이 동기화 방법은 논리적 초기 동기화보다 빠를 수 있습니다.

중요

파일 복사본 기반 초기 동기화로 인해 부정확한 카운트가 발생할 수 있습니다.

파일 복사 기반 초기 동기화가 완료된 후 쿼리 조건자 없이 count() 메서드를 실행하면 반환되는 문서 수가 정확하지 않을 수 있습니다.

쿼리 조건자가 없는 count 메서드는 다음과 같이 보입니다: db.<collection>.count().

자세히 알아보려면 쿼리 조건자(predicate)가 없는 부정확한 카운트를참조하세요.

파일 복사본 기반 초기 동기화 활성화

파일 복사 기반 초기 동기화를 활성화하려면, 초기 동기화 대상 노드에서 initialSyncMethod 매개 변수를 fileCopyBased 로 설정합니다. 이 매개변수는 시작 단계에서만 설정할 수 있습니다:

행동

파일 복사 기반 초기 동기화는 동기화 시 대상 노드의 local 데이터베이스를 소스 노드의 local 데이터베이스로 바꿉니다.

제한 사항

파일 복사 기반 초기 동기화 중입니다:
- 동기화 중인 노드 또는 동기화 원본 노드에 대해서는 백업을 실행할 수 없습니다.
- 동기화되는 멤버의 local 데이터베이스에는 쓸 수 없습니다.
초기 동기화는 한 번에 한 개의 지정된 멤버에서만 실행할 수 있습니다.
암호화된 스토리지 엔진을 사용할 때 MongoDB는 소스 키를 사용하여 대상을 암호화합니다.

NVMe 클러스터의 초기 동기화

Atlas 자동 확장 을 사용하는 경우를 포함하여 로컬 NVMe (Non-Volatile Memory Express) SSD 저장 옵션을 사용하는 클러스터에서 초기 동기화를 수행해야 합니다. Atlas NVMe 클러스터는 저장 공간의 90%가 가득 차면 다음 상위 계층으로 자동 확장됩니다. 초기 동기화는 후속 동기화에 비해 완료하는 데 시간이 더 오래 걸리고 데이터를 읽는 프라이머리 동기화의 성능이 저하됩니다.

내결함성

초기 동기화를 수행하는 세컨더리 노드가 일시적이지 않은 네트워크 오류를 만나면, 세컨더리 노드는 초기 동기화 프로세스를 처음부터 다시 시작합니다.

초기 동기화를 수행하는 세컨더리는 동기화 프로세스가 일시적인(즉, 임시) 네트워크 오류, 컬렉션 제거 또는 컬렉션 이름 변경으로 인해 중단된 경우 동기화를 다시 시작하려고 시도할 수 있습니다.

기본적으로 보조 동기화는 24시간 동안 초기 동기화를 재개하려고 시도합니다. initialSyncTransientErrorRetryPeriodSeconds 서버 매개 변수를 사용하여 세컨더리가 초기 동기화를 재개하려고 시도하는 시간을 제어할 수 있습니다. 세컨더리가 구성된 기간 동안 초기 동기화 프로세스를 성공적으로 재개할 수 없는 경우 복제본 세트에서 새로운 정상 소스를 선택하고 초기 동기화 프로세스를 처음부터 다시 시작합니다.

세컨더리는 치명적인 오류를 반환하기 전에 최대 10번까지 초기 동기화를 다시 시작하려고 시도합니다.

초기 동기화 소스 선택

초기 동기화 소스 선택은 mongod 스타트업 매개 변수 initialSyncSourceReadPreference의 값에 따라 달라집니다.

primary로 설정된 initialSyncSourceReadPreference의 경우(chaining이 비활성된 경우 기본값) 프라이머리 항목을 동기화 로 선택합니다. 프라이머리를 사용할 수 없거나 연결할 수 없는 경우 오류를 로깅하고 정기적으로 프라이머리 가용성을 확인합니다.
initialSyncSourceReadPreference가 primaryPreferred로 설정되어 있다면(투표하는 복제본 세트 노드의 기본 설정), 프라이머리를 동기화 소스로 선택하려고 시도합니다. 프라이머리가 사용 불가능하거나 접근할 수 없는 경우, 나머지 복제본 세트 노드 중에서 동기화 소스를 선택합니다.
지원되는 다른 모든 읽기 모드의 경우 복제본 세트 노드에서 동기화 소스 선택을 수행합니다.

초기 동기화 소스 선택을 수행하는 멤버들은 모든 복제본 세트 멤버 목록을 두 번 훑습니다:

멤버는 초기 동기화 소스를 선택하기 위한 첫 번째 전달을 만들 때 각 복제본 세트 멤버에 다음 기준을 적용합니다.

동기화 소스는 반드시 PRIMARY 또는 SECONDARY 복제 상태여야 합니다.
동기화 소스는 반드시 온라인 상태이고 접근 가능해야 합니다.
initialSyncSourceReadPreference가 secondary 또는 secondaryPreferred 인 경우 동기화 소스는 반드시 세컨더리여야 합니다.
동기화 소스는 반드시visible여야 합니다.
동기화 소스는 프라이머리의 최신 oplog 항목에서 30초 이내에 반드시 있어야 합니다.
builds indexes노드인 경우 동기화 소스는 인덱스를 반드시 작성해야 합니다.
votes 멤버가 복제본 세트 투표에 속해 있는 경우 동기화 소스도 투표해야 합니다.
이 멤버가 delayed member이(가) 아닌 경우 동기화 소스 구성 시간이 지연되지 않아야 합니다.
이 멤버가 delayed member일 경우 동기화 소스의 구성 시간 지연이 단축되어야 합니다.
이 동기화 소스의 구성 시간은 현재 최고 동기화 소스보다 빨라야 합니다(즉, 지연 시간이 낮아야 함).

첫 번째 전달 이후에 후보 동기화 소스가 남아 있지 않은 경우 노드는 완화된 기준으로 두 번째 시도를 수행합니다. Sync Source Selection (Second Pass)에서 확인 가능합니다.

노드는 초기 동기화 소스를 선택하기 위한 두 번째 전달을 만들 때 각 복제본 세트 노드에 다음 기준을 적용합니다.

동기화 소스는 반드시 PRIMARY 또는 SECONDARY 복제 상태여야 합니다.
동기화 소스는 반드시 온라인 상태이고 접근 가능해야 합니다.
initialSyncSourceReadPreference이(가) secondary인 경우 동기화 원본은 세컨더리여야 합니다.
노드 builds indexes인 경우 동기화 소스는 인덱스를 반드시 작성해야 합니다.
이 동기화 소스의 구성 시간은 현재 최고 동기화 소스보다 빨라야 합니다(즉, 지연 시간이 낮아야 함).

두 번 통과한 후에도 노드가 초기 동기화 소스를 선택할 수 없는 경우 오류를 로깅하고 1초를 기다린 후 {0}프로세스를 다시 시작합니다. 세컨더리 mongod는 오류로 종료되기 전에 초기 동기화 소스 선택 과정을 최대 10 번 다시 시작할 수 있습니다.

Oplog 윈도우 (oplog window)

Oplog window는 세컨더리가 논리적 초기 동기화 프로세스 의 시작과 끝 사이에 발생하는 새 oplog 항목을 가져올 수 있을 만큼 충분히 길어야 합니다. 창이 충분히 길지 않으면 일부 항목이 세컨더리가 적용하기 전에 oplog에서 떨어질 위험이 있습니다.

oplog개 항목을 새로 가져올 수 있도록 oplog의 크기를 넉넉하게 설정하는 것이 좋습니다. 이는 초기 동기화 동안 발생할 수 있는 변경사항에 대비하는 것입니다.

자세한 내용은 Oplog 크기를 참조하세요.

복제

세컨더리 멤버는 초기 동기화 후 지속적으로 데이터를 복제합니다. 세컨더리 멤버는 소스에서 동기화된 oplog를 복사하여 비동기 프로세스에서 이러한 작업을 적용합니다. [1]

세컨더리 멤버는 다른 멤버의 핑 시간 및 복제 상태의 변화에 따라 필요에 따라 소스에서 동기화를 자동으로 변경할 수 있습니다. 동기화 소스 선택 기준에 대한 자세한 내용은 복제 동기화 소스 선택을 참조하세요.

[1]	이제 복제본 세트의 세컨더리 멤버가 느린 작업 임곗값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다. `diagnostic log`에 세컨더리 멤버에 대해 기록합니다. 텍스트와 함께 구성 요소 아래에 기록됩니다. 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다. 프로파일링 수준에 의존하지 않습니다. `slowOpSampleRate`의 영향을 받습니다. 에 세컨더리 멤버에 대해 기록합니다. 의 영향을 받습니다. 프로파일러는 느린 oplog 항목을 캡처하지 않습니다.

스트리밍 복제

소스로부터의 동기화는 oplog 항목의 연속 스트림을 동기화 세컨더리 항목으로 보냅니다. 스트리밍 복제는 부하가 높고 대기 시간이 긴 네트워크에서 복제 지연 시간을 완화합니다. 또한 다음이 가능합니다.

보조 데이터에서 읽은 데이터의 부실함을 감소.
프라이머리 페일오버로 인해 w: 1 설정으로 쓰기 작업이 손실될 위험이 줄어듭니다.
w: "majority" 및 w: >1(즉, 복제를 기다려야 하는 모든 쓰기 고려)을 사용한 쓰기 작업의 지연 시간을 줄입니다.

스트리밍 복제를 비활성화하고 이전 복제 동작을 사용하려면 oplogFetcherUsesExhaust 시작 매개변수를 사용합니다. 소스에서 동기화에 리소스 제약이 있거나 복제를 위한 MongoDB의 네트워크 대역폭 사용을 제한하려는 경우에만 oplogFetcherUsesExhaust 매개 변수를 false로 설정하세요.

멀티스레드 복제

MongoDB는 동시성을 향상시키기 위해 여러 스레드를 사용하여 쓰기 작업을 배치로 적용합니다. MongoDB는 문서 ID(WiredTiger)를 기준으로 배치를 그룹화하고, 다른 스레드를 사용하여 각 작업 그룹을 동시에 적용합니다. MongoDB는 항상 특정 문서에 대한 쓰기 작업을 원래 쓰기 순서대로 적용합니다.

읽기 작업이 세컨더리를 대상으로 하고 "local" 또는 "majority"의 읽기 고려 수준으로 구성된 경우, 복제 배치가 적용되는 세컨더리에 읽기가 수행될 때 데이터의 WiredTiger 스냅샷에서 읽습니다.

스냅샷에서 읽기는 데이터의 일관된 뷰를 보장하고, 잠금 없이 진행 중인 복제와 동시에 읽기를 수행할 수 있도록 합니다. 결과적으로, 이러한 읽기 고려 수준이 필요한 보조 읽기는 더 이상 복제 배치가 적용될 때까지 기다릴 필요 없이 수신되는 대로 처리될 수 있습니다.

흐름 제어

MongoDB 4.2부터 관리자는 majority committed 지연을 구성 가능한 최대값 flowControlTargetLagSeconds이하로 유지하는 것을 목표로 기본이 쓰기를 적용하는 속도를 제한할 수 있습니다.

기본적으로 흐름 제어는 enabled 입니다.

참고

흐름 제어가 작동하려면 복제본 세트/샤딩된 클러스터에 4.2 의 featureCompatibilityVersion(fCV) 과 majority enabled의 읽기 우려 사항이 있어야 합니다. 즉, fCV가 4.2 가 아니거나 읽기 문제 과반수가 비활성화된 경우 활성화된 흐름 제어는 효과가 없습니다.

자세한 내용은 흐름 제어를 참조하세요.

복제 동기화 소스 선택

복제 동기화 소스 선택은 복제본 세트 chaining 설정에 따라 달라집니다.

체인이 활성화된 상태(기본값)에서는 복제본 세트 멤버들 중에서 동기화 소스를 선택합니다.
체인이 비활성화된 상태에서 프라이머리 소스를 동기화 소스로 선택합니다. 프라이머리를 사용할 수 없거나 연결할 수 없는 경우 오류를 로깅하고 정기적으로 프라이머리 가용성을 확인합니다.

복제 동기화 소스 선택을 수행하는 노드는 모든 복제본 세트 노드의 목록을 다음과 같이 두 번 훑습니다.

멤버는 복제 동기화 소스를 선택하기 위한 첫 번째 전달을 만들 때 각 복제본 세트 멤버에 다음 기준을 적용합니다.

동기화 소스는 반드시 PRIMARY 또는 SECONDARY 복제 상태여야 합니다.
동기화 소스는 반드시 온라인 상태이고 접근 가능해야 합니다.
동기화 소스는 멤버보다 최신의 oplog 항목이 있어야 합니다(즉 동기화 소스가 멤버보다 앞서 있어야 합니다).
동기화 소스는 반드시visible여야 합니다.
동기화 소스는 프라이머리의 최신 oplog 항목에서 30초 이내에 반드시 있어야 합니다.
builds indexes노드인 경우 동기화 소스는 인덱스를 반드시 작성해야 합니다.
votes 멤버가 복제본 세트 투표에 속해 있는 경우 동기화 소스도 투표해야 합니다.
이 멤버가 delayed member이(가) 아닌 경우 동기화 소스 구성 시간이 지연되지 않아야 합니다.
이 멤버가 delayed member일 경우 동기화 소스의 구성 시간 지연이 단축되어야 합니다.
이 동기화 소스의 구성 시간은 현재 최고 동기화 소스보다 빨라야 합니다(즉, 지연 시간이 낮아야 함).

첫 번째 전달 이후에 후보 동기화 소스가 남아 있지 않으면 멤버는 완화된 기준을 사용하여 두 번째 전달을 수행합니다. Sync Source Selection (Second Pass)을(를) 참조하세요.

노드는 복제 동기화 소스를 선택하기 위한 두 번째 전달을 만들 때 각 복제본 세트 노드에 다음 기준을 적용합니다.

동기화 소스는 반드시 PRIMARY 또는 SECONDARY 복제 상태여야 합니다.
동기화 소스는 반드시 온라인 상태이고 접근 가능해야 합니다.
노드 builds indexes인 경우 동기화 소스는 인덱스를 반드시 작성해야 합니다.
이 동기화 소스의 구성 시간은 현재 최고 동기화 소스보다 빨라야 합니다(즉, 지연 시간이 낮아야 함).

두 번 통과한 후에도 멤버가 동기화 소스를 선택할 수 없는 경우 오류를 로깅하고 1초를 기다린 후 선택 프로세스를 다시 시작합니다.

시간당 소스를 변경할 수 있는 횟수는 maxNumSyncSourceChangesPerHour 매개변수를 설정하여 구성할 수 있습니다.

참고

초기 동기화 소스를 선택할 때 시작 매개변수 initialSyncSourceReadPreference는 복제본 세트의 settings.chainingAllowed 설정보다 우선합니다. 복제본 세트 멤버가 초기 동기화를 성공적으로 수행한 후에는 복제 동기화 소스를 선택할 때 chainingAllowed 값을 사용합니다.

초기 동기화 소스 선택에 대한 자세한 내용은 초기 동기화 소스 선택을 참조하세요.

돌아가기

Oplog

복제본 세트 멤버