Oracle 데이터베이스 링크를 통해 로컬 데이터베이스의 레코드와 원격 데이터베이스의 레코드를 삽입하는 응용 프로그램 코드가 있습니다. 이 분산 트랜잭션을 커밋 할 때 로컬 데이터베이스와 원격 데이터베이스 모두 커밋되거나 롤백되는 것이 보장되거나 원격 커밋 할 수 있지만 로컬 커밋이 실패 할 가능성이 있습니다 (또는 그 반대)?커밋/롤백을 보장하는 분산 데이터베이스 트랜잭션이 있습니까?
오라클이 Two-Phase Commit (2PC) 프로토콜에 해당하는 것을 사용하지 않으면 나는 놀랐을 것입니다. 이것은 두 커밋 또는 두 롤백 모두를 보장합니다.
2PC에서는 마스터 (코디네이터) 인스턴스가 자신의 결정을 기록하고 모든 참가자에게 커밋 준비 (그리고 상태를보고 - 실패하거나 커밋 할 수 있음)를 알려주는 사전 커밋 단계가 있습니다. . 참가자는 또한 커밋 할 준비를하고 코디네이터에게 커밋 할 준비가되었음을 알린 후 코디네이터의 지시를 기다립니다. 모든 참가자가 응답 한 후 코디네이터는 최종 결정을 기록하고 참가자에게 결정을 보냅니다. 결정을 기록한 후에 마스터가 실패했지만 참가자에게 결정을 성공적으로 전송하기 전에 참가자는 커밋하거나 롤백 할 수없는 상태에서 중단 될 수 있습니다. 그것으로부터 회복 할 수있는 방법이 있습니다. 코디네이터가 충분히 오랫동안 (예를 들어, 치명적인 h/w 실패의 결과로 작동하지 않을 때) 오래 머물러 있다면 문제가 발생할 수 있습니다. 참가자들은 일반적으로 경험적 롤백 (추정 롤백)을 수행합니다. 그러나 이로 인해 문제가 발생하는 것은 놀라운 행운을 요구합니다.
2PC의 대안이 있습니다. 그물 결과는 동일합니다 - 모든 커밋 또는 모든 롤백.
분산 트랜잭션이 각 서버에 대해 독립적 인 트랜잭션과 동일한 역할을한다면 요점은 무엇입니까? (당신이 염려하고있는 커밋/롤백의 불일치를 허용) –
@Damien_The_Unbeliever : 나는 동의하지만, 모든 가능성을 어떻게 설명 할 수 있는지를 보지 못했습니다. Jonathan의 대답은 이해할 수 있습니다. 하나의 시스템에 심각한 실패가 발생해도 상황이 달라질 수있는 상황이 많지만 대다수의 상황이 처리되는 것처럼 보입니다. –
@Renderln - 트랜잭션 로그가있는 디스크에 치명적인 오류가 발생한 경우 실제로 트랜잭션을 복구 할 수없는 경우 커밋이 성공했다고 생각할 수 있습니다. 따라서 분산 트랜잭션을 호출하지 않아도 항상 엣지 케이스가 있습니다. –