MSSQL - Peer-to-Peer Replication Architecture

개요

MSSQL - Peer-to-Peer는 모든 노드가 동등한 권한을 가진 상태에서 데이터를 서로 복제하고 동기화하는 구조이다. 데이터베이스의 고가용성과 확장성을 향상시키는데 주로 사용되며, 각 노드가 데이터를 동시에 읽고 쓸 수 있다.

핵심 기능

• 카탈로그 쿼리 및 기타 읽기는 여러 노드에 분산 → 읽기가 증가함에 따라 성능이 일관성을 유지할 수 있다.
• 시스템의 노드 중 하나가 실패하면 애플리케이션 계층이 해당 노드에 대한 쓰기를 다른 노드로 리디렉션 가능 → 가용성이 유지
• 노드를 유지 관리해야 하거나 전체 시스템을 업그레이드해야 하는 경우 애플리케이션의 가용성에 영향을 주지 않는다 → 각 노드를 오프라인 상태로 만들었다가 다시 시스템에 추가할 수 있다.
• 동등한 권한의 노드들: 모든 노드는 동등한 권한을 가지며, 데이터의 변경 작업을 수행할 수 있다. 각 노드는 독립적으로 작동하며, 데이터의 변경을 자체적으로 관리한다.
• 변경사항의 복제: 노드에서 데이터 변경이 발생하면, 이 변경사항은 다른 모든 노드에 복제된다. 각 노드는 독립적으로 트랜잭션을 수행하고 결과를 다른 노드에 전파한다.
• 데이터의 동기화: 모든 노드는 변경사항을 실시간으로 수신하고 적용함으로써 데이터를 동기화한다. 이를 통해 모든 노드가 항상 최신의 데이터를 유지할 수 있다.

 

사용 예시

참여하는 데이터베이스가 두 개인 토폴로지

왼쪽 그림 설명

• 예를 들어 데이터베이스에 제품 카탈로그가 포함된 경우 사용자 지정 애플리케이션을 지정
• A-M으로 시작하는 제품 이름에 대해서는 노드 A 로 업데이트를 전송
• N-Z로 시작하는 제품 이름에 대해서는 노드 B로 업데이트를 전송
• 이후 업데이트가 노드 간에 상호 복제

오른쪽 그림 설명

• 모든 업데이트가 노드 B로 전달
• 업데이트는 노드 A에 복제
• B가 오프라인(예: 유지 관리)인 경우 애플리케이션 서버는 모든 작업을 A로 보낼 수 있다.
• B가 다시 온라인 상태가 되면 업데이트가 다시 B에 전달될 수 있게 된다.
• 애플리케이션 서버는 모든 업데이트를 B로 다시 이동하거나 A로 계속 보낼 수 있다.

3개 이상의 참여 데이터베이스가 있는 토폴로지

• 위 그림은 토폴로지는 시간별로 분할.
• 현재 업무를 진행 중인 노드에서만 업데이트가 발생하며 이후 다른 참여 데이터베이스로 업데이트 내용이 이동
  • 로스앤젤레스, 런던 및 타이베이에 지사를 둔다고 가정.
  • 세 사무실의 표준 시간대는 8시간 간격으로 근무일에는 겹치지 않음.
  • 한 사무실이 문을 닫을 때 통화가 계속 진행 중인 경우 다음 사무실의 담당자에게 전화를 전달.
• 위 토폴로지의 이점
  • 격리 없이 독립성: 데이터를 독립적으로 삽입, 업데이트 또는 삭제가능 && 다른 모든 참여 데이터베이스에 복제 → 데이터 공유 가능
  • 오류가 발생하거나 하나 이상의 참여하는 데이터베이스에서 유지 관리를 허용하는 경우 가용성이 높아짐

3노드 토폴로지에 노드를 추가

• 유지 관리를 지원하거나 내결함성을 높이기 위해 더 높은 가용성을 제공
• 다른 지사가 개설되는 경우
• 디스크 오류 또는 기타 주요 오류가 발생하는 경우

특징

• 장점
  • 고가용성과 확장성
  • 하나의 노드에 문제가 발생하더라도 다른 노드에서 데이터를 계속 처리할 수 있다.
  • 필요에 따라 노드를 추가하거나 제거 → 시스템의 확장성을 유연하게 관리.
• 단점
  • 데이터의 동기화와 복제시 충돌 가능성
  • 데이터의 변경사항이 실시간으로 모든 노드에 적용되도록 관리필요.
  • 복제 과정에서의 충돌 처리를 위한 복잡한 로직이 필요.
  • 복제를 위해 많은 네트워크 리소스를 사용 → 네트워크 지연이나 병목현상 발생 가능성

충돌

• 행이 둘 이상의 노드에서 수정되면 행이 다른 노드로 전파될 때 충돌 또는 업데이트 손실이 발생할 수 있다.
• 피어 투 피어 토폴로지에서 충돌 검색을 사용하도록 설정하는 옵션을 제공.
  • 일관되지 않은 애플리케이션 동작 및 업데이트 손실을 포함하여 검색되지 않은 충돌로 인해 발생하는 문제를 방지
  • 기본적으로 충돌하는 변경 내용이 배포 에이전트의 오류를 유발하는 심각한 오류로 처리.
  • 충돌이 발생할 경우 충돌이 해결되고 토폴로지 전체에서 데이터가 일관될 때까지 일관성 없는 상태로 유지.
• SQL Server 2019(15.x) CU 13부터 가장 최근의 삽입 또는 업데이트가 충돌을 해결하도록 허용 → 자동으로 충돌을 해결하도록 피어 투 피어 복제를 구성할 수 있다
  • [ @p2p_conflictdetection = ] 'p2p_conflictdetection' : 피어 투 피어 복제를 설정한 경우 배포 에이전트 충돌을 검색할 수 있도록 한다. 기본값 : TRUE
  • [ @p2p_continue_onconflict = ] 'p2p_continue_onconflict' : 충돌이 감지된 후에도 배포 에이전트 변경 내용을 계속 처리할지 여부를 결정. 기본값 : FALSE
  • [ @p2p_conflictdetection_policy = ] 'originatorid' | 'lastwriter'
    • p2p_continue_onconflict = 'true' 인 경우 해당.
    • originatorid (기본값) 충돌 감지시 → 생성자 ID에 따라 승자를 결정. 그렇지 않으면 오류 발생
    • lastwriter 충돌 감지시 → 마지막 기록기의 날짜/시간에 따라 승자를 결정. 그렇지 않으면 오류 발생

참고 문헌

피어 투 피어 트랜잭션 복제 - SQL Server

Peer to peer replication

https://youtu.be/lqYyYaJp9Wk?si=nsjm1qw3TZ7tBIFu