Part 2. 분산 데이터

• 여러 장비 간 분산된 데이터베이스를 필요로 하는 이유
  • 확장성
  • 내결함성/고가용성
  • 지연 시간

고부하로 확장

• 공유 메모리 아키텍처 (수직 확장)
  • 단점
    • 비용이 선형적인 추세보다 훨씬 빠르게 증가
    • 제한적인 내결함성
    • 하나의 지리적인 위치로 제한됨
• 비공유 아키텍처 (수평 확장) 공유 아키텍처의 단점을 극복할 수 있다.
  

복제 대 파티셔닝

• 복제 같은 데이터의 복사본을 잠재적으로 다른 위치에 있는 여러 노드에 유지한다.
  
• 파티셔닝 큰 데이터베이스를 파티션이라는 작은 서브셋으로 나누고 각 파티션은 각기 다른 노드에 할당한다. (샤딩)
  

---

05. 복제

• 복제가 필요한 이유
  • 지리적으로 가깝게 유지하여 지연 시간을 줄인다.
  • 가용성을 높인다.
  • 장비의 수를 확장해 처리량을 늘린다.
• 복제에서 모든 어려움은 복제된 데이터의 변경 처리에 있다.

리더와 팔로워

• 데이터베이스의 복사본을 저장하는 각 노드를 복제 서버(replica)라고 한다.
• 모든 쓰기는 모든 복제 서버에서 처리돼야 한다. 해결책은 리더 기반 복제(능동/수동, 마스터 슬레이브 복제)이다.
• 메커니즘 복제 서버 중 하나를 리더(마스터 or 프라이머리)로 지정한다. 클라이언트가 데이터베이스에 쓰기를 할 때, 클라이언트는 요청을 리더에게 보내야 한다. 리더는 먼저 로컬 저장소에 새로운 데이터를 기록한다. 다른 복제 서버는 팔로워(슬레이브, secondary)라고 한다. 리더가 로컬 저장소에 새로운 데이터를 기록할 때마다 데이터 변경을 복제 로그나 변경 스트림의 일부로 팔로워에게 전송한다. 각 팔로워가 리더로부터 로그를 받으면 리더가 처리한 것과 동일한 순서로 모든 쓰기를 적용해 그와 맞게 데이터베이스의 로컬 복사본을 갱신한다. 클라이언트가 읽기를 할 때는, 리더 또는 임의 팔로워에게 질의할 수 있다. 쓰기는 리더에게만 허용된다. (팔로워는 읽기 전용이다)
  

동기식 대 비동기식 복제

• 동기식 리더는 팔로워가 쓰기를 수신했는지 확인해줄 때까지 기다린다. 확인이 끝나면 사용자에게 성공을 보고하고, 다른 클라이언트에게 해당 쓰기를 보여준다.
  • 장점 팔로워가 리더와 일관성있게 최신 데이터 복사본을 가지는 것을 보장한다.
    
  • 단점 동기 팔로워가 응답하지 않으면 쓰기가 처리될 수 없다.
    
• 비동기식 리더는 메시지를 전송하지만 팔로워의 응답을 기다리지 않는다.
  • 장점 모든 팔로워가 잘못되더라도 리더가 쓰기 처리를 계속 할 수 있다.
    
  • 단점 리더가 잘못되고 복구할 수 없으면 팔로워에 아직 복제되지 않은 모든 쓰기는 유실된다. 즉, 쓰기가 클라이언트에게 확인된 경우에도 지속성을 보장하지 않는다.
    

현실적으로 데이터베이스에서 동기식 복제를 사용하려면 보통 팔로워 하나는 동기식으로 하고, 그 밖에는 비동기식으로 하는 것을 의미한다. 동기식 팔로워가 사용할 수 없게 되면 비동기식 팔로워 중 하나가 동기식 팔로워가 된다. 이것은 적어도 두 노드(리더와 동기식 팔로워)에 데이터 최신 복사본이 있음을 보장한다. 반동기식(semi-synchronous)이라고도 한다.

새로운 팔로워 설정

팔로워가 추가될 때, 한 노드에서 새 노드로 데이터 파일을 복사하는 것만으로는 정확한 복제본임을 보장할 수 없다. 데이터는 항상 유동적이므로 표준 파일 복사본은 다른 시점에 데이터베이스의 다른 부분을 보게 된다.

