이관된 상품들의 실패한 channel_jobs 수십 건을 신 구조로 옮길 수 있는지를 조사했다. 옮기려면 대응하는 신 구조 레코드가 있어야 하므로 new_product_id 와 new_channel_product_id 참조부터 확인했다.
Table of contents
Open Table of contents
배경 — 컬럼에 없던 매핑
양쪽 참조가 모두 비어 있었고 이관 정보를 담을 만한 컬럼도 없었다. 여기서 매핑이 없다고 결론 내릴 수도 있었다.
두 가지 방법이 있었는데 여기서 매핑이 없다고 결론 내리는 것과 컬럼이 아니라 테이블을 찾아보는 것이다. 뒤쪽을 골랐다. 이유는 이관 작업이 있었다면 어딘가에 대응표를 남겼을 가능성이 커서다. 대신 조사가 반나절 더 걸리는 것을 감수했다. MySQL 매뉴얼대로 information_schema.TABLES 가 데이터베이스의 테이블 정보를 담으므로 TABLE_NAME LIKE '%migration%' 으로 검색하니 product_migrations 매핑 테이블이 나왔다. 나중에 추가된 관계는 기존 테이블에 컬럼을 넣는 대신 매핑 테이블로 만드는 경우가 많으므로 컬럼으로 못 찾으면 테이블 이름을 검색해야 한다.
검증 — 다 된 상위와 몇 건뿐인 자식
그 테이블로 확인하니 수십 건 전부 매핑돼 있어서 상위 레벨 이관은 다 된 상태였다. 그런데 옮기려는 것은 채널별 작업이라 채널별 자식이 있어야 했다.
new_channel_products 를 세니 수십 건 중 몇 건뿐이었다. 왜 그런지를 보려고 한 상품의 자식을 GROUP BY channel_id 로 나열하니 다른 채널은 다 있는데 하나만 없었다.
원인 — 이관이 건너뛴 이유
그 채널의 channel_products 를 보니 NOT_REGISTERED 상태였고 channel_product_no 도 NULL 이었다. 마켓에 한 번도 안 올라간 것이다.
이관이 그런 채널은 자식을 안 만드는데 등록된 적이 없으면 옮길 것이 없기 때문이다. 합리적인 동작이고 그래서 그 채널의 실패 작업은 연결할 대상 자체가 없다.
조치 — 유형으로 갈린 처리
이것을 알고 수십 건을 job_type 별로 나눴다. CREATE 대부분은 연동 레코드가 미등록 상태라 자식이 없고 UPDATE 와 SUSPEND 몇 건만 자식이 있었다.
그 대부분은 등록된 적 없는 것을 등록하려던 작업이므로 당연히 자식이 없다. 이관 대상이 아니라 정리 대상이고 그 상품들을 정말 연동하려면 신 구조에서 새로 만들어야 한다.
주의 — 어렵다와 없다의 차이
이 조사의 결론이 옮기기 어렵다가 아니라 옮길 대상이 없다는 것이었다. 둘은 성질이 다른데 어려운 것은 노력하면 되고 없는 것은 만들어야 한다.
조사 순서는 직접 참조를 보고 관련 컬럼을 찾은 뒤 스키마에서 테이블을 검색하고 매핑을 확인한 다음 자식 존재를 보고 표본으로 이유를 확인해 유형별 처리를 정하는 것이었다. 세 번째 단계가 없었으면 앞의 둘에서 매핑이 없다고 끝났을 것이다.
정리
- 관계가 컬럼이 아니라 별도 매핑 테이블에 있을 수 있다
- 컬럼으로 못 찾으면 스키마에서 테이블 이름을 검색한다
- 상위 매핑이 다 돼도 하위가 다 생긴 것은 아니다
- 이관이 특정 상태의 대상은 건너뛸 수 있다
- 표본의 목록을 나열하면 하나만 없는 것이 보인다
- 작업 유형별로 나누면 이관 대상과 정리 대상이 갈린다
- 옮기기 어렵다와 옮길 것이 없다는 다르다
- 없는 것은 노력이 아니라 새로 만드는 일이다