2 단계 커밋은 어떻게 마지막 초 실패를 방지합니까?

Question

분산 거래에서 2 단계 커밋이 어떻게 작동하는지 연구하고 있습니다. 단계의 마지막 부분에서 트랜잭션 코디네이터는 각 노드에게 커밋 준비가되었는지 여부를 묻습니다. 모든 사람이 동의한다면, 그들은 계속해서 커밋하라고 말합니다.

다음과 같은 실패를 방지하는 것은 무엇입니까?

1. 모든 노드는 커밋 할 준비가되었다고 응답합니다
2. 트랜잭션 코디네이터는 그들에게 "계속 커밋하고 커밋"하도록 지시하지만이 메시지를 받기 전에 노드 중 하나가 충돌합니다.
3. 다른 모든 노드는 성공적으로 커밋되지만 이제는 분산 트랜잭션이 손상되었습니다.
4. 충돌 노드가 다시 오면 트랜잭션이 다시 롤백되었을 것이라는 것은 내 이해입니다 (커밋 메시지를받지 못했기 때문에).

각 노드가 분산 트랜잭션에 대해 아무것도 모르는 일반적인 데이터베이스를 실행하고 있다고 가정합니다. 내가 놓친 게 무엇입니까?

Answer 1

모든 사람의 답변 요약 :

1. 분산 트랜잭션과 함께 일반 데이터베이스를 사용할 수 없습니다. 데이터베이스는 트랜잭션 코디네이터를 명시 적으로 지원해야합니다.

2. 일부 노드 중 일부가 이미 커밋 되었기 때문에 노드는 롤백을 지시받지 않습니다. 충돌 노드가 다시 오면 트랜잭션 코디네이터가 커밋을 완료하도록 지시합니다.

Answer 2

아니요, 원래 포스터의 시나리오에서 일부 노드 중 일부가 이미 커밋 되었기 때문에 롤백을 지시받지 않습니다. 충돌 노드를 사용할 수있게되면 트랜잭션 코디네이터는 다시 커밋하라고 지시합니다.

노드는 "준비"단계에서 긍정적으로 응답했기 때문에 충돌로 돌아올 때에도 "커밋"할 수 있어야합니다.

Answer 3

번호 4가 틀 렸습니다. 각 노드는 안정적인 스토리지의 기록을 기록하여 트랜잭션을 커밋하거나 롤백 할 수있게하여 충돌 전반에도 명령을 내릴 수 있도록합니다. 충돌 노드가 다시 등장하면 사전 커밋 상태에 트랜잭션이 있고 관련 잠금 또는 기타 컨트롤을 복원 한 다음 코디네이터 사이트에 연락하여 트랜잭션 상태를 수집하려고 시도합니다.

충돌 노드가 다시 등장하지 않는 경우에만 문제가 발생합니다 (그런 다음 다른 모든 것은 트랜잭션이 정상이라고 생각하거나 충돌 된 노드가 다시 오면됩니다).

Answer 4

2 단계 커밋은 완벽하지 않으며 시간의 99%에서 작동하도록 설계되었습니다.

"프로토콜은 쓰기 로그로 쓰기 로그를 사용하여 각 노드에 안정적인 스토리지가 있다고 가정하고, 노드가 영원히 충돌하지 않으며, 쓰기 로그의 데이터가 충돌로 손실되거나 손상되지 않으며 두 노드가 통신 할 수 있다고 가정합니다. 서로 서로 함께."

http://en.wikipedia.org/wiki/two-phase_commit_protocol

Answer 5

2 단계 커밋으로 문제를 공격하는 방법에는 여러 가지가 있습니다. 거의 모든 사람들이 Paxos 3 상 커밋 알고리즘의 일부 변형으로 시작됩니다. Paxos를 기반으로하는 Google에서 통통한 잠금 서비스를 설계 한 Mike Burrows는 내가 본 강의에서 두 가지 유형의 분산 커밋 알고리즘 "Paxos 및 잘못된 것" -이 있다고 말했다.

추락 된 노드가 다시 흔들릴 때 할 수있는 한 가지는 "이 거래에 대해 들어 본 적이 없다. 코디네이터에게 투표가 무엇인지 알려줄 것입니다.

이것은 더 일반적인 문제의 예입니다. 충돌 노드는 복구하기 전에 많은 트랜잭션을 놓칠 수 있습니다. 따라서 회복시 코디네이터 나 다른 복제본과 대화 해야하는 것이 매우 중요합니다. 노드 자체가 충돌했는지 여부를 알 수 없다면 상황이 더 관여하지만 여전히 다루기 쉬운 것입니다.

데이터베이스 읽기에 쿼럼 시스템을 사용하는 경우 불일치가 마스크되어 데이터베이스 자체에 알려져 있습니다.