• 해결하는 방법
  1. 리더의 데이터베이스 스냅숏을 일정 시점에 가져온다.
  2. 이 스냅숏을 새로운 팔로워 노드에 복사한다.
  3. 팔로워는 리더에 연결해 스냅숏 이후 발생한 모든 데이터 변경을 요청한다.
  4. 팔로워가 스냅숏 이후 데이터 변경의 미처리분을 모두 처리했을 때, 따라잡았다고 말한다.

노드 중단 처리

개별 노드의 장애에도 전체 시스템이 동작하게끔 유지하고 노드 중단의 영향을 최소화하는 것이 목표이다.

팔로워 장애: 따라잡기 복구

각 팔로워는 리더로부터 수신한 데이터 변경 로그를 로컬 디스크에 보관한다. 보관된 로그에서 결함이 발생하기 전에 처리한 마지막 트랜잭션을 알아낸다. 리더에 연결해 팔로워 연결이 끊어진 동안 발생한 데이터 변경을 모두 요청할 수 있다.

리더 장애: 장애 복구

팔로워 중 하나를 새로운 리더로 승격해야 하고, 클라이언트는 새로운 리더로 쓰기를 전송하기 위해 재설정이 필요하며, 다른 팔로워는 새로운 리더로부터 데이터 변경을 소비해야 한다.

• 자동 장애 복구의 단계
  1. 리더가 장애인지 판단한다. (대개 타임아웃을 사용함)
  2. 새로운 리더를 선택한다.
  3. 새로운 리더 사용을 위해 시스템을 재설정한다.
• 장애 복구 과정에서 잘못될 수 있는 것들
  • 비동기식 복제를 사용한다면 새로운 리더는 이전 리더가 실패하기 전에 이전 리더의 쓰기를 일부 수신하지 못할 수 있다.
  • 쓰기를 폐기하는 방법은 위험이 많다.
  • 특정 결함 시나리오에서 두 노드가 모두 자신이 리더라고 믿을 수 있다. (스플릿 브레인)
  • 리더가 죽었다고 판단할 수 있는 적절한 타임아웃은 과연 얼마일까?

복제 로그 구현

구문 기반 복제

리더는 모든 쓰기 요청을 기록하고 쓰기를 실행한 다음 구문 로그를 팔로워에게 전송한다. 각 팔로워는 클라이언트에서 직접 받은 것처럼 SQL 구문을 파싱하고 실행한다.

이 방식은 여러 문제점이 있다. (NOW 사용 등)

쓰기 전 로그 배송

일반적으로 모든 쓰기는 로그에 기록된다.

완전히 동일한 로그를 사용해 다른 노드에서 복제 서버를 구축할 수 있다. 팔로워가 이 로그를 처리하면 리더에서 있는 것과 정확히 동일한 데이터 구조의 복제본이 만들어진다.

• 단점 로그가 제일 저수준의 데이터를 기술한다. → 복제가 저장소 엔진과 밀접하게 엮인다.
  

논리적(로우 기반) 로그 복제

복제 로그를 저장소 엔진 내부와 분리하기 위한 대안은 복제와 저장소 엔진을 위해 다른 로그 형식을 사용하는 것이다. 이를 논리적 로그라고 한다.

관계형 데이터베이스용 논리적 로그는 대개 로우 단위로 데이터베이스 테이블에 쓰기를 기술한 레코드 열이다.

트리거 기반 복제

트리거는 사용자 정의 애플리케이션 코드를 등록할 수 있다. 이 애플리케이션 코드는 데이터베이스 시스템에서 데이터가 변경되면 자동으로 실행된다. 트리거는 데이터 변경을 분리된 테이블에 로깅할 수 있다. 이 테이블로부터 데이터 변경을 외부 프로세스가 읽을 수 있다. 그러면 외부 프로세스는 필요한 애플리케이션 로직을 적용해 다른 시스템으로 데이터 변경을 복제한다.

• 장점 : 유연성
• 단점 : 더 많은 오버헤드, 버그, 제한 사항

복제 지연 문제

• 읽기 확장 아키텍처에서는 간단히 팔로워를 더 추가함으로써 읽기 전용 요청을 처리하기 위한 용량을 늘릴 수 있다. 이는 실제로 비동기식 복제에서만 동작한다.
• 최종적 일관성 비동기 팔로워에서 데이터를 읽을 때, 팔로워가 뒤처진다면 데이터베이스에 명백히 불일치가 발생한다. 하지만 이런 불일치는 일시적 상태에 불과하다. 데이터베이스에 쓰기를 멈추고 잠시 기다리면 팔로워는 결국 따라잡게 되고 리더와 일치하게 된다.
  

