Die Architektur von InnoDB erfordert die Verwendung von vier grundlegenden Arten von Informationsseiten
- Tabellendatenseiten
- Tabellenindex-Seiten
- Tabellen-Metadaten
- MVCC- Daten (zur Unterstützung der Transaktionsisolation und der Einhaltung von ACID )
- Rollback-Segmente
- Leerzeichen rückgängig machen
- Double Write Buffer (Hintergrundschreiben, um das Caching des Betriebssystems zu verhindern)
- Insert Buffer (Verwalten von Änderungen an nicht eindeutigen Sekundärindizes)
Siehe die bildliche Darstellung von ibdata1
Standardmäßig ist innodb_file_per_table deaktiviert. Dies führt dazu, dass alle vier Informationsseitentypen eine einzige Datei mit dem Namen ibdata1 speichern. Viele Menschen versuchen, die Daten zu verteilen, indem sie mehrere ibdata-Dateien erstellen. Dies kann zur Fragmentierung von Daten und Indexseiten führen.
Aus diesem Grund empfehle ich oft , die InnoDB-Infrastruktur mit der Standarddatei ibdata1 und nicht mehr zu bereinigen .
Das Kopieren ist aufgrund der Infrastruktur, unter der InnoDB arbeitet, sehr gefährlich. Es gibt zwei grundlegende Infrastrukturen
- innodb_file_per_table deaktiviert
- innodb_file_per_table aktiviert
Mit innodb_file_per_table Behinderte, alle diese Arten von InnoDB info leben innerhalb ibdata1. Die einzige Manifestation einer InnoDB-Tabelle außerhalb von ibdata1 ist die .frm-Datei der InnoDB-Tabelle. Um alle InnoDB-Daten auf einmal zu kopieren, muss das gesamte Verzeichnis / var / lib / mysql kopiert werden.
Das Kopieren einer einzelnen InnoDB-Tabelle ist völlig unmöglich. Sie müssen einen MySQL-Dump erstellen, um einen Dump der Tabelle als logische Darstellung der Daten und der zugehörigen Indexdefinitionen zu extrahieren. Sie würden diesen Speicherauszug dann in eine andere Datenbank auf demselben oder einem anderen Server laden.
Mit innodb_file_per_table aktiviert ist , Tabellendaten und ihre Indizes leben in der Datenbank Ordner neben der FRM - Datei. Beispiel: Für die Tabelle db1.mytable lautet die Manifestation dieser InnoDB-Tabelle außerhalb von ibdata1:
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibd
System Tablespace ibdata1
Alle Metadaten für db1.mytable befinden sich immer noch in ibdata1, und daran führt absolut kein Weg vorbei . Redo-Logs und MVCC-Daten leben auch noch mit ibdata1.
Wenn es um die Fragmentierung von Tabellen geht, passiert mit ibdata1 Folgendes:
- innodb_file_per_table enabled : Sie können db1.mytables mit
ALTER TABLE db1.mytable ENGINE=InnoDB;oderverkleinernOPTIMIZE TABLE db1.mytable;. Dies führt dazu, dass /var/lib/mysql/db1/mytable.ibd ohne Fragmentierung physisch kleiner ist.
- innodb_file_per_table deaktiviert : Sie können db1.mytables nicht mit
ALTER TABLE db1.mytable ENGINE=InnoDB;oderverkleinern,OPTIMIZE TABLE db1.mytable;da es sich in ibdata1 befindet. Wenn Sie einen der beiden Befehle ausführen, wird die Tabelle zusammenhängend und kann schneller gelesen und beschrieben werden. Leider tritt das am Ende von ibdata1 auf. Dadurch wächst ibdata1 schnell. Dies wird in meinem InnoDB-Bereinigungsbeitrag ausführlich behandelt .
Wenn Sie nur daran denken, die .frm- und .ibd-Datei zu kopieren, sind Sie für die Welt der Verletzungen gut gerüstet. Das Kopieren der .frm- und .ibd-Datei einer InnoDB-Tabelle ist nur dann sinnvoll, wenn Sie sicherstellen können, dass die Tablespace-ID der .ibd-Datei genau mit dem Tablespace-ID-Eintrag in den Metadaten der ibdata1-Datei übereinstimmt .
Ich habe in DBA StackExchange zwei Posts über dieses Tablespace-ID-Konzept geschrieben
Hier finden Sie einen hervorragenden Link zum erneuten Anhängen einer .ibd-Datei an ibdata1 im Falle von nicht übereinstimmenden Tablespace-IDs: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Nachdem Sie dies gelesen haben, sollten Sie sofort feststellen, dass das Kopieren von .ibd-Dateien einfach verrückt ist.
Für InnoDB benötigen Sie nur etwas, um sich zu bewegen
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
um eine Kopie einer InnoDB-Tabelle zu erstellen.
Wenn Sie es auf einen anderen DB-Server migrieren, verwenden Sie mysqldump.
In Bezug auf das Mischen aller InnoDB-Tabellen aus allen Datenbanken kann ich tatsächlich die Weisheit darin erkennen. Bei der DB / Web-Hosting-Firma meines Arbeitgebers habe ich einen MySQL-Client, der eine Tabelle in einer Datenbank hat, deren Einschränkungen einer anderen Tabelle in einer anderen Datenbank innerhalb derselben MySQL-Instanz zugeordnet sind. Mit einem gemeinsamen Metadaten-Repository werden Transaktionsunterstützung und MVCC-Funktionsfähigkeit über mehrere Datenbanken hinweg ermöglicht.