지금은 mysqldump를 사용하여 백업을 수행 할 수 있습니다. 그러나 웹 서버를 중단해야하며 백업을 수행하는 데 약 5 분이 걸립니다. 웹 서버를 중단하지 않으면 영원히 걸리고 결코 끝나지 않으며 백업 중에 웹 사이트에 액세스 할 수 없게됩니다.
22GB 및 증가하는 데이터베이스를 백업하는 더 빠르고 더 나은 방법이 있습니까?
모든 테이블은 MyISAM입니다.
답변:
예.
두 번째 컴퓨터에 복제를 설정합니다. 백업이 필요한 경우 보조 시스템을 잠그고 mysqlhotcopy 또는 mysqldump를 수행 한 다음 잠금을 해제 할 수 있습니다. 마스터를 따라 잡기 때문에 마스터를 오프라인으로 전환 할 필요가 없습니다.
쓰기 I / O를 두 배로 늘리지 않아도되는 경우 동일한 머신에서이 작업을 수행 할 수도 있지만, 이상적으로는 실시간으로 두 번째 물리적 서버에 백업하고 필요할 때마다 스냅 샷 백업을 수행해야합니다. 프로덕션 서버를 방해하지 않습니다.
이론적으로 알려진 상태 및 binlog를 사용하여 데이터베이스를 복원 할 수도 있습니다. 한 번도 해본 적이 없으므로 먼저 조사해보십시오. 데이터베이스의 알려진 상태를 백업 한 다음 모든 새로운 binlog를 백업하고 복원해야 할 경우 다시 재생할 수 있습니다. binlog는 선형으로 작성되므로 새 binlog를 원격 컴퓨터로 재 동기화하는 것이 매우 빠릅니다.
편집 : 실제로 백업에 binlogs를 사용하는 것이 문서화 된 것처럼 보입니다.
이 질문은 매우 관련이 있습니다
OS가 Linux라고 가정 해 봅시다. LVM을 사용하지 않는 경우 사용해야합니다. 그렇다면 스냅 샷을 통해 백업하는 매우 간단한 방법입니다.
# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"
/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol
이를 통해 슬레이브 서버를 추가하지 않고도 야간 백업을 수행 할 수 있습니다. 나는 고 가용성을 위해 슬레이브 서버를 사용하는 것을 매우 좋아하지만, 그 슬레이브를 만들 수있을 때까지 갇혀 있다고 생각하고 싶지 않습니다.
READ LOCK이있는 FLUSH 테이블은 생산 시스템에서 정기적으로 (또는 반 정기적으로) 수행하려는 것이 아닙니다. 마지막 수단이어야합니다.
복제 슬레이브를 두 개 이상 설정하십시오 (물론 읽기 잠금이있는 FLUSH 테이블이 필요합니다). 일단 설정되면 다른 하나는 예비 마스터로 동기화 된 상태에서 백업을 수행 할 수 있습니다.
또한 슬레이브 중 하나에 장애가 발생하면 스냅 샷을 사용하여 두 번째 (또는 세 번째) 슬레이브를 재 구축 할 수 있습니다. 모든 슬레이브가 고장 나면 읽기 잠금이있는 FLUSH TABLES로 돌아갑니다.
데이터가 동기화되어 있는지 정기적으로 확인하는 프로세스를 항상 기억하십시오. mk-table-checksum과 같은 것을 사용하십시오 (이 작업은 쉽지 않습니다. 자세한 내용은 Maatkit 설명서를 참조하십시오).
22GB가 상대적으로 작으므로이 작업을 수행하는 데 아무런 문제가 없습니다. 큰 데이터베이스를 사용하면 문제가 발생할 수 있습니다.
여기에 솔루션은 위에서 설명한 것처럼 두 가지입니다.
테이블에 InnoDB를 사용하는 경우 --single-transaction 플래그를 사용하여 테이블 잠금을 수행하지 않아도 마스터 에서조차 데이터베이스의 일관된 덤프를 얻을 수 있으므로 백업 없이도 백업을 수행 할 수 있습니다. 서버를 중단시킵니다. 그러나 위의 솔루션이 더 좋습니다.
또한 Linux에서 LVM을 사용하는 경우 파티션의 LVM 스냅 샷을 작성한 다음 백업 할 수 있습니다. LVM 스냅 샷은 원 자성이므로 '읽기 잠금이있는 테이블 플러시'를 수행 한 다음 스냅 샷을 만들고 잠금을 해제하면 일관된 스냅 샷이 생성됩니다.
덤프가 너무 오래 걸리는 I / O 경합이 우려되는 경우, 디스크 스 래싱을 피하기 위해 네트워크를 통해 세 번째 머신을 추가하고 mysqldump를 실행할 수 있습니다.
환경에 따라 스냅 샷은 일반적으로 훌륭한 방법입니다. 특히 어떤 이유로 마스터를 백업해야하는 경우. 마스터와 슬레이브 쌍을 실행하고 둘 다에서 스냅 샷 백업을 사용합니다.
FLUSH TABLES WITH READ LOCK;UNLOCK TABLES;InnoDB 테이블을 사용 SET AUTOCOMMIT=0;하면 읽기 잠금 을 실행 하기 전에 실행 해야합니다.
" 운영 MySQL 데이터베이스 백업을위한 모범 사례? "를 살펴보십시오 . Stack Overflow와 비슷한 게시물입니다.