Skip to content
isdnetworks
Go back

판마다 다른 파일 형식

기록 파일을 읽어서 처리하는 cron 배치가 있었는데 어떤 파일에서는 실패하고 어떤 파일에서는 잘 돌았다. 실패하는 파일들을 grep 으로 모아서 열어 보니 형식이 지금 것과 달랐다.

Table of contents

Open Table of contents

증상 — 실패하는 파일과 여러 판

형식을 바꿀 때 그 시점 이후의 파일만 새 형식이 되고 그 전 파일은 옛 형식으로 남아 있었다. 파일이 남아 있는 한 읽는 쪽은 여러 판을 다 다뤄야 한다.

모아서 보니 판이 두 개가 아니라 세 개였고 각각 만들어진 시기가 달랐다. 형식이 바뀔 때마다 하나씩 늘어난 것이었다.

내용으로 판을 알아내기

파일 안에 이것이 몇 번째 판인지를 적어 둔 자리가 없었기 때문에 내용을 보고 판단해야 했다. 다행히 첫 줄만 읽어도 세 판이 서로 갈렸다.

그래서 파일을 열어 첫 줄로 판을 정하고 그다음에 그 판에 맞는 파서로 읽게 만들었다. 이 판단이 틀리면 뒤의 처리가 전부 어긋나므로 첫 줄 규칙을 각 판마다 확인해 뒀다.

못 알아내면 처리하지 않는다

세 판 중 어느 것으로도 안 갈리는 파일이 나올 수 있으므로 그 경우를 어떻게 할지도 정해야 했다. 짐작으로 어느 한 판으로 읽으면 조용히 잘못된 값이 들어간다.

그래서 판을 못 알아낸 파일은 처리하지 않고 그대로 남기면서 목록에 적게 했다. 나중에 사람이 열어 보고 판단하면 되고 그때까지 자료가 오염되지는 않는다.

읽는 것만 나누고 결과는 하나로

판별 뒤에 갈라지는 것은 읽는 부분까지만이고 그 뒤로는 같은 형태로 만들어서 흘려보냈다. 뒤쪽 처리가 판을 알 필요가 없어야 판이 하나 더 늘어도 뒤쪽을 안 고친다.

옛 판에는 아예 없는 값이 몇 개 있었는데 그것은 NULL 로 두는 쪽으로 했다. 기본값을 채워 넣으면 실제로 그 값이었던 것과 없어서 채운 것이 구분되지 않는다.

판별 건수와 새 형식의 표시

판별해 본 결과를 판별로 세어 보니 옛 판 두 개의 건수가 생각보다 적었다. 이 숫자가 옛 파일을 새 형식으로 옮길지 그대로 둘지를 정하는 근거가 됐다.

전부 옮기거나 전부 두는 대신 자주 조회되는 것만 옮기기로 했다. 그리고 새로 만드는 형식에는 판 표시를 넣어서 다음에는 내용을 보고 알아내지 않아도 되게 했다.

정리


Share this post on:

Previous Post
마이그레이션 원본이 살아 있었다
Next Post
메모리 풀이 하나가 아니었다