Ich stelle einen ~ 52 GB-Speicherauszug in einer MySQL-Datenbank wieder her. Die Datei ibdata1 hat die Größe der Speicherauszugsdatei bereits überschritten und die Wiederherstellung ist noch unvollständig. Gibt es eine Möglichkeit, die endgültige Größe der ibdata1-Datei zu schätzen, wenn die Größe der MySQL-Dump-Datei bekannt ist?
Nur aufgrund der Wörter in Ihrer Frage vermute ich Folgendes: Sie haben höchstwahrscheinlich innodb_file_per_table deaktiviert.
HINWEIS: Die folgenden Informationen basieren darauf, dass innodb_file_per_table deaktiviert ist
Beim Einfügen von Daten in InnoDB-Tabellen landen alles und seine Großmutter in der Systemtabellenbereichsdatei, besser bekannt als ibdata1. Was enthält ibdata1 eigentlich?
Tabellendaten und Indizes beim anfänglichen Aufblähen von ibdata1. Die Metadaten sind einfach das Datenwörterbuch + die Liste der Tablespace-IDs, die pro Tabelle zugewiesen werden.
Was ist mit MVCC (Multiversioning Concurrency Control) ? Dies stellt die Systemobjekte dar, die zur Unterstützung der Transaktionsisolation, Rollbacks, Rückgängigmachen von Protokollen, Einfügen von Puffern für Secondayr-Indizes und des Doppelschreibpuffers entwickelt wurden.
Sie müssen die InnoDB-Infrastruktur bereinigen. Ich habe bereits StackExchange-Beiträge darüber geschrieben, wie und warum dies zu tun ist:
Wenn Sie zu Ihrer ursprünglichen Frage zurückkehren, besteht die einzige Möglichkeit, die Größe der ibdata1 beim Neuladen zu schätzen, darin, diese Abfrage vor dem mysqldump auszuführen:
SELECT
data_length/power(1024,3) InnoDBData,
index_length/power(1024,3) InnoDBIndexes,
(data_length+index_length)/power(1024,3) InnoDBSize
FROM
information_schema.tables
WHERE
engine='InnoDB';
Dadurch wird die Größe der Daten in GB angegeben. Bei einem erneuten Laden von ibdata1 (in Ihrem Fall mit innodb_file_per_table deaktiviert) wäre dies die Faustregel für die Größenschätzung gewesen.
Anhand der Größe der Dump-Datei ist es schwer zu beurteilen, da die kombinierte Gesamtgröße von Datenseiten und Indexseiten möglicherweise weit unter der Größe von ibdata1 liegt, aus der der Dump erstellt wurde. Dieser Unterschied wäre ein verbleibender Speicherplatz durch das Aufblähen von MVCC-Systemobjekten (Rollback-Segmente, Rückgängig-Protokolle, Doppelschreibpuffer, Sekundärindex-Einfügepuffer). Aus einer anderen Perspektive könnten Datenseiten die Indexseiten übersteigen und umgekehrt. Dies kann an zu vielen Indizes, schlechtem Design oder nur einer vernünftigen Datenmenge liegen.
ibdata1während der Wiederherstellung so groß geworden ist.