Auto increment max 때문에 주말에 6시간 일했다 - 2

 

 

해결책은 간단했다. D 테이블의 id가 max에 도달해서 C 모듈이 Queue Table에 있는 데이터를 읽어서 D 테이블에 업데이트를 못하는 것이니깐

1. C 모듈 잠깐 끄고

2. pk가 unsigned int 인 것을 unsigned bigint로 바뀐 E테이블을 새로 만들고

3. D테이블을 E테이블로 카피하고

4. 그다음에 D테이블과 E테이블의 이름을 바꿔치기

하면 해결되는 것이었다. 

 

약간 걱정이 되는 부분은 D테이블에 데이터가 얼마나 쌓였고 D테이블에 있는 데이터를 E테이블에 카피하는 데 걸리는 시간을 가늠할 수 없다는 것이었다. (최대 42억개니깐..) 그래도 git의 maintainer 권한이 있었기 때문에 작업 자체는 어떻게든 다 할 수 있었다.

production DB에 접근할 수 없어 쿼리를 직접 날릴 수 없는 문제는 migration 파일을 이용해서 테이블 이름을 바꾸거나 카피할 수 있었고,

config repo 를 이용하면 약간의 번거로움은 있어도 배포를 통해 모듈이 띄워져 있는 pod을 간접적으로 조작이 가능했었다.

 

옮기는 쿼리는 INSERT INTO SELECT로 쉽게 처리했고, 컬럼 이름 바꾸는 건 RENAME A TO B로 처리했다.

DB copy는 stage는 대략 70분 정도 걸렸고 id는 중간에 id 빵꾸난거를 채우면서 42억 -> 5800만 정도 줄었다. 즉 5800만 개 데이터를 INSERT INTO SELECT 하는데 70분 정도 걸렸다는 것이다.

 

dev 랑 stage에서 DB copy가 문제없이 되는 것을 확인하고 prod에도 동일하게 반영해주었는데 DB 성능이 좋아서 그런지 40분 만에 끝났다.

 

DB copy가 끝나고 dev,stage에서 DB rename 쿼리를 돌려주고 문제가 없는 것을 확인한 후 prod에도 동일하게 쿼리를 돌려주었다.

 

마지막으로 잠깐 죽였던 C 모듈을 재시작 해줌으로서 모듈을 정상화 시켰다. 문제상황 인지부터 해결까지 대충 6시간 좀 안되게 걸렸는데 오늘도 혼자서 잘 해결해서 뿌듯함을 느꼈다. 다만 다음부터는 에러 로그만 보고 대충 문제를 확인하지 말고 조금 더 넓은 시야로 문제를 파악해야 겠다는 반성을 했고, 이렇게 특정 데이터를 처리하는 모듈에 문제가 발생했을 때는 바로 고쳐야겠다고 생각했다.

 

상황 공유 시간

 

상황 종료 시간