회사 개발 서버가 날라갔다...
내가 입사하기 전부터 돌아가던 개발 서버였던지라 당연히 백업 시스템이 구축 되어 있을 줄 알았지만....
암튼 백업하라는 지시가 내려왔는데 이걸 또 수동으로 하고 있....
아후..... /_-;;
- --single-transaction 데이터 일관성을 보장하는 핵심 옵션. 백업 시작 시점의 스냅샷을 생성해서 백업 중에 다른 트랜잭션이 데이터를 변경해도 백업 내용이 일관성 있게 유지되고, InnoDB 엔진에서만 동작함.
- --extended-insert=FALSE INSERT 문을 개별적으로 생성. 기본값(TRUE)은 INSERT INTO table VALUES (1,'a'), (2,'b') 형태로 여러 행을 한 번에 삽입하는걸 FALSE로 설정하면 INSERT INTO table VALUES (1,'a'); INSERT INTO table VALUES (2,'b'); 형태로 각각 생성함. 복원 시 더 안전하지만 파일 크기가 커짐.
- --default-character-set=utf8mb4 클라이언트 문자셋을 utf8mb4로 설정합니다. 한글과 이모지 등 4바이트 문자를 정확히 처리하기 위해 필수.
- --set-charset 백업 파일에 문자셋 설정 명령어를 포함시킴. 복원 시 문자셋 문제를 방지함.
- --complete-insert 컬럼명을 포함한 INSERT 문을 생성함. INSERT INTO table (col1, col2) VALUES (1,'a') 형태로 생성되어 테이블 구조가 변경되어도 안전하게 복원할 수 있음.
- --routines 저장 프로시저와 함수도 백업에 포함시킴.
- --triggers 트리거도 백업에 포함시킴.
개발 서버에서 스케줄러를 돌리려 했지만 백업 파일을 개발 서버로 떨구면 의미가 없어서 외부로 전송하려 했으나...
외부로 전송할 곳이 마땅치가 않았다...
nas가 있음에도 mount도 되어 있지 않고 ip주소도 모르겠고, 답답해서 그냥 내 로컬로 전송하려 했으나 외부 방화벽 문제가 있고.. 이 모든 상황을 공유해서 내부적으로 해결하고 싶었지만... 음.... 답답 ㅋ
그냥 스케줄러를 내 로컬에서 돌리고 땡겨와서 nas로 떨구기로..
sql로 백업하고 압축파일 만들지 말고 파이프를 이용해서 gzip 으로 백업해라!
sql파일로 덤프뜨면 20분 걸리던거 압축 파일로 덤프뜨면 2분 걸림..
crontab으로 주기적으로 백업하는걸로...