Mysqldump chưa hoàn thành


11

Tôi đang cố chạy mysqldump để tạo ảnh chụp nhanh cơ sở dữ liệu và tôi thấy nó sẽ dừng ngẫu nhiên giữa chừng mà không báo cáo bất kỳ lỗi nào. Cơ sở dữ liệu của tôi tương đối nhỏ (khoảng 100 MB) và đang sử dụng InnoDB.

Tôi đang chạy nó như sau:

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

Kiểm tra mã thoát báo cáo 0.

Phiên bản của tôi là: mysqldump Ver 10.13 Phân phối 5.1.52, cho redhat-linux-gnu (i386)

Tôi đã thấy một số bài viết tương tự và thậm chí là một báo cáo lỗi chính thức , nhưng dường như không có giải pháp nào được áp dụng.

Làm cách nào để tôi có được mysqldump để chụp ảnh cơ sở dữ liệu hoàn chỉnh?

EDIT: Cơ sở dữ liệu của tôi hiện đang cư trú trên RDS của Amazon.


Có đủ không gian đĩa? Và bạn đã chạy CHECK TABLE để thấy không có lỗi DB trên các bảng chưa?

Bạn đã thử loại bỏ --forceparam để xem bạn gặp lỗi gì chưa? Hay là --quick?

@Adrian, Có, tôi có khoảng 10 GB dung lượng trống, quá đủ. Và vâng, tất cả các bảng kiểm tra ok.

@Yzmir, Vâng, vấn đề tương tự xảy ra.

Câu trả lời:


5

Nó có thể là một vấn đề với việc max_allowed_packetkhông được đặt đủ cao trên cả máy khách (ví dụ: mysqldump) máy chủ (tức là Amazon RDS). Tôi đặt cái này thành 500M cho cả hai và điều đó dường như đã khắc phục vấn đề.

Vì các bảng lược đồ thông tin của InnoDB chỉ đưa ra ước tính số lượng hàng, thật khó để biết liệu ảnh chụp nhanh của tôi có thực sự bao gồm mọi thứ từ RDS hay không. Tất cả các bảng đều ở đó, nhưng số lượng hàng khác nhau. Tôi sẽ cập nhật với một câu trả lời dứt khoát hơn khi tôi có thời gian để phân tích kỹ lưỡng hơn.


4

Bạn đã thử chưa

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

Đây là cách đơn giản mà tôi luôn làm mà không có vấn đề gì. Về cơ bản thực hiện kết xuất theo cách này bạn có được mọi thứ bạn có (dữ liệu, đối tượng và đôi khi là những bình luận quý giá) tại một thời điểm nhất định bỏ qua các giao dịch không được cam kết.


1
Tôi đã gặp lỗi sau khi thử chạy lệnh đó:mysqldump: Got error: 1049: "Unknown database 'data'" when selecting the database
Andy

1
@Andy bạn đúng một cái gì đó sai với điều này bây giờ. dev.mysql.com/doc/refman/5.7/vi/ . Tôi nghĩ rằng "dữ liệu" hoàn toàn không nên ở đó.
Rui Marques

1

Theo như tôi hiểu thì các tài liệu mysql - giao dịch đơn lẻ sẽ thất bại nếu việc đọc được thực hiện trên bàn trong khi bạn đang bán phá giá. Kết quả khi chạy mà không có "- Force --single-giao dịch --quick" là gì?


Tôi nhận được lỗi tương tự.
Cerin

