필수 MySQL 백업 전략: 데이터에 적합한 접근 방식 선택하기

MySQL 백업 전략은 압박 속에서 복원할 수 있을 때만 유용합니다. 덤프 파일, 파일 시스템 스냅샷, 물리적 백업은 각각 다른 복구 문제를 해결하므로, 올바른 선택은 데이터 크기, 다운타임 허용 범위, 그리고 잃을 수 있는 데이터 양에 따라 달라집니다.

MySQL 백업에 복원 계획이 필요한 이유

백업은 디스크 장애로부터만 보호하지 않습니다. 또한 애플리케이션 버그, 잘못된 배포, 실수로 인한 삭제, 랜섬웨어, 지역 장애로부터 복구하는 데 도움을 줍니다.

두 가지 목표부터 시작하세요:

RTO: 복원하는 동안 데이터베이스가 얼마나 오래 중단될 수 있습니까?
RPO: 얼마나 최근 데이터를 잃을 수 있습니까?

예를 들어, 작은 내부 위키는 야간 mysqldump와 1시간 복원을 허용할 수 있습니다. 프로덕션 주문 시스템은 잘못된 DELETE 전에 특정 초로 복구할 수 있도록 물리적 백업과 바이너리 로그가 필요할 수 있습니다.

`mysqldump`를 사용한 논리적 백업

논리적 백업은 스키마와 데이터를 SQL로 내보냅니다. 이식 가능하고 검사하기 쉽지만, 대규모 데이터베이스에서는 생성 속도가 느리고 복원 속도가 더 느릴 수 있습니다.

하나의 데이터베이스 백업:

mysqldump -u your_username -p your_database_name > backup_file.sql

모든 데이터베이스 백업:

mysqldump -u your_username -p --all-databases > all_databases_backup.sql

특정 테이블 백업:

mysqldump -u your_username -p your_database_name table1 table2 > specific_tables_backup.sql

스키마가 의존하는 경우 루틴, 이벤트, 트리거를 포함하세요. 트리거는 일반적인 mysqldump 사용에서 기본적으로 포함되지만, 백업 실행 책에 의도를 명시하면 검토자가 이를 인지하는 데 도움이 됩니다.

mysqldump -u your_username -p --routines --events --triggers your_database_name > database_with_programs.sql

기존 데이터베이스로 복원:

mysql -u your_username -p your_database_name < backup_file.sql

InnoDB 중심 워크로드의 경우 --single-transaction을 추가하여 긴 테이블 잠금 없이 일관된 스냅샷을 읽도록 합니다:

mysqldump -u your_username -p --single-transaction --routines --events your_database_name | gzip > backup_file.sql.gz

MyISAM과 같은 비트랜잭션 테이블에 의존하는 경우 --single-transaction을 유일한 일관성 보호 수단으로 사용하지 마세요. 해당 테이블에는 다른 잠금 또는 스냅샷 계획이 필요합니다.

대규모 데이터베이스를 위한 물리적 백업

물리적 백업은 데이터베이스를 SQL로 재구성하는 대신 MySQL 데이터 파일을 복사합니다. 일반적으로 대규모 데이터 세트에 더 적합하며, 복원 시간이 파일을 다시 복사하고 복구 로그를 적용하는 시간에 가깝습니다.

일반적인 옵션은 다음과 같습니다:

MySQL 데이터가 충돌 일관성 또는 애플리케이션 일관성을 유지하도록 조정된 파일 시스템 또는 클라우드 볼륨 스냅샷.
MySQL 호환 InnoDB 데이터의 핫 물리적 백업을 위한 널리 사용되는 오픈 소스 도구인 Percona XtraBackup.
MySQL Enterprise 배포를 위한 Oracle의 상용 백업 도구인 MySQL Enterprise Backup.

XtraBackup으로 전체 백업 생성:

xtrabackup --backup --target-dir=/path/to/backup/full --user=your_username --password=your_password

복원 전 백업 준비:

xtrabackup --prepare --target-dir=/path/to/backup/full

MySQL을 중지하고 이전 데이터 디렉토리를 이동한 후 복원:

systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.before-restore
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/path/to/backup/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

이 예제는 Debian 스타일의 서비스 이름과 데이터 디렉토리를 가정합니다. 복원 명령을 실행하기 전에 패키지, 컨테이너 이미지 또는 관리형 데이터베이스 문서를 확인하세요.

바이너리 로그 및 특정 시점 복구

백업은 복원할 수 있는 위치를 알려줍니다. 바이너리 로그는 해당 백업 이후의 변경 사항을 재생하는 데 도움을 주며, 이는 특정 시점 복구에 필요합니다.

자체 관리형 MySQL에서 버전 및 패키징에 적합한 log_bin 설정으로 바이너리 로깅을 활성화하세요. 그런 다음 데이터베이스 서버와 별도로 바이너리 로그를 백업하세요.

복원할 때 일반적으로 다음을 수행합니다:

최신의 양호한 전체 또는 증분 백업을 복원합니다.
mysqlbinlog를 사용하여 대상 시간 또는 위치까지 바이너리 로그를 재생합니다.
운영자 오류로부터 복구하는 경우 잘못된 명령문 전에 중지합니다.

올바른 백업 전략 선택

간단한 결정 규칙을 사용하세요:

소규모 데이터베이스: 자동화된 mysqldump, 압축, 오프사이트 저장소, 정기적인 복원 테스트로 시작하세요.
중간 규모 데이터베이스: 특정 시점으로 복구할 수 있도록 바이너리 로그 백업을 추가하세요.
대규모 또는 비즈니스 중요 데이터베이스: 물리적 백업, 지원되는 경우 증분 백업, 바이너리 로그, 모니터링, 문서화된 복원 훈련을 사용하세요.

백업 속도만으로 선택하지 마세요. 복원 속도는 사고 중에 더 중요합니다.

실제로 중요한 백업 관행

백업 작업을 자동화하되, 프로세스가 지루해질 때까지 수동으로 복원을 테스트하세요. 백업을 오프사이트에 저장하고, 민감한 백업을 암호화하며, 작업 실패를 모니터링하고, 며칠 후에 발견된 조용한 손상이나 실수로 인한 삭제를 감지할 수 있을 만큼 오래 보존 기간을 유지하세요.

또한 정확한 복원 순서를 문서화하세요. 실제 장애 중에는 미래의 자신이 어떤 전체 백업, 증분 백업, 바이너리 로그 범위가 함께 속하는지 추측하지 않아야 합니다.

결론

복원 목표에 맞는 백업 방법을 선택하세요. mysqldump는 소규모 데이터베이스와 이식 가능한 복원에 적합합니다. 물리적 백업은 대규모 시스템에 적합합니다. 바이너리 로그는 특정 시점 복구가 필요할 때 격차를 메웁니다. 무엇을 선택하든, 테스트 환경에서 성공적으로 복원할 때까지 백업은 유효하지 않습니다.