2. 문제의 반복...
이런.... 이런.....
그렇다... 필자는 그렇게 db 데이터 날림의 시련이 또 찾아올 줄은 몰랐다. 하지만, 역시나 그런 오류는 반복되고, 언젠가는 다시 마주할 것이었다. 물론 이렇게 빨리 찾아올 줄은 몰랐지만...
01) 데이터 삽입.
다음 날, 새로운 db에 데이터를 비워둔 채로 미션 7을 진행중이었다. 하지만, 결국 미션 7의 api를 확인해 보기 위해서는 데이터를 넣어야만 했다. 그래서데이터를 집어 넣었다.
하지만, 여기서 잠깐... 설마 또 나가다로 일일이 mysql에 접속해서 db에 하나씩 넣는 것이 옳은 것일까?
그 생각을 안 한 것도 아니다. 그런데 말입니다. 좀 더 이 귀찮은 짓을 줄여줄 방법은 없을까? 고민을 시작했다. 그래서 나온 결과가 아래의 방법이다.
- 기존 데이터가 들어간 테이블이 있는 db를 덤프해서 sql파일을 만들어 놓는다.
터미널을 열고, 바로
mysqldump -uroot -p 기존데이터베이스명 > 파일명.sql
입력하면 되고, 엔터 누르면 mysql 비밀번호 입력하는 창이 뜬다.
비밀번호 입력해주면 기존 데이터를 담은 파일이 생성된다.
이제 모든 준비는 끝났다. 해당 파일을 실행해 보자.
- 실행해 보면, vsc에서 열릴 것이다. 이제 그 데이터들만 뽑으면 된다. 자 뽑는 것 역시 간단하다. 해당 파일을 열어보면, insert into의 쿼리문이 보일 것이다. 이 쿼리문의 뒤로는 본인이 입력한 데이터가 보일 것이다.
그러면 그 줄들을 쭉 복사한다.
그리고나서 mysql에 접속하여 바로 해당 db에 들어간다. 그리고 해당 파일을 복붙하면 된다. 그러면 복사 완료된 것을 확인할 수 있다.
다만, 여기서 의문이 들 수도 있다. 그냥 덤프 파일 로드해서 바로 넣으면 안 되냐?
맞는 말이다. 그렇게도 필자가 안 해본 것은 아니다. 그 방법이 훨씬 간단하고 쉽다. 하지만, 그 경우는 db에 들어갈 데이터에 대한 무결성 검증 등이 제대로 이뤄진 경우에 쓰면 되겠다. 바로 이 부분에 대해서는 아래에 기술하겠다.
02) 참조 무결성의 위배
필자는 여기서 또 오류에 마주한다.
에러메시지
Error Code: 1452. Cannot add or update a child row: a foreign key constraint fails (vanilla.#sql-1c10_73, CONSTRAINT document_ibfk_1 FOREIGN KEY (user_id) REFERENCES _user (id))
바로 잘 들어갈 거라고 예상했던, mysql 상에서 오류가 뜬 것이다. 바로 단박에 알 수 있었다. 아... 내가 지금 넣으려는 데이터의 포린키와 기존 테이블의 프라이머리 키가 안 맞구나...
구글링을 해보니, 이게 바로 참조 무결성 오류였다....ㅜㅜ
다시 만난 오류. 이건 생각보다는 간단했다.
원인
document의 user_id라는 컬럼은 처음부터 있던 게 아니라 나중에 추가한 컬럼이다. 따라서 document 테이블에 있던 기존 튜플에는 user_id 컬럼은 비어있는 상태였다. 이 상황이 참조 무결성을 위배한 것 같다.
참조 무결성이란 데이터베이스의 신념 중 하나로, 예를 들어 A 테이블의 a 컬럼이 B 테이블의 b 컬럼을 참조하고 있다면 이 두 컬럼은 항상 값이 일관되어야 함을 말한다. 즉, B 테이블에서 값을 변경시켰다면 이 변경사항이 A 테이블에도 적용되어야 한다. 또한 B 테이블의 b 컬럼에 없는 값을 A 테이블 a 컬럼에서 가질 수 없다. 아래의 그림은 참조 무결성이 깨진 예시이다.
그래서 필자는 고민했다. 그래서 다시 인서트 인투의 데이터 넣은 부분을 바라봤다. 그랬더니 기존 카테고리 설정에서 참조값으로 넣었던 아이디 값의 데이터가 새롭게 만든 데이터의 아이디 번호와 일치하지 않았던 것. 그래서 다시 해당 부분만 수정해서 다시 넣으니 해결이 바로 되었다.
03) 데이터 확인의 중요성& 백업 필수.
이처럼 데이터가 무결하지 않은 경우가 있기에, 필자는 웬만하면 이렇게 덤핑된 데이터를 하나씩 넣어보면서 테이블에 제대로 데이터가 들어갔는 지 확인하면서 넣는 것이 더 좋다고 느꼈다.
또한, 이번에 다시 한 번 느낀 것은 테이블은 날리면 다시 형식을 만들면 되지만, 데이터는 날리면 너무 수고스럽다. 따라서 특히 수많은 데이터를 다루는 백엔드 개발자에게 있어서는 해당 데이터를 덤프하는 것은 필수라고 하겠다.
그래서 바로 이것을 적용해 새롭게 만든 db인 webucks_3 sql 파일을 만들어 뒀다. 이것이 추후 마이그레이션의 오류에 어떻게 쓰이는 지 확인해 보면 알 것이다. 그 힘을!!!!
다음 편에서는 최종적으로 필자가 마이그레이션의 1탄의 오류를 다시 만났을 때 대처한 방법을 마무리하면서 이번 트러블 슈팅 처리 과정에 대해 마치고자 한다. 기대해 주시라. 뭐 별게 있는 거는 아니고 ㅋㅋ
=================to be continued=======================
