정산 유니크 제약 누락으로 중복 적재되던 문제 수정
목차
dump.rdb 가 또 올라왔음
로컬에서 캐시 띄워놓고 작업하다 보면 워킹 디렉토리에 dump.rdb 가 슬쩍 생김. 평소엔 잘 피해다녔는데 다른 변경이랑 같이 add 되면서 한번 커밋에 따라 들어간 적이 있었음. 수십 MB 바이너리가 히스토리에 박히면 클론할 때마다 짜증나고, 무엇보다 캐시 스냅샷에 뭐가 들었는지 모르니 보안적으로도 찜찜함.
그래서 이번에 gitignore 에 못박았음.
# 로컬 캐시 스냅샷
dump.rdb
*.rdb
*.rdb 까지 같이 넣은 건 다른 모듈에서 파일명 살짝 바꿔서 떨어뜨리는 경우도 있어서. 한 번에 다 막아두는 편이 마음 편함.
진짜 본론은 정산 UK
이커머스 정산을 일별로 집계하면서 같은 파트너의 같은 일자 레코드가 두 번 들어가는 케이스가 운영에서 잡힘. 원인 추적해보니 유니크 제약이 파트너 식별자 하나만 걸려 있고 정산일자 컬럼이 빠져 있었음. 월마감 직전 재집계 잡이 동시에 두 번 돌면서 정확히 터짐.
| 항목 | 변경 전 | 변경 후 |
|---|---|---|
| UK 구성 | 파트너 식별자 단일 | 파트너 식별자 + 정산일자 |
| 중복 적재 | 애플리케이션 분기에 의존 | DB 레벨 차단 |
| 재집계 잡 | 덮어쓰기 실패 가능 | upsert 안전 |
ALTER 문은 별도 파일로 떼고 날짜를 파일명에 박아둠. 이렇게 해두면 운영 반영할 때 누가 언제 만든 변경인지 한눈에 보이고, 롤백 짝 맞추기도 쉬움. 인라인 마이그레이션에 합치면 나중에 추적이 지옥이라 정산 쪽 DDL 은 무조건 분리하는 편.
한 커밋에 묶은 이유
원래는 두 변경을 나눌까 했는데 둘 다 "쌓여있던 잡일 청소" 성격이라 그냥 묶음. 메시지 prefix 도 chore 로 통일.
- 로컬에서 생기는 산출물은 발견 즉시 ignore, 미루면 결국 한 번은 따라 들어감
- DDL 변경은 날짜 박은 별도 파일로 분리해두는 게 운영 반영·롤백 둘 다 편함
- 마감 직전 재집계 같은 엣지 케이스가 평소엔 안 보이던 제약 누락을 끌어올림
작은 커밋이지만 다음 번 마감 때 한숨 한 번은 줄여줄 거라고 생각함. 다음
댓글 0
첫 댓글 달아줘.