Tôi có một cơ sở dữ liệu MySQL chứa một lượng lớn dữ liệu (100-200GB - một loạt các phép đo khoa học). Phần lớn dữ liệu được lưu trữ trong một bảng Sample. Bây giờ tôi đang tạo một bản sao nô lệ của cơ sở dữ liệu và tôi muốn tận dụng những lợi thế của innodb_file_per_tablequá trình này. Vì vậy, tôi thiết lập innodb_file_per_tablecấu hình nô lệ của mình và nhập kết xuất của cơ sở dữ liệu. Thật ngạc nhiên, nó đã thất bại với

LRI 1114 (HY000) ở dòng 5602: Bảng 'Mẫu' đã đầy

Tệp Sample.ibdhiện có dung lượng khoảng 93 GB, với hơn 600 GB dung lượng trống có sẵn trên phân vùng, do đó, đây không phải là vấn đề về không gian trống của đĩa. Dường như nó không đạt được bất kỳ loại giới hạn hệ thống tệp nào (tôi đang sử dụng ext4).

Tôi rất biết ơn về bất kỳ ý tưởng nào có thể là nguyên nhân hoặc điều gì cần điều tra.

Cập nhật: Tôi đang sử dụng mysql Ver 14.14 Distrib 5.1.66, for debian-linux-gnu (x86_64).

SELECT @@datadir; -- returns `/home/var/lib/mysql/`
SHOW VARIABLES LIKE '%innodb_data_file_path%'; -- ibdata1:10M:autoextend 

df -h /home/var/lib/mysql/
768G   31G  699G   5% /home

SỰ THẬT

Bạn nói bạn đang sử dụng ext4. Giới hạn kích thước tệp là 16TB. Như vậy, Sample.ibdkhông nên đầy đủ.

Bạn nói innodb_data_file_pathlà của bạn ibdata1:10M:autoextend. Do đó, tệp ibdata1 tự nó không có giới hạn về kích thước của nó ngoại trừ từ HĐH.

Tại sao tin nhắn này đến ở tất cả? Lưu ý thông báo là "Bảng ... đã đầy", không phải "Đĩa ... đã đầy". Bảng điều kiện đầy đủ này là từ một quan điểm hợp lý . Hãy nghĩ về InnoDB. Những tương tác nào đang diễn ra?

Tôi đoán là InnoDB đang cố tải 93GB dữ liệu dưới dạng một giao dịch. Nơi sẽ các Table is Fullthông điệp bắt nguồn từ đâu? Tôi sẽ xem xét ibdata1, không phải về kích thước vật lý của nó (mà bạn đã loại trừ), nhưng về mặt giới hạn giao dịch đang đạt được.

Có gì bên trong ibdata1 khi innodb_file_per_table được bật và bạn tải dữ liệu mới vào MySQL?

• Từ điển dữ liệu
• Bộ đệm đôi
  • Mạng lưới an toàn để ngăn chặn tham nhũng dữ liệu
  • Giúp bỏ qua hệ điều hành cho bộ nhớ đệm
• Chèn bộ đệm (Hợp lý hóa các thay đổi cho chỉ mục phụ)
• Phân đoạn rollback
• Hoàn tác Nhật ký
• Nhấn vào đây để xem một đại diện hình ảnh của ibdata1

Những nghi ngờ của tôi cho tôi biết rằng Nhật ký hoàn tác và / hoặc Nhật ký làm lại là đáng trách.

Những bản ghi này là gì? Theo sách

Chương 10: "Công cụ lưu trữ" Trang 203 Đoạn 3,4 nói như sau:

Công cụ InnoDB giữ hai loại nhật ký: nhật ký hoàn tác và nhật ký làm lại. Mục đích của nhật ký hoàn tác là để khôi phục các giao dịch, cũng như hiển thị các phiên bản cũ hơn của dữ liệu cho các truy vấn đang chạy ở cấp độ cách ly giao dịch yêu cầu nó. Mã xử lý nhật ký hoàn tác có thể được tìm thấy trong Storage / innobase / buf / log / log0log.c .

Mục đích của nhật ký làm lại là lưu trữ thông tin sẽ được sử dụng trong phục hồi sự cố. Nó cho phép quá trình phục hồi thực hiện lại các giao dịch có thể hoặc chưa hoàn thành trước khi xảy ra sự cố. Sau khi thực hiện lại các giao dịch đó, cơ sở dữ liệu được đưa đến trạng thái nhất quán. Mã xử lý nhật ký làm lại có thể được tìm thấy trong Storage / innobase / log / log0recv.c .

