Eine Website auf eine andere Engine umziehen #

Diese Seite richtet sich an Datenbankadministratoren, die eine bestehende Exponential-Website auf eine andere Datenbank-Engine umziehen, zum Beispiel von SQLite auf PostgreSQL, wenn die Website auf mehrere Server wächst, oder von MySQL auf PostgreSQL wegen einer Richtlinie der Organisation. Die Inhalte bleiben dieselben; nur der Ort ihrer Speicherung ändert sich. Quellen: 9.9 Eine bestehende Website auf eine andere Engine umstellen und Datenbankunterstützung.

Inhalt #

1. Planen
2. Zwischen SQL-Engines
3. Nach Oracle
4. Nach MongoDB
5. Die Einstellungen umstellen
6. Prüfen, bevor Sie wieder öffnen
7. Nach dem Umzug
8. Checkliste

Planen #

• Ein Wartungsfenster: Kein Redakteur darf zwischen dem Dump und dem Moment, in dem die Website auf der neuen Datenbank läuft, veröffentlichen, sonst geht diese Arbeit verloren.
• Eine Probe: Führen Sie den ganzen Umzug zuerst auf einer Kopie aus und messen Sie die Zeit.
• Das Ziel vorbereitet: Datenbank, Konto und Zeichensatz wie auf der Einrichtungsseite der Engine (PostgreSQL, MySQL und MariaDB, MongoDB, Oracle).
• Eine Sicherung der Quelle in ihrem nativen Format.
• Erweiterungen geprüft für die Ziel-Engine (SQL von Erweiterungen prüfen).

Zwischen SQL-Engines #

SQLite, PostgreSQL, MariaDB, MySQL und Oracle mit ezoracle, über das engine-neutrale Format .dba. --type nimmt einen Schema-Handler aus settings/dbschema.ini: mysql, postgresql, sqlite3 und mit ezoracle oracle. Für SQLite ist das Datenbankargument der Dateiname, wie in Database.

php bin/php/maintenance.php on --message="Moving the database" --allow-root-user
# dump schema and data of the current database (MySQL in this example)
php bin/php/ezsqldumpschema.php --type=mysql --host=localhost --user=exponential --password='<password>' \
    --format=generic --output-array --output-types=all exponential var/backup/site.dba --allow-root-user
# load them into the new one
php bin/php/ezsqlinsertschema.php --type=postgresql --host=localhost --user=exponential --password='<password>' \
    --insert-types=all --schema-file=var/backup/site.dba var/backup/site.dba exponential --allow-root-user

--password= ist in der Prozessliste sichtbar: Führen Sie den Umzug auf einer Maschine aus, die Sie kontrollieren, oder verwenden Sie ein vorübergehendes Passwort und ändern Sie es danach. Führen Sie beide Skripte zuerst mit --help aus (Schemawerkzeuge).

Nach Oracle #

Die Erweiterung hat eigene Übertragungsbefehle, ext:ezoracle:mysql2oracle-schema und ext:ezoracle:mysql2oracle-data (Skripte in extension/ezoracle/bin/php/). Lesen Sie ihr --help und führen Sie danach ext:ezoracle:sequence-sync und ext:ezoracle:gather-stats aus (Wartungsbefehle und Cronjobs für Oracle).

Nach MongoDB #

Die Skripte in bin/mongodb/ (export_mysql.sh, mysql2ndjson.py, validate_ndjson.sh, fixup_ndjson.py, import_all.sh) und Abschnitt 18 der Portierungsreferenz. Danach create_indexes.js und ein Lauf der Cronjobs (MongoDB: Grenzen und Betrieb).

Die Einstellungen umstellen #

Setzen Sie in settings/override/site.ini.append.php DatabaseImplementation und die Verbindungsschlüssel auf die neue Engine (und ActiveExtensions[]=ezoracle für Oracle). Dann:

php bin/php/ezcache.php --clear-all --allow-root-user
php bin/php/console exp:velocity restart --allow-root-user     # when Velocity serves the site

und laden Sie PHP-FPM neu. Ein vergessenes DatabaseImplementation ist der übliche Grund, warum nach einem Wechsel keine Seite lädt.

Prüfen, bevor Sie wieder öffnen #

1. Zählen Sie die Zeilen großer Tabellen auf beiden Seiten; die Zahlen müssen übereinstimmen:

   SELECT COUNT(*) FROM ezcontentobject;
   SELECT COUNT(*) FROM ezcontentobject_tree;
   SELECT COUNT(*) FROM ezcontentobject_attribute;

2. Korrigieren Sie auf PostgreSQL die Sequenzen, wenn ezsqlinsertschema.php ein Problem mit ihnen gemeldet hat (PostgreSQL betreiben).

3. Führen Sie die Prüfung der Datenbankkonsistenz aus (Das Schema prüfen).

4. Melden Sie sich in der Administration an, öffnen Sie einige Seiten und veröffentlichen Sie ein Testobjekt.

5. Bauen Sie den Suchindex neu auf, wenn Ergebnisse falsch aussehen: php bin/php/updatesearchindex.php --clean --allow-root-user.

6. Wartungsmodus aus.

Nach dem Umzug #

• Spätere Upgrades verwenden die Update-Dateien der Engine, auf der die Website jetzt läuft, nicht die, auf der sie installiert wurde.
• Sicherungen wechseln das Werkzeug: Passen Sie die Sicherungsjobs an und testen Sie eine Wiederherstellung auf der neuen Engine.
• Überwachung ändert sich: Richten Sie Ihre Prüfungen auf den neuen Server aus (Die Datenbank überwachen).
• Halten Sie die alte Datenbank eine Weile nur lesbar und entfernen Sie sie dann mitsamt ihren Zugangsdaten.

Checkliste #

• To do: Wartungsfenster vereinbart; Probe durchgeführt.
• To do: Zieldatenbank, Konto und Zeichensatz vorbereitet.
• To do: Dump und Insert ohne Fehler abgeschlossen.
• To do: Einstellungen umgestellt; Caches geleert; Worker neu gestartet.
• To do: Zeilenzahlen stimmen überein; Konsistenzprüfung sauber; Testveröffentlichung erledigt.
• To do: Sicherungen, Überwachung und Upgrade-Hinweise für die neue Engine angepasst.

Verwandte Seiten #

• Die Datenbank-Engine wechseln (für Hosting-Unternehmen)
• Eine Engine wählen
• Eine Website zwischen Hosts umziehen
• Migrationen oder Umzug einer Site
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.