it-swarm-ko.tech

매일 22GB MySQL 데이터베이스 백업

지금은 mysqldump를 사용하여 백업을 수행 할 수 있습니다. 하지만 웹 서버를 다운시켜야하고 백업을하는 데 약 5 분이 걸립니다. 웹 서버를 중단하지 않으면 영구적으로 완료되지 않고 백업 중에 웹 사이트에 액세스 할 수 없게됩니다.

22GB 및 증가하는 데이터베이스를 백업하는 더 빠르고 더 나은 방법이 있습니까?

모든 테이블은 MyISAM입니다.

28
unknown (yahoo)

예.

두 번째 컴퓨터에 복제를 설정합니다. 백업을 수행해야하는 경우 보조 머신을 잠그고 mysqlhotcopy 또는 mysqldump를 수행 한 다음 잠금을 해제 할 수 있습니다. 마스터를 따라 잡을 것이며 마스터를 오프라인으로 전환 할 필요가 없습니다.

쓰기 I/O를 두 배로 늘려도 괜찮다면 동일한 시스템에서이 작업을 수행 할 수도 있지만, 이상적으로는 실시간으로 두 번째 물리적 서버에 백업하고 필요할 때마다 스냅 샷 백업을 수행해야합니다. 프로덕션 서버를 방해하지 않고.

이론적으로 알려진 상태 및 binlog를 사용하여 데이터베이스를 복원하는 것도 가능합니다. 저는 한 번도 해본 적이 없으므로 먼저 조사해 보시기 바랍니다.하지만 데이터베이스의 알려진 상태를 백업 한 다음 모든 새 binlog를 백업하고 복원이 필요한 경우 다시 재생할 수 있습니다. binlog는 선형으로 작성되기 때문에 새 binlog를 원격 컴퓨터에 재 동기화하는 것은 매우 빠릅니다.

편집 : 실제로 백업을 위해 binlogs를 사용하는 것이 문서화되어있는 것처럼 보입니다.

이 질문은 관련성이 높습니다.

28
John Douthat

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

이를 통해 슬레이브 서버를 추가하지 않고도 야간 백업을 수행 할 수 있습니다. 고 가용성을 위해 슬레이브 서버를 사용하는 것을 매우 선호하지만 해당 슬레이브를 만들 수있을 때까지 갇혀 있다고 생각하지 않기를 바랍니다.

5
Bruno Bronosky

READ LOCK이있는 FLUSH TABLES는 프로덕션 시스템에서 정기적으로 (또는 반 정기적으로) 수행하려는 작업이 아닙니다. 최후의 수단이어야합니다.

적어도 2 개의 복제 슬레이브를 설정합니다 (물론 읽기 잠금이있는 FLUSH TABLES가 필요합니다). 일단 설정되면 다른 하나는 예비 마스터로 동기화 상태를 유지하면서 하나의 백업을 제거 할 수 있습니다.

또한 슬레이브 중 하나가 실패하면 그로부터 스냅 샷을 사용하여 두 번째 (또는 세 번째) 슬레이브를 재 구축 할 수 있습니다. 모든 슬레이브가 실패하면 읽기 잠금 기능이있는 FLUSH TABLES로 돌아갑니다.

항상 데이터가 동기화되어 있는지 정기적으로 확인하는 프로세스가 있어야합니다.이를 수행하려면 mk-table-checksum과 같은 것을 사용하십시오 (설정하는 것은 간단하지 않습니다. 자세한 내용은 Maatkit 문서를 참조하십시오).

22GB는 비교적 작기 때문에이 작업을 수행하는 데 문제가 없습니다. 큰 데이터베이스를 사용하면 더 문제가 될 수 있습니다.

2
MarkR

여기서 해결책은 위에서 설명한 것처럼 두 가지입니다.

  1. 오프라인으로 전환 할 수있는 슬레이브에 서버 복제를 설정합니다. 이를 수행하는 가장 좋은 방법은 mysqldump 및 --master-data 매개 변수를 사용하여 데이터베이스를 덤프하는 것입니다.
  2. 슬레이브에서 야간 백업을 설정합니다. --master-data --flush-logs 및 --single-transaction 플래그를 사용하여 mysqldump를 사용하거나 mysql 서버를 중지하고 디스크에 데이터 파일을 복사 한 다음 다시 시작할 수 있습니다 (복제는 중단됨).
  3. 슬레이브에서 매번 (예 : 5 분, 10 분, 20 분) 스크립트를 실행하여 mysql이 여전히 복제 중인지 확인하고 확인하십시오. 나는 간단한 python script 썼습니다.

테이블에 InnoDB를 사용하는 경우 --single-transaction 플래그를 사용하여 테이블 잠금을 수행하지 않아도되고 마스터에서도 데이터베이스의 일관된 덤프를 얻을 수 있으므로 서버를 다운합니다. 그러나 위의 솔루션이 더 나은 솔루션입니다.

또한 Linux에서 LVM을 사용하는 경우 파티션의 LVM 스냅 샷을 만든 다음 백업 할 수 있습니다. LVM 스냅 샷은 원자 적이므로 '읽기 잠금으로 테이블 플러시'를 수행 한 다음 스냅 샷을 생성하고 잠금을 해제하면 일관된 스냅 샷을 얻을 수 있습니다.

덤프가 너무 오래 걸리는 I/O 경합이 염려되는 경우 세 번째 머신을 추가하고 네트워크를 통해 mysqldump를 실행하여 디스크 스 래싱을 방지 할 수 있습니다.

1
Dan Udey

점진적으로 백업 할 수 있습니다. 매시간 레코드의 1/24를 백업합니다. 이 접근 방식의 유일한 문제는 하루 중 처음 몇 시간 동안 충돌이 발생하면 그 시간부터 충돌 시점까지 모든 것을 잃게된다는 것입니다. 어느 쪽이든 손실 된 기록은 24 시간 미만입니다 (이게 당신에게 얼마나 중요한지 모르겠습니다).

0
musicfreak

환경에 따라 스냅 샷은 일반적으로 좋은 방법입니다. 특히 어떤 이유로 마스터를 백업해야하는 경우. 우리는 마스터와 슬레이브 쌍을 실행하고 둘 다에서 스냅 샷 백업을 사용합니다.

  1. FLUSH TABLES WITH READ LOCK;
  2. 데이터베이스 및 로그 파일 시스템에서 스냅 샷을 가져옵니다.
  3. UNLOCK TABLES;
  4. 여유 시간에 스냅 샷에서 데이터 파일을 복사하십시오.

InnoDB 테이블을 사용하면 SET AUTOCOMMIT=0; 읽기 잠금을 실행하기 전에.

0
jasonjwwilliams

" 프로덕션 MySQL 데이터베이스 백업 모범 사례? "를 살펴보십시오. Stack Overflow에 대한 유사한 게시물입니다.

0
Charles Faiga