2011-08-05 5 views
1

클라이언트는 ~ 1000 행의 데이터 (최근에는 물론)가 테이블 중 하나에 누락되었습니다. 일부 법의학 조사를 수행 한 결과, 해당 테이블의 다른 행에있는 "last_updated_date"도 삭제 발생과 대략 동일한 시간으로 설정된다는 것을 알았습니다. 이것은 큰 테이블 중 하나가 아닙니다.MySQL 덤프 제한? MySQL 전체 데이터베이스 크기 제한?

지난 주에 대한 mysqldumps는 모두 exact 같은 크기 - 10375605093 바이트입니다. 이전 덤프는 각각 약 0.5GB 씩 증가했습니다. MySQL은 명령은 표준 덤프 : 상자에

/path/to/mysqldump -S /path/to/mysqld2.sock --lock-all-tables -u username -ppassword database > /path-to-backup/$(date +%Y%m%d)_live_data.mysqldump 

DF -h 모든 디렉토리에 충분한 공간 (50 % 이상)를 보여줍니다.

덤프가 늘어나지 않는다는 사실과 결합 된 데이터 손실은 어떻게 든 MySQL에서 하드 코드 된 한계를 깨고 (내가 잘못했으면 좋겠다고) 걱정하고 있습니다. 데이터가 손상됩니다. 이런 얘길 들어 본 사람 없니? 우리는 어떻게 mysqldump 크기를 설명 할 수 있는가?

답변

0

MySQL이 처리 할 수있는 데이터의 양에 하드 코드 된 한계는 없습니다.

+0

더 깊게 파고 들기 ... "max_allowed_packet"문제 (alahttp : //rackerhacker.com/2007/10/11/mysqldump-got-packet-bigger-than-max_allowed_packet-bytes/)가 아니며 파일 시스템은 다음과 같습니다. Linux/ext4 ... 최대 파일 크기는 16TB입니다 (http://en.wikipedia.org/wiki/Ext4). 아직 완전히 단서가 없습니다 ... – rICh

3

다중 멀티 gig 덤프를 수행하고 공간을 절반 이상 사용하면 50 %의 여유 공간이 많다는 의미는 아닙니다. 당신이 당신의 덤프에서 바이너리 데이터를 저장하지 않는 한, 그들은 매우 압축, 그래서 파일로 출력하기 전에 gzip을 통해 배관 mysqldump는의 출력을 건의 할 것입니다 :

mysqldump .... | gzip -9 > /path_to_backup/.... 

MySQL은 그 자체가 말을 임의의 제한이없는 "X 기가 바이트 이후에는 더 이상은 아니지만"실행 플랫폼에 의해 부과 된 제한이 있습니다, detailed here.

+0

디스크 공간이 절대적으로 부족하지 않습니다 ... 각 덤프는 ~ 10GB이고 디스크에는 366GB가 있습니다. – rICh

+1

myserverd가 생성하는 오류 출력을 캡처하려면 stderr을 다른 파일로 리디렉션 할 수 있습니다. 'msyqldump ...> dump.sql 2> dump.err' 그리고 거기에 무엇이 있는지보십시오. 예를 들어 DB에 blob이 max_allowed_packet을 초과하면 덤프가 그 시점에서 중단됩니다. –

+0

커맨드 라인 (stderr을 덤프하지 않고)에서 실행해도 출력은 출력되지 않습니다 ... 완벽하게 실행 된 것처럼 보입니다 (그러나 파일은 10375605093에서 완료됩니다). 데이터 디렉토리의 du -k는 현재 약 1.45GB로이를 보여줍니다 (그리고 성장 중). 나는 정말로 난처하게 굴지 않았다. 꼬리 -1 덤프 파일에 "덤프 완료 2011-08-05 17:33:29"보여줍니다 ... – rICh