2상 커밋 프로토콜

Two-phase commit protocol

트랜잭션 처리, 데이터베이스, 컴퓨터 네트워킹에서 2상 커밋 프로토콜(2PC)은 원자약정 프로토콜(ACP)의 일종이다. 분산 원자성 거래에 참여하는 모든 프로세스를 거래 커밋 또는 중단(롤백) 여부에 대해 조정하는 분산 알고리즘이다. 이 프로토콜(전문화된 형태의 합의 프로토콜)은 일시적 시스템 장애(프로세스, 네트워크 노드, 통신 장애 등 어느 한쪽에서든 발생)가 많은 경우에도 그 목표를 달성하여 널리 사용되고 있다.[1][2][3] 그러나 가능한 모든 고장 구성에 탄력적이지 않으며, 드물지만 결과를 개선하기 위해 수동 개입이 필요하다. 장애로부터의 복구를 수용하기 위해(대부분의 경우 자동으로) 프로토콜의 참가자는 프로토콜의 상태 로깅을 사용한다. 로그 레코드는 일반적으로 생성 속도는 느리지만 실패에서 살아남는 것으로 프로토콜의 복구 절차에 의해 사용된다. 로깅 전략과 복구 메커니즘에서 주로 다른 많은 프로토콜 변형들이 존재한다. 일반적으로 간헐적으로 사용되도록 의도되었지만, 프로토콜에 의해 고려되고 지원될 수 있는 많은 가능한 고장 시나리오 때문에 복구 절차는 프로토콜의 상당 부분을 구성한다.

