Ich muss eine InnoDB-Datenbank von einem Server auf einen anderen verschieben – außerdem wird sie von MySQL > MariaDB verschoben. Ich möchte sicherstellen, dass es überhaupt keine Probleme gibt, und werde daher mysqldump zum Exportieren und anschließenden Importieren auf dem neuen Server verwenden. Die my.cnf-Einstellungen sind auf dem neuen Server anders, daher möchte ich keine Dateien kopieren. Ich mache mir auch keine allzu großen Sorgen um Ausfallzeiten, solange dadurch ein guter Dump/Import ohne Probleme gewährleistet wird.
Da es sich um eine Live-Datenbank handelt, mache ich mir Sorgen über Fehler im Dump aufgrund von Transaktionen oder aus anderen Gründen, die beim Importieren auf den neuen Server zu Einschränkungsproblemen/Beschädigungen führen würden.
Was ist hier das beste Vorgehen? Folgendes habe ich mir überlegt ...
- Starten Sie MySQL ohne Benutzerzugriff neu, damit niemand die Datenbank lesen/beschreiben kann.
- mysqldump mit
mysqldump -u [username] -p[password] -h [host] [databaseName] > [backup-name].sql - importieren mit
mysql -u [username] -p[password] -h [host] [databaseName] < [filename].sql
Ist es möglich, MySQL neu zu starten und alle Benutzer auszusperren? Würde dies alle verbleibenden Transaktionen lösen und sicherstellen, dass die Daten beim Importieren legitim sind? Grundsätzlich möchte ich den Zugriff auf die Datenbank für immer „sperren“, sobald ich den Sicherungsvorgang starte, da nach dem Import auf den neuen Server nie wieder darauf zugegriffen werden muss und, was noch wichtiger ist, ich möchte nicht, dass während des Dumps/der Wiederherstellung auf dem anderen Server darauf zugegriffen wird. Natürlich möchte ich die Datenbank auf dem ursprünglichen Server belassen, falls beim Importieren Probleme auftreten.
Antwort1
--hex-blobBeachten Sie, dass Sie mit verwenden müssen, mysqldumpwenn Sie verschlüsselte Felder in der Datenbank haben. Wenn --hex-blobnicht verwendet, werden die Daten beim Importieren unbrauchbar.
Führen Sie vor dem Sichern ein aus, FLUSH TABLES WITH READ LOCKum Änderungen zu verhindern. Sie können das Backup in einem Schritt auf den neuen Server weiterleiten und sparen sich so das Kopieren der SQL-Datei.
mysqldump --single-transaction --routines --triggers --events --hex-blob db-name | mysql -h server db-name
Antwort2
Als Erstes sollten Sie eine Sicherungskopie Ihrer Datenbank erstellen, diese dann auf den neuen Server importieren und, wenn alles in Ordnung ist, den neuen Server zunächst testen. Überprüfen Sie auch, wie viel Zeit Sie zum Erstellen einer Sicherungskopie und zur Wiederherstellung auf dem neuen Server benötigen, damit Sie wissen, wie viel Zeit Sie benötigen, um den neuen Server in Betrieb zu nehmen.
Wenn Sie bereit sind, alles an den neuen Server zu übergeben, deaktivieren Sie am besten alle Verbindungen zu Ihrer Datenbank, außer zu localhost, da Sie mysqldump verwenden, um auf die Datenbank zuzugreifen und die Sicherung zu erstellen. Wenn alle Zugriffe auf die Datenbank von Ihrem Webserver kommen, können Sie den Webserver herunterfahren. Eine andere Möglichkeit wäre, iptables so zu konfigurieren, dass der gesamte Datenverkehr auf Ihrem MySQL-Port außer localhost blockiert wird. Dann sichern Sie Ihre Datenbank, stellen sie auf dem neuen Server wieder her, schalten Ihren neuen Server live und stellen sicher, dass alle Ihre Verbindungen zum neuen Server gehen.
Antwort3
das hängt alles davon ab, ob Ihre Datenbank groß oder klein genug ist und welchen Dienst Sie ausführen. Ich nehme aber an, dass es ein gewisses Wartungsfenster geben muss. Fahren Sie beispielsweise am Wochenende spät in der Nacht Ihren Apache/Nginx herunter. Sie können Ihre Datenbank auch mit deaktiviertem Netzwerk, einer Firewall oder einem anderen lokalen Port neu starten. Export:
mysqldump -p --single-transaction --routines --triggers --events DATABASE | gzip > backup.sql.gz
importieren:
zcat backup.sql.gz | mysql -f -p DATABASE
nochmal prüfen:
mysql_upgrade -p -f
gzipUndzcat wird Ihnen helfen, es schneller zu erledigen.