자신이 쓴 내용 읽기

• 리더 기반 복제 시스템에서 쓰기 후 읽기 일관성 구현 방법
  • 사용자가 수정한 내용을 읽을 때는 리더에서 읽는다.
  • 애플리케이션 내 대부분의 내용을 사용자가 편집할 수 있다면 이 접근 방식은 대부분 리더에서 읽기 때문에 비효율적이다. 예를 들어 마지막 갱신 후 1분 동안은 리더에서 모든 읽기를 수행하는 식으로 개선할 수 있다.
  • 복제 서버가 여러 데이터센터에 분산되어있어도, 리더가 제공해야 하는 요청은 리더가 포함된 데이터센터로 라우팅되야 한다.
• 디바이스 간 쓰기 후 읽기 일관성 사용자 디바이스의 요청을 동일한 데이터 센터로 라우팅해야 한다.
  

단조 읽기

• 사용자가 시간이 거꾸로 흐르는 현상은 비동기식 팔로워에서 읽을 때 발생할 수 있다.
• 단조 읽기는 위 현상이 발생하지 않음을 보장한다. 단조 읽기는 강한 일관성보다는 덜한 보장이지만, 최종적 일관성보다는 더 강한 보장이다. 이전에 새로운 데이터를 읽은 후에는 예전 데이터를 읽지 않는다.
  
• 단조 읽기를 달성하는 방법은 각 사용자의 읽기가 항상 동일한 복제 서버에서 수행되게끔 하는 것이다.

일관된 순서로 읽기

• 일관된 순서로 읽기는 일련의 쓰기가 특정 순서로 발생한다면 이 쓰기를 읽는 모든 사용자는 같은 순서로 쓰여진 내용을 보게 됨을 보장한다.
• 파디셔닝(샤딩)된 데이터베이스에서 발생하는 특징적인 문제다. 데이터베이스가 항상 같은 순서로 쓰기를 한다면, 읽기는 항상 일관된 순서를 보기 때문에 순서가 바뀌는 현상은 나타나지 않는다. 하지만 분산 데이터베이스에서 서로 다른 파티션은 독립적으로 동작하므로 쓰기의 전역 순서는 없다. 즉, 사용자가 데이터베이스에서 읽을 때 예전 상태의 일부와 새로운 상태의 일부를 함께 볼 수 있다.
  

복제 지연을 위한 해결책

트랜잭션을 사용할 수 있다. 트랜잭션은 애플리케이션이 더 단순해지기 위해 데이터베이스가 더 강력한 보장을 제공하는 방법이다.

다중 리더 복제

• 다중 리더 설정 (마스터 마스터, 액티브/액티브 복제) 리더 기반 복제 모델은 쓰기를 허용하는 노드를 하나 이상 두는 것으로 자연스레 확장된다. 복제는 여전히 같은 방식이며, 쓰기 처리를 하는 각 노드는 데이터 변경을 다른 모든 노드에 전달해야 한다. 각 리더는 동시에 다른 리더의 팔로워 역할도 한다.
  

다중 리더 복제의 사용 사례

단일 데이터센터 내에 다중 리더 설정을 사용하는 설정은 복잡도에 비해 이점이 크지 않다. 다음은 다중 리더 설정이 합리적인 사례이다.

다중 데이터센터 운영

다중 리더 설정에서는 각 데이터센터마다 리더가 있을 수 있다. 각 데이터센터 내에는 보통의 리더 팔로워 복제를 사용하고 데이터센터 간에는 각 데이터센터의 리더가 다른 데이터센터의 리더에게 변경 사항을 복제한다.

• 단일 리더 설정과 비교
  • 성능 단일 리더 설정에서 모든 쓰기는 인터넷을 통해 리더가 있는 데이터센터로 이동해야 한다. 다중 리더 설정에서 모든 쓰기는 로컬 데이터센터에서 처리한 다음 비동기 방식으로 다른 데이터센터에 복제한다. 성능이 더 좋다.
    
  • 데이터센터 중단 내성 다중 리더 설정에서는 각 데이터센터는 다른 데이터센터와 독립적으로 동작하고 고장 난 데이터센터가 온라인으로 돌아왔을 때 복제를 따라잡는다.
    
  • 네트워크 문제 내성 단일 리더 설정에서는 데이터센터 내 연결의 쓰기는 동기식이므로 데이터센터 내 연결 문제에 매우 민감하다. 다중 리더 설정에서는 비동기 복제를 사용하므로 네트워크 문제에 잘 견딘다.
    