단일 분산 트랜잭션의 "정상 실행"에서(즉, 일반적으로 가장 빈번한 상황인 장애가 발생하지 않을 때), 프로토콜은 다음 두 단계로 구성된다.

  1. 커밋 요청 단계(또는 투표 단계) - 코디네이터 프로세스가 트랜잭션을 커밋하거나 중단하는 데 필요한 단계를 수행하고 "예" 중 하나를 투표하기 위해 모든 트랜잭션 참여 프로세스(이름된 참가자, 코호트 또는 근로자)를 준비하려고 시도하는 단계: 커밋(거래 참여자의 로컬 부분 실행인 경우)가 올바르게 종료됨), 또는 "아니오": 중단(로컬 부분에서 문제가 감지된 경우) 및
  2. 참가자의 투표에 기초해 코디네이터가 커밋 여부를 결정하고(모두 "예"를 투표한 경우에만), 거래를 취소(그렇지 않으면)하고, 그 결과를 모든 참가자에게 통지하는 커밋 단계. 그런 다음 참여자는 로컬 트랜잭션 리소스(예: 복구 가능한 리소스(예: 데이터베이스 데이터)와 트랜잭션의 다른 출력물(해당되는 경우)에서 각각의 부분을 사용하여 필요한 조치(커밋 또는 중단)를 수행한다.

2상 커밋(2단계 커미트)프로토콜은 동시성 프로토콜과 혼동해서는안 된다 프로토콜인 2상 잠금(2PL)제어.

가정

프로토콜은 다음과 같은 방식으로 동작한다. 한 노드는 마스터 사이트인 지정 코디네이터로, 나머지 네트워크 노드는 참가자로 지정된다. 프로토콜은 각 노드에 쓰기-어헤드 로그가 있는 안정적인 스토리지가 있고, 노드가 영구적으로 충돌하지 않으며, 쓰기-어헤드 로그의 데이터가 충돌로 손실되거나 손상되지 않으며, 어떤 두 노드가 서로 통신할 수 있다고 가정한다. 네트워크 통신은 일반적으로 다시 라우팅될 수 있기 때문에 마지막 가정은 너무 제한적이지 않다. 처음 두 가정은 훨씬 더 강력하다. 만약 노드가 완전히 파괴되면 데이터가 손실될 수 있다.

프로토콜은 거래의 마지막 단계에 도달한 후에 코디네이터에 의해 개시된다. 그런 다음 참가자들은 참여자로부터 거래가 성공적으로 처리되었는지 여부에 따라 합의문이나 중단문자로 응답한다.

기본 알고리즘

요청(또는 투표) 단계 커밋

  1. 코디네이터는 모든 참가자에게 메시지를 커밋하기 위해 쿼리를 보내고 모든 참가자들로부터 회신을 받을 때까지 기다린다.
  2. 참여자는 커밋을 요청받을 때까지 거래를 수행한다. 그들은 각각 실행 취소 로그에 항목을 쓰고 재실행 로그에 항목을 쓴다.
  3. 각 참가자는 참가자의 행동이 성공했을 경우 동의 메시지(참가자 표는 예스, 커밋하지 않을 경우 취소자 표)로 회신뢰할 수 없는 실패를 경험할 경우, 취소 메시지(참가자는 커밋에 예, 커밋하지 않음)로 응답한다.

커밋(또는 완료) 단계

성공.

커밋 요청 단계에서 코디네이터가 모든 참가자로부터 동의 메시지를 받은 경우:

  1. 코디네이터는 모든 참가자에게 커밋 메시지를 보낸다.
  2. 각 참가자는 작업을 완료하고, 거래 중에 보유하고 있는 모든 잠금장치와 자원을 해제한다.
  3. 각 참가자는 코디네이터에게 확인서를 보낸다.
  4. 코디네이터는 모든 승인을 받으면 거래를 완료한다.

실패

커밋 요청 단계(또는 코디네이터의 시간 초과 만료) 중에 참가자가 No를 투표하는 경우:

  1. 코디네이터가 모든 참가자에게 롤백 메시지를 보낸다.
  2. 각 참여자는 실행 취소 로그를 사용하여 트랜잭션을 실행 취소하고, 트랜잭션 중에 보유하고 있는 리소스와 잠금을 해제한다.
  3. 각 참가자는 코디네이터에게 확인서를 보낸다.
  4. 모든 승인이 접수되면 코디네이터가 거래를 취소한다.

메시지 흐름

Coordinator                                          Participant                              QUERY TO COMMIT                  -------------------------------->                              VOTE YES/NO             prepare*/abort*                  <------------------------------- commit*/abort*               COMMIT/ROLLBACK                  --------------------------------------------------------------------------- 인정 커밋*/abort* <------------------끝 

레코드 유형 옆의 *는 레코드가 안정적인 저장으로 강제된다는 것을 의미한다.[4]

단점들

2상 커밋 프로토콜의 가장 큰 단점은 차단 프로토콜이라는 점이다. 코디네이터가 영구적으로 실패하면 일부 참가자는 트랜잭션을 해결하지 못한다. 참가자가 코디네이터에게 합의 메시지를 보낸 후에는 커밋 또는 롤백을 수신할 때까지 차단한다.

2상 커밋 프로토콜 구현

공통 아키텍처

많은 경우에 2PC 프로토콜은 컴퓨터 네트워크에서 배포된다. 각 트랜잭션(예: The Open GroupX/Open XA)에 대해 프로토콜의 실행을 실시하는, 통상적으로 지명되는 Transaction manager(TM, 2PC 에이전트 또는 Transaction Processing Monitors라고도 한다)라고 하는, 서로 유사한 복수의 전용 2PC 컴포넌트를 구현해, 쉽게 배포된다. 분산 트랜잭션과 관련된 데이터베이스, 즉 참여자와 코디네이터 모두 2PC를 사용하여 해당 트랜잭션을 종료하기 위해 TM(일반적으로 참여자와 동일한 각 네트워크 노드에 있음)에 등록한다. 각 분산 거래에는 거래 참여자가 등록하는 TM의 임시 집합이 있다. 거래마다 리더인 코디네이터 TM이 존재하여 2PC, 일반적으로 코디네이터 데이터베이스의 TM을 조정한다. 단, 코디네이터 역할은 성능이나 신뢰성 등의 이유로 다른 TM으로 이관할 수 있다. 참가자는 2PC 메시지를 서로 교환하기보다는 각자의 TM과 메시지를 교환한다. 관련 기술책임자는 상기 2PC 프로토콜 스키마를 실행하기 위해 서로 의사소통하며, 해당 거래를 종료하기 위해 각 참여자를 "표현"한다. 이 아키텍처를 통해 프로토콜은 완전히 분산되고(중앙 처리 구성요소나 데이터 구조가 필요 없음), 네트워크 노드 수(네트워크 크기)에 따라 효과적으로 확장된다.

이러한 공통 아키텍처는 모든 그러한 프로토콜들이 프로토콜 참여자들에게 동일한 투표 메커니즘과 결과 전파를 사용하기 때문에 2PC 이외의 다른 원자력 약속 프로토콜의 배포에도 효과적이다.[1][2]

프로토콜 최적화

데이터베이스 연구는 특정 시스템의 행동 가정 하에서 프로토콜 최적화[1][2][3] 및 프로토콜 운영 절약을 통해 비용을 절감하면서 2상 커밋 프로토콜의 이점을 대부분 얻는 방법에 대해 수행되었다.

추정 중단 및 추정 커밋

추정 중단 또는 추정 커밋은 그러한 최적화에 공통적이다.[2][3][5] 커밋 또는 중단되는 트랜잭션의 결과에 대한 가정은 2PC 프로토콜의 실행 중에 참가자에 의한 메시지와 로깅 작업을 모두 저장할 수 있다. 예를 들어, 중단으로 추정될 때, 시스템 복구 중에 복구 절차에 의해 어떤 거래의 커밋에 대한 기록된 증거가 발견되지 않으면, 그 거래는 중단되었다고 가정하고 그에 따라 행동한다. 즉, 중단이 기록되더라도 전혀 문제가 되지 않으며, 이러한 가정 하에서 그러한 로깅을 저장할 수 있다. 일반적으로 추가 운영의 벌금은 최적화 유형에 따라 실패로부터 복구하는 동안 지불된다. 따라서 최적화의 최선의 변형은, 만일 있다면, 실패와 거래 결과 통계에 따라 선택된다.

트리 2상 커밋 프로토콜

Tree 2PC 프로토콜[2](내포된 2PC 또는 재귀적 2PC라고도 함)은 컴퓨터 네트워크에서 2PC의 일반적인 변종으로서, 기반 통신 인프라를 더 잘 활용한다. 분산 트랜잭션의 참여자는 일반적으로 트리 구조, 호출 트리를 정의하는 순서로 호출되며, 여기서 참여자는 노드, 가장자리는 호출(통신 링크)이다. 2PC 프로토콜에 의한 거래를 완료하기 위해서는 일반적으로 같은 트리가 활용되지만, 이를 위해 다른 통신 트리도 원칙적으로 활용할 수 있다. 트리 2PC에서 코디네이터는 통신 트리(반전 트리)의 루트("상단")로 간주되는 반면, 참가자는 다른 노드들이다. 코디네이터는 트랜잭션을 발생시킨 노드(다른 참가자를 재귀적으로(전환적으로))가 될 수 있지만, 같은 트리의 다른 노드가 코디네이터 역할을 대신 맡을 수 있다. 코디네이터의 2PC 메시지는 트리 "아래"로 전파되는 반면, 코디네이터에게 보내는 메시지는 모든 참가자에 의해 "수집"된다. 그 아래의 참가자는 트리를 "위로"라는 적절한 메시지를 보내기 전에 (중단 메시지를 제외하고, 메시지를 수신하거나 현재 참가자가 중단을 시작하는 경우 즉시 "위로" 전파된다.)

동적 2상 커밋(Dynamic 2상 커밋, D2PC) 프로토콜은[2][6] 미리 정해진 코디네이터가 없는 트리 2PC의 변형이다. 그것은 이전에 제안된 몇 가지 최적화를 약화시킨다. 합의 메시지(예스 표)는 트랜잭션을 대신하여 작업을 완료할 때 각 리프에서 모든 잎에서 전파되기 시작한다(준비됨). 중간(비 리프) 노드는 합의 메시지가 아직 수신되지 않은 마지막(단일) 인접 노드로 합의 메시지가 전송될 때 준비 상태를 보낸다. 코디네이터는 그들이 충돌하는 장소에서 거래 트리를 통해 계약 메시지를 경마함으로써 역동적으로 결정된다. 이들은 트랜잭션 트리 노드, 코디네이터 또는 트리 가장자리에서 충돌한다. 후자의 경우, 두 에지의 노드 중 하나를 코디네이터(모든 노드)로 선택한다. D2PC는 시간 최적이다(특정 트랜잭션 트리의 모든 인스턴스 및 특정 트리 2PC 프로토콜 구현 중, 모든 인스턴스는 트리가 동일하며, 각 인스턴스는 코디네이터로서 서로 다른 노드를 가진다). 최적의 코디네이터 D2PC를 선택함으로써 가능한 최소 시간 내에 코디네이터와 각 참가자를 커밋하여 각 거래 참여자(트리 노드)에서 잠근 자원의 가장 빠른 해제를 가능하게 한다.

참고 항목

참조

  1. ^ a b c 필립 A. 번스타인, 바소스 하질라코스, 네이선 굿맨(1987년): 데이터베이스 시스템동시성 제어 복구, 7장 애디슨 웨슬리 출판사, ISBN0-201-10715-5
  2. ^ a b c d e f Gerhard Weikum, Gottfried Vossen(2001): 트랜잭션 정보 시스템, 19장, Exvier, ISBN 1-55860-508-8
  3. ^ a b c 필립 A. 번스타인, 에릭 신참(2009년): 트랜잭션 처리 원리, 제2판 2010-08-07년 웨이백 머신보관, 제8장 모건 카우프만(Elsevier), ISBN 978-1-55860-623-4
  4. ^ C. 모한, 브루스 린제이와 R. Obermarck(1986) : "R* 분산 데이터베이스 관리 시스템의 트랜잭션 관리",데이터베이스 시스템(TODS), 제11권 제4호 1986년 12월, 페이지 378 - 396
  5. ^ C. Mohan, Bruce Lindsay(1985): "분산 트랜잭션의 프로세스 모델 트리에 대한 효율적인 프로토콜 커밋",ACM SIGOPS 운영 체제 검토, 19(2),pp. 40-52(1985년 4월)
  6. ^ Yoav Raz(1995) : "동적 2상 약속(D2PC) 프로토콜 ",데이터베이스 이론 ICDT '95, 컴퓨터 과학 강의 노트, 893/1995, 페이지 162-176, 스프링거, ISBN 978-3-540-58907-5