Ist es sicher, einen Abschnitt fehlender Daten für den erneuten Import mit meinen Flags per mysqldump zu speichern?

Ist es sicher, einen Abschnitt fehlender Daten für den erneuten Import mit meinen Flags per mysqldump zu speichern?

Nehmen wir an, in einer Testdatenbank wurden etwa die Daten eines Jahres gelöscht. Ich habe die beiden IDs für die Daten frühestens in einem Jahr und spätestens für die Daten des anderen Jahres erhalten und daher einen Bereich dessen, was hier fehlt. Meine Frage: Besteht überhaupt eine Gefahr, wenn ich den folgenden Befehl aus der vollständigen Instanz der Datenbank verwende, um einen funktionierenden Dump zu erhalten, mit dem die Datenbank mit dem darin fehlenden Informationsblock repariert werden kann? Der Befehl:

mysqldump -t --insert-ignore --skip-opt --single-transaction --quick --where="id<156789339" -w"id>124054297" -u root -p database table > partial.sql

Und dies soll nach dem GZIP-Komprimieren/Verschieben importiert werden:

zcat partial.sql.gz | mysql -u root -p database table

Möglicherweise ist ein Vorbehalt erwähnenswert: Die Daten stammen aus MySQL 5.5 (Percona), während sie in eine MySQL 5.1-Instanz importiert werden, obwohl mir spontan keine Kompatibilitätsprobleme bekannt sind, die sich daraus ergeben könnten.

Ich verstehe, dass es darum geht, die Erstellung von Anweisungen ( ) -tzu vermeiden , falls sich mein Bereich überlappt, sodass es ignoriert wird, wenn diese ID bereits vorhanden ist, und um sicherzustellen, dass es nicht eine ganze Reihe von Dingen tut, die beim Importieren alles durcheinanderbringen würden ( gemäß der Manpage für mysqldump). Ich möchte nur sichergehen, dass dies alles ist, was ich beim Exportieren brauche, und ob ich beim Importieren vielleicht etwas übersehe, bevor mögliche Fehler gemacht werden.CREATE TABLE--no-create-info--insert-ignore--skip-opt--add-drop-tab, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables, --quick, and --set-charset

Antwort1

Wahrscheinlich ist das in Ordnung. Es gibt einige Sonderfälle, in denen es fehlschlagen kann.

  • In Ihrer Datenbank gibt es Fremdschlüssel, die mit der Anweisung ON DELETE CASCADE auf Ihre Tabelle verweisen. In diesem Fall haben Sie durch die vorherige Löschung andere Daten verloren und müssen diese ebenfalls suchen und kopieren. Wenn Ihre Datenbank MYISAM verwendet, haben Sie keine Fremdschlüssel und sind daher sicher.

  • Sie verwenden spezielle Funktionen, die in der vorherigen Version nicht unterstützt wurden, z. B. FULLTEXT-Indizes. Da Sie sagten, es handele sich um eine Testdatenbank, gehe ich davon aus, dass das Modell identisch ist. In diesem Fall sollte es kein Problem geben.

  • Sie verwenden unterschiedlicheCodierung/Kollationin den beiden Datenbanken und Sie haben nicht-ASCII-Textfelder (lokalisiert) in der Tabelle. Auch hier sollte es kein Problem geben, wenn das Modell dasselbe ist. (Wenn Ihre Tabelle keine explizite Kodierungsdefinition hat und die Standardkodierung in den MySQL-Servernunterscheidet sichMöglicherweise haben Sie ein Problem, aber das ist unwahrscheinlich.)

Wenn Sie INNODB verwenden, möchten Sie möglicherweise Ihren gesamten Dump in einer TRANSAKTION ausführen (zwischen BEGIN; und COMMIT;).

verwandte Informationen