다시 만들면 멀쩡하던 것도 달라진다

집계 데이터를 전 기간 다시 만들어야 해서 작업 전에 백업을 떴다. 작업 뒤에 백업과 비교해 의도한 것만 바뀌었는지 보려 했는데 거의 전부 달랐다.

Open Table of contents

백업과 거의 전부 달랐던 결과

이유는 단순했는데 재생성은 그 시점의 원본에서 다시 가져온다는 점이었다. 백업을 뜬 시점과 재생성 시점 사이에 취소와 반품과 정정이 들어왔다.

그러면 원래 정상이던 구간도 정당하게 달라진다. 바이트 비교는 그것까지 전부 변경으로 잡으므로 나오는 것이 거짓 경보뿐이었다.

바이트 비교는 같은지 다른지만 말하고 왜 다른지는 말하지 않는다. 재생성처럼 정당한 변동이 섞이는 작업에서는 그 구분이 판정의 전부다.

그래서 비교 방식을 두 축으로 나눴다. 하나는 형태가 기대한 대로인지이고 다른 하나는 값이 얼마나 달라졌는지다.

구조 축에서는 최상위 키 개수와 특정 버킷의 항목 수 회복과 새 필드의 존재를 봤다. 이것들은 재생성으로 의도한 변경이므로 바뀌어 있어야 정상이다.

변동폭 축에서는 월별 총액이 백업 대비 몇 퍼센트 달라졌는지를 봤다. 이쪽은 바뀐 것이 정당한지를 판단하는 축이다.

변동률을 구간별로 보니 확정 구간은 변동이 없고 최근 구간만 소폭 줄어 있었다. 확정 구간은 정산이 끝나 원장이 안 움직이므로 재생성해도 같은 값이 나와야 한다.

그 구간이 실제로 움직이지 않았다는 것은 깨져 있던 것이 집계 방식뿐이고 원본은 멀쩡했다는 뜻이다. 반대로 확정 구간이 움직였으면 집계 문제가 아니라 원장 쪽 신호이므로 기준선 없이는 뭔가 바뀐 것 같다에서 못 나간다.

백업을 뜨면서 압축 인코딩 표시가 헤더에 보존되는지도 확인했다. 원본이 압축돼 저장돼 있는데 복사하면서 그 표시가 빠지면 복원했을 때 압축된 본문을 그대로 내려보내 화면이 깨진다.

복사 명령이 성공한 것과 제대로 복사된 것은 다르므로 복사 뒤에 헤더를 다시 조회했다. 버킷의 버전 관리가 꺼져 있어 이 백업이 유일한 되돌리기 수단이었으므로 개수와 크기 합계와 헤더에 더해 표본 몇 개를 실제로 열어 봤다.