불완전한 mysqldump

데이터베이스 스냅 샷을 만들기 위해 mysqldump를 실행하려고하는데 오류가 발생하지 않고 중간에 임의로 중지됩니다. 내 데이터베이스는 비교적 작으며 (약 100MB) InnoDB를 사용하고 있습니다.

나는 그것을 다음과 같이 실행하고있다 :

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

종료 코드를 확인하면 0이보고됩니다.

내 버전은 다음과 같습니다 : mysqldump Ver 10.13 Distrib 5.1.52, redhat-linux-gnu (i386)

좀 본 적이 유사한 게시물 심지어 공식 버그 리포트를 하지만, 어느 솔루션을 적용 할 것으로 보인다.

mysqldump가 완전한 데이터베이스 스냅 샷을 만들려면 어떻게해야합니까?

편집 : 내 데이터베이스는 현재 Amazon의 RDS에 있습니다.

max_allowed_packet클라이언트 (예 : mysqldump) 와 서버 (예 : Amazon RDS) 모두에서 충분히 높게 설정되지 않은 문제 일 수 있습니다 . 나는 이것을 둘 다 500M으로 설정했는데 문제가 해결 된 것 같습니다 .

InnoDB의 정보 스키마 테이블은 행 수 추정치 만 제공하기 때문에 스냅 샷에 RDS의 모든 항목이 실제로 포함되어 있는지 알기가 어렵습니다. 모든 테이블이 있지만 행 수가 다릅니다. 좀 더 철저한 분석을 스크립팅 할 시간이있을 때보다 명확한 답변으로 업데이트하겠습니다.

시도 했습니까?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

이것은 내가 아무런 문제없이 항상하는 방식입니다. 기본적으로 이러한 방식으로 덤프를 수행하면 커밋되지 않은 트랜잭션을 무시하고 특정 순간에 모든 데이터 (데이터, 개체 및 때로는 소중한 주석)를 얻을 수 있습니다.

내가 이해하는 한, 덤프하는 동안 테이블에서 읽기가 수행되면 --single-transaction이 실패합니다. "--force --single-transaction --quick"없이 실행하면 결과는 어떻습니까?

테이블이 손상되었을 수 있습니다. 데이터 및 / 또는 색인 페이지가 손상되었다는 의미는 아닙니다. 매우 간단한 것이 깨질 수 있습니다.

최근에 mysqldumped 여러 데이터베이스를 병렬 처리 할 때 슬레이브 서버의 백업 스크립트에 문제가 발생했습니다. 데이터베이스 중 하나에서 mysqldump를 실행하면 mysqldump가 매우 작아졌습니다. DB에는 80 개 이상의 테이블이 있습니다. 그러나 mysqldump는 DB의 다섯 번째 테이블에서 중지되었습니다. SHOW CREATE TABLE tblname\G슬레이브의 테이블을 실행했을 때 "테이블을 찾을 수 없습니다"라는 오류가 발생했습니다. SHOW CREATE TABLE tblname\G마스터에서 실행했을 때 테이블 설명이 예상대로 표시되었습니다.

클라이언트는 테이블의 복원을 요청했고 엔지니어는 디스크 백업에서 InnoDB 테이블의 .ibd 파일을 복원했습니다. .ibd 파일의 테이블 스페이스 ID (25)가 ibdata1에 등록 된 테이블 스페이스 ID (28)와 일치하지 않습니다.

슬레이브를 호소하고, mysql을 덤핑하고, 처음부터 복제를 설정하여 문제를 해결했습니다. 다행히도 데이터 및 인덱스 스페 이브는 총 7GB입니다. 따라서 rstore 프로세스는 별 문제가되지 않았습니다.

이야기의 교훈

기본 문제는 테이블 스페이스 ID가 올바르지 않은 경우 mysqldump가 InnoDB에서 오류를보고하지 않는다는 것입니다. mysqldump가 끝나고 모든 테이블을 알파벳 순서로 덤프하지 않는 경우, 이는 오류로 종료되고 오류 메시지를 인쇄하지 않고 테이블을 종료했음을 나타냅니다.

확인하십시오

• 당신은 사용하여 테이블의 구조를 표시 할 수 있습니다 SHOW CREATE TABLE
• INFORMATION_SCHEMA.TABLES에서 테이블에 대한 모든 것을 쿼리 할 수 ​​있습니다.

다음은 mysqldump 및 InnoDB에 대한 일부 브레인 스토밍입니다.

InnoDB 테이블에 대한 mysqldump의 동작에 대해 생각하십시오. 덤프하는 테이블에 속하는 InnoDB 버퍼 풀에 더티 페이지가있는 경우 해당 테이블의 더티 페이지를 디스크로 플러시 SELECT /* SQL_NO_CACHE */해야이를 실행할 수 있습니다.

Amazon RDS를 사용하고 있기 때문에 데이터베이스가 다중 테넌트 인프라에 있다는 느낌이 들었습니다. (과도한 단순화를한다면이 문장을 자유롭게 수정하십시오.) 다른 데이터베이스는 공유 InnoDB 버퍼 풀, 공유 메타 데이터 파일 (ibdata1) 및 공유 테이블 스페이스 ( innodb_file_per_table 이 비활성화 된 경우 ibdata1 )를 사용 중일 수 있습니다.

데이터베이스의 일부 중복이 진행 중일 수 있으며, 이는 작은 데이터 세트 인 경우에도 데이터베이스에 대한 MVCC 에 영향을 줄 수 있습니다.

당신은 증가 할 수 있습니다 (50 초 기본) innodb_lock_wait_timeout 이 아마존 RDS에 어떤 영향이 있는지 확인하려면 mysqldump는 세션 (또는 아마존이 제한을 늘릴있다). 또한 개별 테이블 덤프를 실험 해보십시오.

업데이트 2011-11-14 17:58 EDT

DB 세션 내에서 이것을 실행하십시오 (2 분으로 설정).

SET innodb_lock_wait_timeout = 120;