Tôi không thể tìm thấy bất cứ điều gì trong tài liệu để hỗ trợ tuyên bố này. AFAIK đọc và ghi trên bảng được hỗ trợ khi - giao dịch đơn lẻ được thực hiện, nhưng các câu lệnh thay đổi cấu trúc bảng (ALTER, CREATE, TRUNCATE, v.v.) có thể khiến kết xuất không thành công hoặc cung cấp dữ liệu không mong muốn. ( dev.mysql.com/doc/refman/5.7/vi/
Chỉ huy mã

1

Nó hoàn toàn có thể là bảng bị hỏng. Tôi không có nghĩa là các trang dữ liệu và / hoặc chỉ mục bị hỏng. Có thể có một cái gì đó rất đơn giản bị phá vỡ.

Gần đây tôi đã gặp sự cố với tập lệnh sao lưu trên Máy chủ Slave khi tôi song song với nhiều cơ sở dữ liệu. Chạy mysqldump trên một trong những cơ sở dữ liệu dẫn đến một mysqldump rất nhỏ. DB có hơn 80 bảng. Tuy nhiên, mysqldump dừng lại ở bảng thứ năm trong DB. Khi tôi chạy SHOW CREATE TABLE tblname\Gtrên bàn trên Slave, tôi đã gặp lỗi "Không tìm thấy bảng". Khi tôi chạy SHOW CREATE TABLE tblname\Gtrên Master, mô tả bảng hiển thị như mong đợi.

Điều đã xảy ra là một chút điên rồ: Một khách hàng đã yêu cầu khôi phục bảng và một kỹ sư đã khôi phục tệp .ibd của bảng InnoDB từ bản sao lưu đĩa. Id không gian bảng của tệp .ibd (25) không khớp với id không gian bảng được đăng ký trong ibdata1 (28).

Tôi đã khắc phục vấn đề bằng cách hos nô lệ, mysqldumping master và thiết lập sao chép từ đầu. May mắn thay, dữ liệu và chỉ số tổng cộng là 7GB. Do đó, quá trình lưu trữ không phải là một vấn đề lớn.

CÂU CHUYỆN

Vấn đề cơ bản là mysqldump không báo cáo lỗi trên InnoDB khi id vùng bảng không chính xác. Khi một mysqldump kết thúc và không đổ mọi bảng theo thứ tự bảng chữ cái, điều đó cho thấy nó bị chấm dứt bởi một lỗi và đã làm như vậy mà không in thông báo lỗi.

Kiểm tra để đảm bảo

  • bạn có thể hiển thị cấu trúc của bảng bằng cách sử dụng SHOW CREATE TABLE
  • bạn có thể truy vấn mọi thứ về một bảng từ Information_SCHema.TABLES

0

Sau đây chỉ là một số động não trên mysqldump và InnoDB:

Vui lòng suy nghĩ về hành vi của mysqldump đối với bảng InnoDB. Nếu có bất kỳ trang bẩn nào trong Nhóm đệm của InnoDB thuộc về bảng bạn đang bán, thì các trang bẩn đó của bảng đó phải được xóa ra đĩa trước khi SELECT /* SQL_NO_CACHE */có thể được thực thi đối với bảng đó.

Vì bạn đang sử dụng Amazon RDS, cảm giác ruột của tôi là cơ sở dữ liệu của bạn nằm trong một cơ sở hạ tầng đa năng (Hãy thoải mái sửa câu lệnh này nếu tôi quá đơn giản hóa điều này). Các cơ sở dữ liệu khác có thể đang sử dụng Nhóm bộ đệm InnoDB được chia sẻ, tệp siêu dữ liệu được chia sẻ (ibdata1) và không gian bảng được chia sẻ (ibdata1 nếu innodb_file_per_table bị tắt).

Cũng có thể có một số dư thừa của cơ sở dữ liệu đang diễn ra, điều này có thể ảnh hưởng đến MVCC đối với cơ sở dữ liệu, mặc dù đó là một bộ dữ liệu nhỏ.

Bạn có thể muốn tăng innodb_lock_wait_timeout (50 giây mặc định) trong phiên mysqldump của mình để xem điều này có ảnh hưởng gì đến Amazon RDS không (hoặc Amazon tăng giới hạn này). Ngoài ra, hãy thử trải nghiệm với việc bán các bảng riêng lẻ.

CẬP NHẬT 2011-11-14 17:58 EDT

Hãy thử thực hiện điều này trong Phiên DB của bạn (đặt nó thành hai phút):

SET innodb_lock_wait_timeout = 120;

innodb_lock_wait_timeout là một tham số tĩnh trên RDS không thể thay đổi.
Cerin

@Cerin: Theo Tài liệu, bạn có thể đặt nó trong phiên của mình.
RolandoMySQLDBA

"Phiên của tôi" nghĩa là gì? mysqldump liệt kê không có tùy chọn để điều chỉnh bất kỳ thời gian chờ.
Cerin

Xin lỗi, tôi đã nhìn vào nó ngược. Tôi muốn nói là đặt innodb_lock_wait_timeout trong Amazon RDS.
RolandoMySQLDBA
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.