• 단점 동일한 데이터를 다른 두 개의 데이터센터에서 동시에 변경할 수 있다. 이때의 쓰기 충돌은 반드시 해소해야 한다.
  

오프라인 작업을 하는 클라이언트

• 오프라인 작업 및 동기화가 필요한 애플리케이션에서 다중 리더 복제가 적절하다.
• 오프라인 상태에서 데이터를 변경하면 디바이스가 다음에 온라인 상태가 됐을 때 서버와 다른 디바이스를 동기화해야 한다.
• 모든 디바이스에는 리더처럼 동작하는 로컬 데이터베이스가 있다. 모든 디바이스 상에서 캘린더의 복제 서버 간 다중 리더 복제를 비동기 방식으로 수행하는 프로세스가 있다.

협업 편집

• 동시에 여러 사람이 문서를 편집할 수 있는 실시간 협업 편집 애플리케이션에서 다중 리더 복제가 적절하다.
• 협업 편집은 오프라인 편집 사용 사례와 공통점이 많다. 한 사용자가 문서를 편집할 때 변경 내용을 즉시 로컬 복제 서버에 적용하고 나서 동일한 문서를 편집하는 다른 사용자와 서버에 비동기 방식으로 복제한다.
  
• 더 빠른 협업을 위해 변경 단위를 매우 작게 하여 잠금을 피할 수 있다.

쓰기 충돌 다루기

동기 대 비동기 충돌 감지

이론적으로 충돌 감지는 동기식으로 만들 수 있다. 쓰기가 성공한 사실을 사용자에게 말하기 전에 모든 복제 서버가 쓰기를 복제하기를 기다린다. 하지만 이렇게 하면 다중 리더 복제의 주요 장점(각 복제 서버가 독립적으로 쓰기를 허용)을 잃는다.

충돌 회피

충돌을 처리하는 가장 간단한 전략은 충돌을 회피하는 것이며, 충돌을 처리하는 것이 어렵기 때문에 충돌을 피하는 것이 자주 권장된다.

일관된 상태 수렴

• 단일 리더 데이터베이스는 순차적인 순서로 쓰기를 적용한다. 마지막 쓰기가 필드의 최종 값으로 결정된다. 다중 리더 설정에서는 쓰기 순서가 정해지지 않아 최종값이 무엇인지 명확하지 않다.
  
• 모든 복제 계획은 모든 복제 서버가 최종적으로는 동일하다는 사실을 보장해야 한다. 데이터베이스는 수렴 방식으로 충돌을 해소한다. 이는 모든 변경이 복제돼 모든 복제 서버에 동일한 최종값이 전달되게 해야 한다는 의미다.
  • 수렴 충돌 해소를 달성하는 방법
    • 각 쓰기에 고유 ID를 부여하고 가장 높은 ID를 가진 쓰기를 고르고, 다른 쓰기는 버린다. 타임스탬프를 사용하는 경우를 최종 쓰기 승리라고 한다.
    • 각 복제 서버에 고유 ID를 부여하고 높은 숫자의 복제 서버에서 생긴 쓰기가 낮은 숫자의 복제 서버에서 생긴 쓰기보다 항상 우선 적용되게 한다.
    • 어떻게든 값을 병합한다.
    • 명시적 데이터 구조에 충돌을 기록해 모든 정보를 보존한다. 충돌을 해소하는 애플리케이션 코드를 작성한다.

사용자 정의 충돌 해소 로직

충돌 해소에 적합한 방법은 애플리케이션마다 다르다. 대부분의 다중 리더 복제 도구는 애플리케이션 코드를 사용하여 충돌을 해소한다. 충돌 해소 로직은 쓰기나 읽기 수행 중에 실행될 수 있다.

충돌 해소는 보통 트랜잭션이 아니라 개별 로우나 문서 수준에서 적용된다.

다중 리더 복제 토폴로지

복제 토폴로지는 쓰기를 한 노드에서 다른 노드로 전달하는 통신 경로를 의미한다.

• 전체 연결 가장 일반적인 토폴로지 이 토폴로지는 모든 리더가 각자의 쓰기를 다른 모든 리더에서 전송한다.
  
• 원형 토폴로지 MySQL은 원형 토폴로지만 제공한다. 각 노드가 하나의 노드로부터 쓰기를 받고, 이 쓰기를 다른 한 노드에 전달한다.
  
