거대한 MySQL innodb 데이터베이스를 효율적으로 덤프하는 방법은 무엇입니까?

Ubuntu 10.04 프로덕션 MySQL 데이터베이스 서버를 얻었습니다. 데이터베이스의 총 크기는 260GB이고 루트 파티션의 크기는 자체가 DB가 저장된 300GB입니다. 기본적으로 약 96 % /가 찼으며 덤프 / 백업을 저장할 공간이 없습니다. 현재 다른 디스크는 서버에 연결되어 있지 않습니다.

내 임무는이 데이터베이스를 다른 데이터 센터에있는 다른 서버로 마이그레이션하는 것입니다. 문제는 가동 중지 시간을 최소화하면서 효율적으로 수행하는 방법입니다.

나는 줄을 생각하고있다 :

• 추가 드라이브를 서버에 연결하고 해당 드라이브에 덤프를 요청하십시오. [편집 : 지금은 불가능합니다.]
• 덤프를 새 서버로 전송하고 복원하여 기존 서버의 새 서버 슬레이브를 만들어 데이터 동기화
• 마이그레이션이 필요한 경우 복제를 중단하고 슬레이브 구성을 업데이트하여 읽기 / 쓰기 요청을 수락하고 이전 서버를 읽기 전용으로 설정하여 쓰기 요청을 즐기지 말고 앱 개발자에게 db의 새 IP 주소로 구성을 업데이트하도록 지시하십시오.

이 작업 또는이 작업에 대한 더 나은 대체 방법을 개선하기위한 제안은 무엇입니까?

당신이 MySQL을 동일한 버전으로 다른 DB 서버로 마이그레이션 고려하고 있다면, 당신은 할 수 있습니다 이전 서버에서 새 서버로.rsyncdatadir

이것은 InnoDB 파일 레이아웃이나 MyISAM 테이블의 존재 여부에 관계없이 작동합니다.

1. ServerA와 동일한 버전의 mysql을 ServerB에 설치
2. ServerA RESET MASTER;에서 rsycn 프로세스 전에 모든 이진 로그를 지우려면 실행하십시오 . 이진 로깅을 사용하지 않으면이 단계를 건너 뛸 수 있습니다.
3. ServerA SET GLOBAL innodb_max_dirty_pages_pct = 0;에서 mysql과 약 10 분 동안 실행 합니다 (InnoDB 버퍼 풀에서 더티 페이지를 제거합니다. 또한 mysql 종료를 더 빠르게 수행 할 수 있습니다). 데이터베이스가 모두 MyISAM이면이 단계를 건너 뛸 수 있습니다.
4. ServerA의 rsync / var / lib / mysql과 ServerB의 / var / lib / mysql
5. rsync가 1 분 미만이 될 때까지 3 단계를 반복하십시오.
6. service mysql stop ServerA에서
7. 하나 더 rsync를 수행
8. scp ServerA : /etc/my.cnf를 ServerB : / etc /로
9. service mysql start ServerB에서
10. service mysql start ServerA에서 (선택 사항)

본질적으로, 다음은 이러한 스크립트가 원하는 것입니다

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

DBA StackExchange의 동료 회원은 mysqlperformanceblog.com의 내용을 FLUSH TABLES WITH READ LOCK;근거로 멀리 떨어져 있어야한다고 말했습니다.

필자는 중간에 InnoDB 테이블에 대한 SELECT가 FLUSH TABLES WITH READ LOCK;쓰기가 여전히 어떤 방식 으로든 발생할 수 있음을 읽고 배웠습니다 . Arlukin 의 의견에서 지적했듯이 LVM은 FLUSH TABLES WITH READ LOCKInnoDB에서 잘 작동 합니다 (댓글은 +1).

• http://www.mysqlperformanceblog.com/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
• http://forums.mysql.com/read.php?22,184590,184610

모든 비 LVM 사용자의 경우, 모든 MyISAM 데이터베이스를 사용할 수 있습니다 FLUSH TABLES WITH READ LOCK;. InnoDB의 경우 --single-tranactionmysqldumps의 사용법을 고수 하십시오.

해당 크기의 데이터베이스를 덤프 및 복원하는 데 몇 시간이 걸립니다. 버전 번호가 증가하고 주요 개정 번호가 점프하지 않는 한 mysql 버전에 따라 다릅니다. / var / lib / mysql에서 원시 데이터베이스 파일을 가져 와서 새 서버에 놓고 권한을 설정하고 --skip-grant-tables 스위치를 사용하여 서버를 시작하십시오. 새 IP 주소를 반영하는 사용자에게 필요한 권한을 추가 한 다음 정상적으로 다시 시작하십시오.

데이터베이스 크기가 너무 커서 효율적이지 않습니다.

다음 단계에 따라이 거대한 InnoDB 데이터베이스를 마이그레이션 할 수 있습니다.

• SSHFS를 설치하고 프로덕션 서버에 원격 서버의 관련 파티션을 마운트하십시오.
• Percona XtraBackup을 사용하여 InnoDB 데이터베이스의 핫 카피를 가져 와서 SSHFS 마운트 디렉토리에 직접 저장하십시오.

• 이 작업은 몇 시간이 걸립니다. 라이브 서버에서 핫 카피 스크립트의 영향을 최소화하려면 renice를 사용하여 우선 순위를 낮게 설정하십시오.

  $ renice -n 5 -p <SCRIPT-PID>

• 두 서버 모두 동일한 릴리스의 MySQL 서버를 실행하고 있는지 확인하십시오.
• 핫 카피가 완료되면 새 서버에서 핫 카피를 복원하여 복제 프로세스를 시작할 수 있습니다

이 과정에서 속도가 느려질 수 있지만 다운 타임은 없습니다. Percona XtraBackup은 mysqldump에 비해 더 빠르고 적은 자원을 소비하는 핫 카피를 생성합니다. 이것은 거대한 InnoDB 데이터베이스에 이상적입니다.

사용 패턴 및 통계에 따라 서버에 최소 트래픽이있을 때이 프로세스를 실행할 수 있습니다. 주말에 이렇게하는 것이 좋은 생각일까요? 위는 프로세스의 개요입니다. Percona XtraBackup 및 SSHFS 설명서를 거쳐야 할 수도 있습니다.

데이터베이스를 원격 서버로 바로 덤프 할 수 있습니다 ...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... SQL은 잘 압축되어야하므로 상자에있는 RAM의 양에 따라 다르지만 이러한 옵션 중 하나를 사용 하여이 작업을 훨씬 빨리 완료해야합니다 ...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'