내용 정정: “Aurora MariaDB”는 정확한 엔진 명칭이 아닙니다. Aurora MySQL과 RDS for MariaDB를 구분하고, 아래 설명은 InnoDB 트랜잭션을 전제로 읽어야 합니다. AWS Aurora 공식 소개.
Pod가 종료되면 즉시 롤백될까?
autocommit=false 자체가 Pod 종료 감지 기능은 아닙니다. DB가 연결 종료를 감지하면 해당 세션의 미커밋 트랜잭션은 롤백 대상이 됩니다. 이미 커밋된 청크와 별도 트랜잭션은 취소되지 않으며, 네트워크 단절 시에는 서버의 종료 감지가 늦어질 수 있습니다. 따라서 Pod가 사라진 시점과 DB의 롤백 완료·락 해제 시점을 분리해 관찰해야 합니다.
상황별로 확인할 차이
| 상황 | 점검할 내용 |
|---|---|
| 정상 종료 요청 | Spring 종료 처리, 진행 중 Step 상태, DB 세션 종료와 롤백 완료 |
| 프로세스 강제 종료 | 종료 훅 실행 여부를 기대하지 말고 DB 연결 종료 감지 확인 |
| 네트워크 단절 | DB가 세션을 살아 있다고 보는 시간과 TCP/드라이버 타임아웃 |
| Failover | 기존 연결 오류·새 연결 획득과 트랜잭션 재시도 경계 |
| Deadlock | 서버가 선택한 희생 트랜잭션의 오류 처리와 재시도; 단순 연결 단절과 구분 |
재현과 관찰 절차
비운영 환경에서 테스트 행을 수정하고 아직 커밋하지 않은 세션을 준비합니다. 정상 종료·강제 종료·네트워크 차단을 각각 독립적으로 실행하고, DB 세션·락 대기와 Batch 실행 상태를 관찰합니다. 종료 전 이미 커밋된 행과 미커밋 행을 나누어 비교하세요. 실제 엔진 버전, 종료 방식, 감지 시간과 롤백 시간을 함께 남겨야 결과를 재사용할 수 있습니다.
SELECT VERSION(), @@version_comment;
SHOW ENGINE INNODB STATUS;
애플리케이션의 재시작 기준
DB 연결 복구가 기존 트랜잭션의 이어 실행을 의미하지는 않습니다. 실패한 트랜잭션을 정리하고 새 연결에서 업무 단위로 재시도합니다. 배치 재시작 시 중복 반영을 방지하도록 식별 키와 커밋 경계를 확인하세요. wait_timeout을 낮추는 것만으로 실행 중인 모든 쿼리와 락을 즉시 해제할 수는 없습니다.
참고: MySQL COMMIT·ROLLBACK과 세션 종료. 본문의 점검 절차는 검증 계획이며 특정 운영 환경의 재현 결과를 주장하지 않습니다.
락 대기 제한과 전체 롤백의 차이는 Aurora MySQL·RDS MariaDB에서 락 대기 타임아웃과 트랜잭션 롤백 구분하기에서 이어집니다.
“Aurora MySQL·RDS MariaDB에서 Spring Batch 강제 종료 시 롤백 확인하기”의 하나의 댓글