• 별 모양 토폴로지 지정된 루트 노드 하나가 다른 모든 노드에 쓰기를 전달한다.
  
• 장단점
  • 원형, 별 모양 토폴로지의 문제점은 하나의 노드에 장애가 발생하면 다른 노드 간 복제 메시지 흐름에 방해를 준다는 것이다. 메시지가 여러 경로를 따라 이동할 수 있으면 단일 장애점을 피할 수 있기 때문에 조금 더 빽빽한 연결 토폴로지의 내결함성이 훨씬 더 좋다.
  • 전체 연결 토폴로지의 단점은 일부 네트워크 연결이 다른 연결보다 빠르면 일부 복제 메시지가 다른 메시지를 추월할 수 있다. 이런 경우 이벤트를 올바르게 정렬해야 하는데, 여기에 버전 벡터라는 기법을 사용할 수 있다.
    

리더 없는 복제

리더의 개념을 버리고 모든 복제 서버가 클라이언트로부터 쓰기를 직접 받을 수 있게 허용하는 접근 방식이다.

다이나모 스타일이라고도 한다.

노드가 다운됐을 때 데이터베이스에 쓰기

복제 서버 중 하나를 사용할 수 없게 되었을 때, 리더 기반 설정에서 쓰기 처리를 계속 하려면 장애 복구를 해야 한다. 하지만 리더 없는 설정에서는 장애 복구가 필요하지 않다. 클라이언트가 쓰기를 모든 복제 서버에 병렬로 전송하고, 정족수 이상의 서버에서 쓰기를 확인하면 쓰기가 성공한 것으로 간주한다.

클라이언트가 쓰기가 실패한 노드에서 데이터를 읽는다면 응답으로 오래된 값을 얻을 수 있다. 이 문제를 해결하기 위해 클라이언트가 읽기 요청을 병렬로 여러 노드에 전송한다. 한 노드에서는 최신 값을 받고, 다른 노드에서는 오래된 값을 받는다면, 버전 숫자를 사용해 어떤 값이 최신 내용인지 결정한다.

읽기 복구와 안티 엔트로피

복제 계획은 최종적으로 모든 데이터가 모든 복제 서버에 복사된 것을 보장해야 한다. 이를 보장하기 위해 다이나모 스타일에서는 아래와 같은 메커니즘을 사용한다.

• 읽기 복구 클라이언트가 여러 노드에서 병렬로 읽기를 수행하면 오래된 응답을 감지할 수 있다. 오래된 값이라는 사실을 알고 해당 복제 서버에 새로운 값을 다시 기록한다.
  
• 안티 엔트로피 처리 백그라운드 프로세스를 두고 복제 서버 간 데이터 차이를 지속적으로 찾아 누락된 데이터를 하나의 복제 서버에서 다른 서버로 복사한다.
  

읽기와 쓰기를 위한 정족수

• n개의 복제 서버가 있을 때 모든 쓰기는 w개의 노드에서 성공해야 쓰기가 확정되고, 모든 읽기는 최소 r개의 노드에 질의해야 한다. w + r > n 이면 읽을 때 최신 값을 얻을 것으로 기대한다. 이런 r과 w를 따르는 읽기와 쓰기를 정족수 읽기와 쓰기라고 부른다.
• 일반적은 선택은 n을 홀수로 하고 w = r = (n + 1) / 2 로 설정한다.
• 정족수 조건이 w + r > n 이면 사용 불가능한 노드를 용인한다.
  • w < n 이면 노드 하나를 사용할 수 없어도 쓰기를 처리할 수 있다.
  • r < n 이면 노드 하나를 사용할 수 없어도 읽기를 처리할 수 있다.
  • 읽기와 쓰기는 항상 모든 n개의 복제 서버에 병렬로 전송한다. 파라미터 w, r은 얼마나 많은 노드를 기다릴지 결정한다.

정족수 일관성의 한계

• w + r > n이 되게끔 w, r을 선택한다면 일반적으로 모든 읽기는 키의 최신 값을 반환할 것을 기대한다. 이는 쓰기를 하는 노드셋과 읽기를 하는 노드셋이 겹치기 때문이다.
• w와 r이 작을수록 오래된 값을 읽을 확률이 높다. 최신 값을 가진 노드가 읽을 노드에 포함되지 않을 가능성이 높기 때문이다.
• w + r > n인 경우에도 오래된 값을 반환하는 엣지 케이스가 있다.
• 다이나모 스타일 데이터베이스는 일반적으로 최종적 일관성을 허용하는 사용 사례에 맞게 최적화됐다. 매개변수 w, r 로 오래된 값을 읽는 확률을 조정할 순 있지만, 이를 절대적으로 보장할 수는 없다.

