VPN이 끊긴 후 SQL Server에서 Oracle로의 로드 복구
VPN이 끊기면 호출자는 Oracle의 commit이 완료되었는지 확신할 수 없다. 내구성 있는 배치 ID가 있으면 추출, 적용, 조정 질문에 하나씩 답할 수 있다.
VPN이 끊기면 데이터베이스 간 전송이 죽고, «다시 실행»은 복구 계획이 아니다. 소스 추출이 끝났을 수도, 대상이 이미 commit했을 수도, 아니면 응답이 돌아오는 길에 그냥 사라졌을 수도 있다. 이 세 상태는 서로 다른 조치를 요구하며, «오류»만 아는 클라이언트는 이를 구별할 수 없다.
해결책은 아키텍처에 있다: 모든 실행에 내구성 있는 배치 정체성을 부여하고, 클라이언트가 추측하게 두는 대신 데이터베이스가 질문에 답하게 하라.
데이터베이스가 실제로 보장하는 것
SQL Server와 Oracle 모두 트랜잭션 내부의 원자성을 제공하지만, 둘 사이의 원자성은 어느 쪽도 제공하지 않는다. 연결이 끊겨도 데이터베이스는 손상되지 않고 수동 롤백도 강제되지 않는다. 서버가 당신 없이 자기 트랜잭션을 해결하기 때문이다. 깨지는 것은 결과에 대한 호출자의 지식이다.
따로 commit했다는 것은 따로 commit했다는 뜻이다. 두 연결을 모두 나르는 VPN이 두 commit을 하나의 작업 단위로 합치지는 않는다.
당신이 들어본 적 없는 commit
한 가지 실패 모드는 순진한 재시도 로직을 벌한다: 서버는 commit하고, 확인 응답은 호출자에게 결코 도달하지 않는다. Oracle은 이를 알 수 없는 결과 문제로 문서화하고, 이를 위해 트랜잭션 문서에서 Transaction Guard를 제공한다. 통신 오류는 제출된 commit이 실패했다는 증거가 아니며, 그것을 증거로 다루는 것이 배치가 두 번 게시되는 경로다. 이 구분은 운영자에게 오류 메시지뿐이고 행동할 다른 신호가 없는 재시도 경로에서 가장 중요하다.
따라서 복구 단계는 오류 텍스트에서 추론하는 대신 대상에서 결과를 읽어야 한다.
전송에 배치 정체성을 부여하라
모든 실행은 불변의 배치 ID를 받고, 대상은 그 ID로 무엇을 했는지 기록한다: 수명 주기는 네 단계이며 공급업체와 무관하게 동일해 보인다.
- 추출 기록된 스키마와 경계를 가진, 식별된 불변의 소스 배치.
- 전송 대상의 스테이징 영역으로 옮기고, 준비 완료를 선언하기 전에 불완전하거나 충돌하는 내용을 감지한다.
- 적용 대상 자체의 고유성 또는 잠금 규칙에 따라 수행하고, 같은 로컬 트랜잭션에 완료를 기록한다.
- 조정 지원되는 프로토콜을 통해 확인 응답이나 재시도 전에 내구성 있는 결과를 확인한다.
재시도는 같은 ID를 재사용한다. 시도마다 새 ID를 만들면 방금 구축한 중복 방지가 무너지며, 이는 재시도 래퍼가 자동으로 ID를 생성하기 전까지는 자명해 보인다.
ID는 또한 클라이언트 프로세스가 사라진 훨씬 뒤에 조정할 대상도 제공한다.
배치를 확보한 다음 적용하라
적용 단계는 배치 ID를 확보하고, 비즈니스 변경을 수행하고, 완료를 하나의 로컬 트랜잭션에 기록해야 한다. 검사와 삽입을 별도 문으로 수행하면 제거하려던 경쟁이 다시 들어온다. 두 작업자가 경쟁하면 정확히 하나의 확보가 이기고 다른 하나는 그 사실을 통보받는다.
완료 기록이 없다고 해서 진행 중인 트랜잭션이 결코 commit하지 않는다는 증거는 아니다. 확보가 경쟁 시도를 직렬화해야 하거나, 프로토콜이 무엇이든 결정하기 전에 내구성 있는 결과를 읽어야 한다.
그 직렬화에는 애플리케이션 코드의 검사 후 반복 루프 대신 데이터베이스가 지원하는 메커니즘을 사용하라.
설계가 여전히 약속할 수 없는 것
스테이징은 작업을 재시작 가능하게 하고 하나의 장수 세션에 대한 의존을 줄인다. 그러나 SQL Server, Oracle 및 작업이 수행하는 모든 외부 부작용에 걸친 단일 원자적 commit을 만들지는 않는다. 비즈니스가 정말로 그것을 필요로 한다면 지원되는 분산 트랜잭션이나 조정 프로세스를 결과가 불확실한 작업의 소유자가 누구인지도 포함하여 설계하고 적격성을 확인하라. 그보다 약한 것은 전송 코드가 아니라 조정 런북에 속한다.
세 곳에서 중단을 받아들여라: 전송 중, 적용 중, 그리고 commit 후 확인 응답 전이다. 그런 다음 클라이언트의 메시지가 아니라 비즈니스 결과를 확인하고, 배치 원장이 작업이 미완료인지, commit되었는지, 아니면 아직 미해결인지 말하게 하라.