"왠지 이걸 하면 DB가 망가질지도 몰라"
하는 시도를 해보고싶으면 그걸 팀 공용으로 쓰고있는 테스트서버 같은데서도 돌려보기 망설여진다.
거기서 망가뜨리면 다시 고쳐놔야 하는데 내가 그걸 다시 망가뜨리는 시도를 할테니까.

mysqldump 삽질

그래서 고민하다가 mysqldump를 이용해 로컬에 복사해와서 시도해보기로 했다.
복사해올 대상의 환경은 AWS RDS MySQL 8.0.17 이다.

그리고 로컬의 환경은 docker mysql 8.0.16 이다.

GTID

일단, mysqldump를 처음 해보니 알고있는대로 질러보기로 했다.

mysqldump [...] \
--result-file="~/dump.sql" \
--no-data \

그랬더니 아래 에러를 만났다.

[1] Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.

해결 방법

아래 옵션을 추가해서 해결했다.

--set-gtid-purged=OFF \
--column-statistics=0

view definer/invoker 에러

mysqldump: got error: 1356: view ['view_name'] references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them when using lock tables

앞에 있던 문제를 해결하니 그 다음은 이런 에러를 만났다.
저걸 그대로 주욱 복사해서 구글에 검색하면 어떻게 해결해야 되는지 알기가 어렵다.

이래저래 해메다가 해당 뷰가 구성된 쿼리를 봤는데 사라진 테이블을 참조하고 있었다.
올바르지 않은 테이블을 참조한다는 내용의 에러가 난 것이었다.

(어딜 보고계신겁니까? 그건 제 잔상입니다만...)

해결 방법

그 뷰를 없애버리자고 팀에 제안해서 없애는걸로 해결했다.

이제 진짜로 dump

결국 해냈는데, 생각보다 엄청난 옵션도 없었고 굉장히 심플하게 끝났다.

--databases "databaseName" \
--no-data \
--set-gtid-purged=OFF \
--column-statistics=0 \
--routines \
--triggers

이렇게 하면 데이터 없이 테이블, 뷰, 프로시저들만 CREATE 해주는 sql 파일이 나온다.

그걸 이용해서 이제 restore 작업을 해주면 되는데....

"끝날 때 까지 끝난게 아니다."

- Yogi Berra

restore 삽질

기쁜 마음에 restore를 돌렸더니 이제 복구하는 과정에서 에러를 만나기 시작했다.

시작부터 sql파일을 돌릴 수 없는 문제

이런 에러를 만났다.

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
or READS SQL DATA in its declaration and binary logging is enabled
(you *might* want to use the less safe log_bin_trust_function_creators
variable)

망연자실해서 다시 검색했는데 한번만에 해결법을 만났다.
너무나 빛과 소금같이 느껴져 감사의 표시로 링크를 남긴다.
참고 : https://dzzienki.tistory.com/34

해결 방법

SET GLOBAL log_bin_trust_function_creators = 1;

이걸 넣어주면 된다고 한다.
그래서 dump떠서 나온 sql파일 맨 위에 넣어주었다.

유저 권한 에러

이 부분은 꽤나 단순한 에러였는데,
우리 팀이 root를 쓰지 않고 특정 유저를 만들어서 사용하고 있어서 난 에러였다.

해결 방법

그 유저가 구성된 쿼리를 그대로 복사해서 dump된 sql파일 상단에 넣어주었다.

create user {user name};

grant SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE ROLE, DROP ROLE on *.* to {database name} with grant option;

성공

결국 위 삽질들을 거쳐서 restore를 성공했다.

특정 테이블의 데이터 복사

--no-data 옵션으로 dump를 떳기에 빈 깡통으로 복사해왔다.

모든 데이터를 가져오기엔 불필요한 부분도 많고
용량이 커서 필요한것만 가져오려는 목적이 있었다.

그래서 추가로 아래 옵션을 넣어서 다시 dump를 실행했다.

--set-gtid-purged=OFF \
--column-statistics=0 \
--databases {"database name"} \
--tables "table1" "table2" "table3"

이렇게 dump 뜬 파일은 실패 없이 곧장 restore가 가능했고,
드디어 마음껏 혼돈 파괴 망가를 즐길 수 있었다.