최신성 모니터링

• 애플리케이션이 오래된 값 읽기를 허용하더라도 복제 상태에 대해 알아야 한다. 복제가 명확히 뒤처진다면 원인을 조사할 수 있어야 한다.
• 리더 기반 복제에서 데이터베이스는 일반적으로 복제 지연에 대한 지표를 노출한다.
• 리더 없는 복제 시스템에서는 쓰기가가 적용된 순서를 고정할 수 없어 모니터링이 조금 더 어렵다

느슨한 정족수와 암시된 핸드오프

• 정족수는 내결함성이 없다.
• 응답 가능한 노드가 w나 r보다 적을 가능성이 있으므로 클라이언트는 더 이상 정족수를 충족할 수 없다.
• 노드가 n개 이상인 대규모 클러스터에서 클라이언트는 네트워크 장애 상황에서 일부 데이터베이스 노드에 연결될 가능성이 있다. 이 경우 트레이드오프에 직면한다.
  • w나 r 노드 정족수를 만족하지 않는 모든 요청에 오류를 반환할까?
  • 일단 쓰기를 받아들이고 값이 보통 저장되는 n개 노드에 속하지 않지만 연결할 수 있는 노드에 기록할까? → 느슨한 정족수
• 느슨한 정족수 쓰기와 읽기는 여전히 w와 r의 성공 응답이 필요하지만, 값을 위해 지정된 n개의 홈 노드에 없는 노드가 포함될 수 있다.
  
• 암시된 핸드오프 네트워크 장애 상황이 해제되면 한 노드가 다른 노드를 위해 일시적으로 수용한 모든 쓰기를 해당 홈 노드로 전송한다.
  
• 느슨한 정족수는 쓰기 가용성을 높이는 데에 유용하다.
• 느슨한 정족수는 실제로 전통적인 의미의 정족수가 아니다. 단지 지속성에 대한 보장으로 데이터가 w 노드 어딘가에 저장된다는 뜻이다.

다중 데이터센터 운영

리더 없는 복제도 동시 쓰기 충돌, 네트워크 중단, 지연 시간 급증을 허용하므로 다중 데이터센터 운영에 적합하다.

동시 쓰기 감지

• 다이나모 스타일 데이터베이스는 여러 클라이언트가 동시에 같은 키에 쓰는 것을 허용하므로 엄격한 정족수를 사용하더라도 충돌이 발생한다. 문제는 이벤트가 다른 노드에 다른 순서로 도착할 수 있다는 것이다.
  
• 쓰기 충돌 해소를 위해 아래 방법들이 있다.
  • 최종 쓰기 승리 각 복제본이 가진 예전 값을 버리고 최신 값으로 덮어쓰는 방법
    
  • 이전 발생 관계와 동시성, 이전 발생 관계 파악하기 작업 B가 작업 A에 대해 알거나 A에 의존적이거나 어떤 방식으로든 A를 기반으로 한다면 작업 A는 작업 B의 이전 발생이다. 사실 작업이 다른 작업보다 먼저 발생하지 않으면 단순히 동시 작업이라 말한다. 나중 작업은 이전 작업을 덮어쓸 수 있지만 작업이 동시에 발생하면 충돌을 해소해야 한다.
    
  • 동시에 쓴 값 병합 어떤 데이터도 자동으로 삭제되지 않음을 보장하지만 불행히도 클라이언트가 추가적인 작업을 해야 한다. 여러 작업이 동시에 발생하면 클라이언트는 동시에 쓴 값을 합쳐 정리해야 한다. 추가 외에 제거도 할 수 있게 하려면 형제의 합집합만으로는 안된다. 제거할 때 데이터베이스에서 단순히 삭제하면 안된다. 그 대신 시스템은 형제를 병합할 때, 제거했음을 나타내기 위해 해당 버전 번호에 표시를 남겨둬야 한다.
    
  • 버전 벡터 다중 복제본이 있지만 리더가 없는 경우, 키당 버전 번호뿐만 아니라 복제본당 버전 번호도 사용해야 한다. 각 복제본은 쓰기를 처리할 때 자체 버전 번호를 증가시키고 각기 다른 복제본의 버전 번호도 계속 추적해야 한다. 모든 복제본의 버전 번호 모음을 버전 벡터라고 한다.