PHÂN TÍCH

Có 1023 Nhật ký hoàn tác bên trong ibdata1 (Xem Phân đoạn quay lại và Hoàn tác không gian) . Vì nhật ký hoàn tác giữ các bản sao dữ liệu khi chúng xuất hiện trước khi tải lại, tất cả 1023 Nhật ký hoàn tác đã đạt đến giới hạn. Từ góc độ khác, tất cả 1023 Nhật ký hoàn tác có thể được dành riêng cho một giao dịch tải Samplebảng.

NHƯNG ...

Có lẽ bạn đang nói "Tôi đang tải một Samplebàn trống ". Nhật ký hoàn tác có liên quan như thế nào? Trước khi Samplebảng được tải với 93GB dữ liệu, nó trống. Đại diện cho mỗi hàng không tồn tại phải chiếm một số không gian lưu trữ trong Nhật ký hoàn tác. Việc lấp đầy 1023 Nhật ký hoàn tác có vẻ tầm thường với lượng dữ liệu đổ vào ibdata1. Tôi không phải là người đầu tiên nghi ngờ điều này:

Từ Tài liệu MySQL 4.1, lưu ý Posted by Chris Calender on September 4 2009 4:25pm:

Lưu ý rằng trong 5.0 (trước 5.0,85) và trong 5.1 (trước 5.1,38), bạn có thể nhận được lỗi "bảng đầy" đối với bảng InnoDB nếu InnoDB hết các vị trí hoàn tác (lỗi # 18828).

Đây là báo cáo lỗi cho MySQL 5.0: http://bugs.mysql.com/orms.php?id=18828

BỀN VỮNG

Khi bạn tạo mysqldump của Samplebảng, vui lòng sử dụng --no-autocommit

mysqldump --no-autocommit ... mydb Sample > Sample.sql

Điều này sẽ đặt một rõ ràng COMMIT;sau mỗi INSERT. Sau đó, tải lại bảng.

Nếu điều này không hiệu quả ( bạn sẽ không thích điều này ), hãy làm điều này

mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql

Điều này sẽ làm cho mỗi INSERT chỉ có một hàng. Mysqldump sẽ lớn hơn nhiều (lớn hơn 10 lần) và có thể mất 10 đến 100 lần để tải lại.

Trong cả hai trường hợp, điều này sẽ giúp Nhật ký hoàn tác không bị ngập nước.

Hãy thử một lần !!!

CẬP NHẬT 2013-06 / 03 13:05 EDT

BỔ SUNG

Nếu bảng hệ thống InnoDB (còn gọi là ibdata1) đạt giới hạn kích thước tệp và Nhật ký hoàn tác không thể được sử dụng, bạn có thể thêm một không gian bảng hệ thống khác (ibdata2).

Tôi vừa gặp tình huống này chỉ hai ngày trước. Tôi đã cập nhật bài đăng cũ của mình với những gì tôi đã làm: Xem Thiết kế cơ sở dữ liệu - Tạo nhiều cơ sở dữ liệu để tránh sự đau đầu về giới hạn về kích thước bảng

Về bản chất, bạn phải thay đổi innodb_data_file_path để chứa tệp không gian bảng hệ thống mới. Hãy để tôi giải thích làm thế nào:

PHONG CÁCH

Trên đĩa (ext3), máy chủ của khách hàng của tôi có các mục sau:

[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  2 00:15 ibdata2

Các thiết lập là

innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M

Lưu ý rằng ibdata2đã tăng lên đến 2196875759616 2145386484M.

Tôi đã phải nhúng kích thước tập tin ibdata2vào innodb_data_file_path và thêmibdata3

innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend

Khi tôi khởi động lại mysqld, nó hoạt động:

[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql   32315015168 Jun  3 17:02 ibdata3

Trong 40 giờ, ibdata3tăng lên 31G. MySQL đã một lần nữa hoạt động.

Tôi đã có cùng một vấn đề và tôi chỉ làm một điều và nó đã làm việc.

Bạn dường như có kích thước tối đa quá thấp cho tệp cấu hình innodb_data_file_pathcủa mình my.cnf. Chỉ cần thay đổi mã dưới đây -

innodb_data_file_path = ibdata1:10M:autoextend:max:512M

Lưu ý quan trọng Bạn không thể lưu trữ nhiều hơn 512MBdữ liệu trong tất cả InnoDB các bảng được kết hợp.

Bạn cũng có thể chuyển sang sơ đồ innodb-per-table bằng cách sử dụng innodb_file_per_table.