🎇 트러블 슈팅

RDB & MongoDB 트랜잭션 분리 처리

문제 상황

문서를 삭제할 때, RDB(MySQL)과 MongoDB에 분산된 데이터가 함께 삭제되어야 한다. 하지만 두 데이터베이스 간에 단일 트랜잭션을 묶는 것은 불가능하며(하나의 @Transactional로 처리 X), 처리 순서나 실패 복구를 잘 설계하지 않으면 두 데이터베이스간 불일치가 발생할 수 있다.

현재 구조:

db	저장 내용
RDB(JPA 기반)	Doc, Branch, Edge와 Save, Commit의 메타데이터 (제목, 설명, 생성/수정 일자 etc)
MongoDB	SaveContent, Block, CommitsBlockSequence (Save와 Commit의 본문, Commit의 블록 리스트)

저장 트랜잭션 설계

저장의 경우 다음과 같은 위험이 발생할 수 있다:

• Mongo 먼저 저장 → 이후 RDB 실패: Mongo에 쓰레기 데이터 남음
• RDB 먼저 저장 → 이후 Mongo 실패: RDB에 내용이 없는 저장이 생김

이를 해결하기 위해 다음과 같은 저장 로직을 고안하였다:

✔ MongoDB 저장 후 → 성공 시 ID를 받아 → RDB에 저장

예시 프로세스: RDB의 @Transactional 안에서 다음 처리 실행

try {
    1. [RDB] MongoID를 제외한 Save 메타데이터를 우선 RDB에 저장

    2. [MongoDB] SaveContent를 MongoDB에 저장 → saveContentId 반환

    3. [RDB] 반환받은 saveContentId를 기존 Save(RDB)에 업데이트

    4. 최종적으로 모든 저장 성공 → 트랜잭션 커밋

} catch (예외 발생 시) {
    - [MongoDB 수동 롤백] 실패한 Mongo 저장 내용 직접 삭제 (saveContentId 등)
    - 예외 종류에 따라 적절한 CustomException 발생 후 
    - 전체 트랜잭션 롤백
}

삭제 트랜잭션 설계

삭제의 경우 다음과 같은 위험이 발생할 수 있다:

• Mongo 삭제 중 예외 → RDB는 이미 삭제 완료 상태 → 롤백 불가로 데이터 정합성 깨짐

• 반대로 Mongo는 삭제됐는데 RDB 트랜잭션이 롤백된다면 → MongoDB에 고아 데이터 발생

삭제는 저장과 달리 RDB만 먼저 삭제되고 MpongoDB에 고아 데이터가 남더라도 UX 관점에서 문제가 없으므로, Mongo 삭제를 RDB 트랜잭션 이후로 분리한다.

이를 해결하기 위해 다음과 같은 삭제 로직을 고안하였다:

✔ 이벤트 기반 처리 + 트랜잭션 분리 + 재시도 + 비동기

1. RDB 삭제

• Doc, Branch, Commit, Save 등(RDB)은 하나의 @Transactional 내에서 삭제
• 동시에 삭제해야할 Mongo 관련 ID를 수집하여 DocDeleteMongoIdsDto에 담고
• eventPublisher.publishEvent()로 삭제 이벤트 발행

2. MongoDB 삭제

• @TransactionalEventListener(phase = AFTER_COMMIT)를 통해 RDB 트랜잭션이 성공적으로 커밋된 후에만 Mongo 삭제를 시도
• @Retryable은 AOP 기반으로 프록시를 통해 호출돼야 작동하기 때문에 이벤트리스너에서 직접 삭제하지 않음 (리스너에서 직접 호출 시 동작 안 함)

3. Mongo 삭제: 재시도

• MongoDB는 Atlas 기준 기본적으로 Replica Set을 지원하므로, 트랜잭션 사용이 가능함
• MongoTransactionManager를 @Bean으로 등록해 트랜잭션 분리

4. 삭제 실패 → @Recover 진입

• 삭제가 3회 모두 실패하면 @Recover 메서드로 이동
• 이 시점에는 트랜잭션 컨텍스트가 종료되어 있으므로, 직접 RDB 저장 시도 시 예외 발생 (no transaction is in progress)
• @Async 로 위임하여 트랜잭션을 새로 생성하고 Mongo 삭제 실패 내역(MongoDeleteFailure)을 저장

5. Mongo 삭제 실패 기록 저장

• @Async + @Transactional 조합으로 새 트랜잭션 컨텍스트를 생성하여 RDB에 Mongo 삭제 실패 내역 저장

6. 실패 내역 재시도: 스케줄러 기반

• 일정 주기(1시간?)로 MongoDeleteFailure 내역 조회
• 삭제 성공 시 resolved = true로 soft delete 처리