Kiến trúc của InnoDB yêu cầu sử dụng bốn loại trang thông tin cơ bản
- Bảng dữ liệu trang
- Bảng chỉ mục trang
- Bảng MetaData
- Dữ liệu MVCC (để hỗ trợ Cách ly giao dịch và Tuân thủ ACID )
- Phân đoạn rollback
- Hoàn tác không gian
- Double Write Buffer (viết nền để ngăn chặn sự phụ thuộc vào bộ đệm của hệ điều hành)
- Chèn bộ đệm (quản lý các thay đổi đối với các chỉ mục phụ không duy nhất)
Xem đại diện hình ảnh của ibdata1
Theo mặc định, innodb_file_per_table bị tắt. Điều này khiến tất cả bốn loại trang thông tin hạ cánh một tệp có tên ibdata1. Nhiều người cố gắng trải đều dữ liệu bằng cách tạo nhiều tệp ibdata. Điều này có thể dẫn đến sự phân mảnh dữ liệu và các trang chỉ mục.
Đây là lý do tại sao tôi thường khuyên bạn nên dọn dẹp cơ sở hạ tầng InnoDB, sử dụng tệp ibdata1 mặc định và không có gì hơn .
Sao chép là rất nguy hiểm vì cơ sở hạ tầng mà InnoDB hoạt động. Có hai cơ sở hạ tầng cơ bản
- innodb_file_per_table bị vô hiệu hóa
- kích hoạt innodb_file_per_table
Với innodb_file_per_table bị vô hiệu hóa, tất cả các loại thông tin InnoDB này đều nằm trong ibdata1. Biểu hiện duy nhất của bất kỳ bảng InnoDB nào ngoài ibdata1 là tệp .frm của bảng InnoDB. Sao chép tất cả dữ liệu InnoDB cùng một lúc yêu cầu sao chép tất cả / var / lib / mysql.
Sao chép một bảng InnoDB cá nhân là hoàn toàn không thể. Bạn phải kết xuất MySQL để trích xuất kết xuất của bảng dưới dạng biểu diễn logic của dữ liệu và các định nghĩa chỉ mục tương ứng của nó. Sau đó, bạn sẽ tải kết xuất đó sang cơ sở dữ liệu khác trên cùng một máy chủ hoặc máy chủ khác.
Với innodb_file_per_table được bật, dữ liệu bảng và các chỉ mục của nó nằm trong thư mục cơ sở dữ liệu bên cạnh tệp .frm. Ví dụ: đối với bảng db1.mytable, biểu hiện của bảng InnoDB bên ngoài ibdata1 sẽ là:
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibd
Không gian bảng hệ thống ibdata1
Tất cả siêu dữ liệu cho db1.mytable vẫn nằm trong ibdata1 và hoàn toàn không có cách nào khác . Làm lại nhật ký và dữ liệu MVCC vẫn còn tồn tại với ibdata1.
Khi nói đến phân mảnh bảng, đây là những gì xảy ra với ibdata1:
- innodb_file_per_table được bật : bạn có thể thu nhỏ db1.mytables bằng
ALTER TABLE db1.mytable ENGINE=InnoDB;hoặcOPTIMIZE TABLE db1.mytable;. Điều này dẫn đến /var/lib/mysql/db1/mytable.ibd nhỏ hơn về mặt vật lý mà không bị phân mảnh.
- innodb_file_per_table bị vô hiệu hóa : bạn không thể thu nhỏ db1.mytables bằng
ALTER TABLE db1.mytable ENGINE=InnoDB;hoặcOPTIMIZE TABLE db1.mytable;vì nó nằm trong ibdata1. Chạy một trong hai lệnh thực sự, làm cho bảng liền kề và nhanh hơn để đọc và ghi vào. Thật không may, điều đó xảy ra ở cuối ibdata1. Điều này làm cho ibdata1 phát triển nhanh chóng. Điều này được đề cập đầy đủ trong bài viết Dọn dẹp InnoDB của tôi .
Nếu bạn đang nghĩ đến việc chỉ sao chép tệp .frm và .ibd, bạn đang xếp hàng vào thế giới bị tổn thương. Sao chép tệp .frm và .ibd của bảng InnoDB chỉ tốt khi và chỉ khi bạn có thể đảm bảo rằng id vùng bảng của tệp .ibd khớp chính xác với mục nhập id vùng bảng trong siêu dữ liệu của tệp ibdata1 .
Tôi đã viết hai bài đăng trong DBA StackExchange về khái niệm id không gian bảng này
Đây là một liên kết tuyệt vời về cách gắn lại bất kỳ tệp .ibd nào vào ibdata1 trong trường hợp id không gian bảng không khớp: http : //www.chrryptender.com/?tag=innodb-error-tablespace-id-in-file . Sau khi đọc nó, bạn sẽ nhận ra ngay lập tức rằng việc sao chép các tệp .ibd chỉ là điên rồ.
Đối với InnoDB, bạn chỉ cần một cái gì đó để di chuyển
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
để tạo một bản sao của bảng InnoDB.
Nếu bạn đang di chuyển nó sang một máy chủ DB khác, hãy sử dụng mysqldump.
Liên quan đến việc trộn tất cả các bảng InnoDB từ tất cả các cơ sở dữ liệu, tôi thực sự có thể thấy sự khôn ngoan khi làm như vậy. Tại công ty lưu trữ DB / Web của chủ nhân, tôi có một Máy khách MySQL có một bảng trong một cơ sở dữ liệu có các ràng buộc được ánh xạ tới một bảng khác trong cơ sở dữ liệu khác trong cùng một phiên bản MySQL. Với một kho lưu trữ siêu dữ liệu phổ biến, nó giúp hỗ trợ giao dịch và khả năng hoạt động MVCC trên nhiều cơ sở dữ liệu.