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

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

---

분산 트랜잭션에서 2 단계 커밋이 작동하는 방식을 연구하고 있습니다. 단계의 마지막 부분에서 트랜잭션 코디네이터가 각 노드에 커밋 할 준비가되었는지 묻습니다. 모두가 동의하면 계속해서 커밋하라고 말합니다.

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

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

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

---

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

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

---

모든 사람의 답변 요약 :

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

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

---

아니요. 포인트 4는 올바르지 않습니다. 각 노드는 트랜잭션을 커밋하거나 롤백 할 수 있었다는 것을 안정적인 스토리지에 기록하므로 충돌시에도 명령 된대로 수행 할 수 있습니다. 크래시 된 노드가 백업되면 커밋 전 상태의 트랜잭션이 있음을 인식하고 관련 잠금 또는 기타 제어를 복원 한 다음 코디네이터 사이트에 연락하여 트랜잭션 상태를 수집해야합니다.

문제는 충돌 한 노드가 백업되지 않는 경우에만 발생합니다 (그런 다음 다른 모든 사람들은 트랜잭션이 정상이라고 생각하거나 충돌 한 노드가 다시 돌아올 때 발생합니다).

---

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

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

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

---

2 단계 커밋 문제를 공격하는 방법에는 여러 가지가 있습니다. 거의 모두 Paxos 3 단계 커밋 알고리즘의 변형으로 나타납니다. Paxos를 기반으로하는 Google에서 Chubby 잠금 서비스를 설계 한 Mike Burrows는 내가 본 강의에서 두 가지 유형의 분산 커밋 알고리즘 인 "Paxos와 잘못된 알고리즘"이 있다고 말했습니다.

충돌 한 노드가 다시 깨어날 때 할 수있는 한 가지는 "이 트랜잭션에 대해 들어 본 적이 없습니다. 커밋 되었어야하나요?"라고 말하는 것입니다. 코디네이터에게 전달하면 투표 내용을 알 수 있습니다.

이것은보다 일반적인 문제의 예입니다. 고장난 노드는 복구되기 전에 많은 트랜잭션을 놓칠 수 있습니다. 따라서 복구시 코디네이터 또는 다른 복제본과 대화 한 후에 자체를 사용할 수있게 만드는 것이 매우 중요합니다. 노드 자체가 충돌 여부를 알 수 없으면 상황이 더 복잡해 지지만 여전히 다루기 쉽습니다.

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

참고 URL : https://stackoverflow.com/questions/171876/how-do-two-phase-commits-prevent-last-second-failure