MySQL 논리 백업 및 복원 (mysqldump, MySQL Shell)
MySQL난이도: 중급소요 시간: 20–90분 (데이터 크기에 따라)mysqldump 또는 MySQL Shell(util.dumpInstance / dumpSchemas / dumpTables + util.loadDump)을 사용한 논리 백업 및 복원입니다: 테이블, 스키마 또는 인스턴스 전체, 구조만 또는 데이터만, 다른 서버로의 마이그레이션, 전체 덤프에서 단일 테이블 추출, systemd/cron으로 예약하고 login-path로 비밀번호 없이 실행하며 검증과 보존 기간을 갖춘 백업. 모든 경로는 행 수 비교로 끝납니다. 마이그레이션, 단일 객체 복구, 버전 간 이전에는 이 가이드를 사용하고, 대용량 데이터베이스의 일일 백업, 빠른 복원, 특정 시점 복구(PITR)에는 Percona XtraBackup 가이드를 사용합니다.
구성: 서버 1대 (마이그레이션 및 인스턴스 복원 시 대상 서버 추가)
시나리오
- 테이블 export / import — 하나 이상의 테이블을 백업하거나 다른 스키마/서버로 복사하거나 복원합니다. 원본은 계속 운영되며 InnoDB 테이블에는 잠금이 걸리지 않습니다.
- 스키마(데이터베이스) 백업 / 복원 — 데이터베이스(스키마) 전체를 백업하거나 다른 스키마/서버에 로드합니다. 원본은 계속 운영되며 대상의 같은 이름 테이블은 삭제 후 다시 생성됩니다.
- 인스턴스 전체 (사용자 + 모든 스키마) — 백업은 이 서버에서 받고 복원은 빈 서버에서 수행합니다: 사용자, 권한, 모든 스키마. 서버 재구축 또는 버전/플랫폼 변경용입니다.
- 구조만 (DDL) — 테이블, 뷰, 트리거, 프로시저, 이벤트 정의만 포함하며 데이터는 없습니다. 스키마 비교, 빈 환경 구축, 구조의 버전 관리용입니다.
- 데이터만 — 대상에 구조가 이미 있는 상태에서 행만 전송합니다(예: 테스트 데이터 갱신). 로드 중 대상의 트리거가 실행될 수 있으며 가이드에서 이를 확인합니다.
- 다른 서버로 마이그레이션 — 대상 서버에서 작업하며 원본에는 네트워크를 통해 login-path로 접속합니다. 전환 시점에 애플리케이션은 쓰기를 중지하며, 다운타임은 덤프 + 로드 시간만큼입니다. 서버, 운영체제 또는 버전 변경용입니다.
- 전체 덤프에서 단일 테이블 추출 — 전체 덤프는 있는데 테이블 하나만 필요한 경우입니다(삭제된 행, DROP된 테이블). 원래 스키마는 건드리지 않고 별도 스키마로 추출하거나, 삭제된 테이블을 되돌려 놓습니다.
- 예약 백업 (systemd timer / cron) — 매일 정해진 시각에 자동으로 받는 논리 백업입니다: 별도 백업 사용자, login-path, 스크립트, systemd timer 또는 cron, 보존 기간, 오류 알림. 원본은 계속 운영됩니다.
시작하기 전에
- MySQL …이(가) 실행 중이며, 운영체제 root 사용자가 mysql 명령으로 비밀번호 없이 접속할 수 있습니다(auth_socket 또는 ~/.mylogin.cnf). DBAtlas MySQL 단일 서버 설치 가이드로 설치했다면 경로가 동일합니다.
- 스키마 크기를 알고 있으며 백업 디렉터리 …에 충분한 여유 공간이 있습니다(압축된 논리 백업은 보통 데이터 크기의 10–30%이며, 인덱스는 정의만 덤프에 포함됩니다).
- 모든 테이블이 InnoDB입니다. --single-transaction(및 MySQL Shell의 일관된 덤프)은 InnoDB 테이블에서만 잠금 없이 일관성을 보장합니다. MyISAM 테이블이 있으면 덤프 중 해당 테이블에 대한 쓰기가 불일치를 일으킵니다.
- MySQL Shell을 설치할 서버가 MySQL 저장소(repo.mysql.com)에 접근할 수 있거나 사내 미러가 구성되어 있습니다.
- 대상 서버 …에 같거나 더 새로운 MySQL 버전이 (DBAtlas 설치 가이드로) 설치되어 실행 중이며 사용자 스키마가 없습니다. 롤백을 위해 8.4에서 8.0으로 로드하는 것처럼 이전 버전으로의 로드는 지원되지 않습니다.
- 대상 서버에서 원본의 … 포트에 접근할 수 있습니다.
- 서버에서 이메일을 보낼 수 있습니다: 로컬 MTA(postfix)가 사내 SMTP relay로 전달하도록 설정되어 있습니다.
- 대규모 복원이나 마이그레이션을 위한 유지보수 시간이 계획되어 있으며, 대상을 덮어쓰는 경우 대상의 백업을 받아 두었습니다.
- 이 서버는 정상 상태의 replica입니다: IO 및 SQL 스레드가 Yes이고 지연이 낮습니다. 덤프에 기록되는 binlog 위치(--source-data=2)는 이 replica 자체의 binlog를 가리킵니다. PITR에 사용하려면 log_replica_updates가 켜져 있어야 합니다(8.x 기본값).
- 이 서버는 InnoDB Cluster 멤버이며 현재 SECONDARY / ONLINE 상태입니다.
가이드 단계
- 준비 — 백업 디렉터리 생성 · 테이블 엔진과 장시간 트랜잭션 확인 · MySQL Shell 설치
- 복원 (import) — 대상 스키마 생성 · 대상에 테이블 구조 생성 · 대상의 트리거 확인 · 로드 (mysql) · 로드 (mysql, 같은 스키마에 덮어쓰기) · 로드 (util.loadDump) …
- 인스턴스 백업 — 사용자와 권한 내보내기 · 모든 스키마 백업 (mysqldump) · 인스턴스 백업 (util.dumpInstance) · 백업을 복원 서버로 복사 · 백업 로드 (mysql) · 사용자 로드 …
- 원본 서버의 마이그레이션 계정 — 마이그레이션 사용자 생성 · 방화벽에서 대상에 포트 개방 · 애플리케이션 중지 (전환 시점)
- 대상 서버에서 전송 — 원본 접속 정보를 login-path로 저장 · 사용자 마이그레이션 · 스키마 전송 (mysqldump | mysql) · 대상에 사용자 로드 · 원본 덤프 (util.dumpInstance / dumpSchemas) · 대상에 로드 (util.loadDump) …
- 덤프에서 단일 테이블 추출 — 테이블이 덤프에 있는지 확인 · 덤프에서 테이블 추출 · 대상 스키마 생성 · 테이블 로드 · 테이블을 원래 스키마로 복원 · 행 수 비교 …
- 백업 사용자와 login-path — 운영체제 백업 사용자 생성 · MySQL 백업 계정 생성 · login-path 저장 (mysql_config_editor)
- 백업 스크립트 — 알림 도구 설치 · 백업 스크립트 작성 · 스크립트에 실행 권한 부여 · 첫 백업 수동 실행
- 예약 (systemd timer) — systemd 서비스 작성 · systemd timer 작성 · timer 활성화 및 서비스 수동 실행 · 예약 작업 실행 확인 (다음 날)
- 예약 (cron) — cron 서비스 준비 · cron 작업 작성 · cron 파일 권한 설정 및 cron 환경에서 테스트 · 예약 작업 실행 확인 (다음 날)
- 검증 및 모니터링 — 최신 백업을 테스트 스키마로 복원 · 최신 백업 경과 시간 모니터링
- 다음 단계: 물리 백업 — 논리 백업의 한계 보완