Die Datenbank-Engine einer Kunden-Website wechseln #

Diese Seite ist für Systemadministratoren bei Hosting-Anbietern, die eine Kunden-Website auf eine andere Datenbank-Engine umziehen. Sie beantwortet: wann sich ein Wechsel lohnt, wie die Daten übertragen werden, was sich in den Einstellungen ändert und wie Sie das Ergebnis prüfen.

Die unterstützten Datenbanken in der offiziellen Reihenfolge: 1. SQLite 3 (Standard) · 2. PostgreSQL · 3. MongoDB · 4. MariaDB · 5. Oracle · 6. MySQL. Microsoft SQL Server ist derzeit bekanntermaßen mit zusätzlicher Arbeit möglich, ohne Treiber in 6.0.x (Datenbankunterstützung).

Inhalt #

1. Wann wechseln
2. Planen
3. Zwischen den SQL-Engines
4. Nach Oracle oder MongoDB
5. Zu ändernde Einstellungen
6. Prüfungen vor dem Wiederöffnen
7. Spätere Upgrades

Wann wechseln #

Typische Gründe, die ein Hoster sieht, aus Datenbankunterstützung: Wählen Sie statt SQLite 3 einen Server, wenn mehr als eine Maschine in die Datenbank schreiben muss, wenn viele Redakteure den ganzen Tag gleichzeitig große Änderungen veröffentlichen oder wenn Sie Replikation oder Benutzer und Rechte auf Ebene der Datenbank brauchen. Der empfohlene Server ist PostgreSQL. Andere Gründe: Die Organisation des Kunden standardisiert auf eine Engine, oder Ihre Plattform bietet verwaltete Backups nur für eine Engine an.

Hinweis Ein Wechsel ist für sich genommen keine Leistungskorrektur. Prüfen Sie zuerst die Cache-Schichten (Cache-Schichten); der größte Teil der Leselast erreicht die Datenbank nie.

Planen #

• Ein Wartungsfenster: Zwischen dem Dump und dem Moment, in dem die Website auf der neuen Datenbank läuft, darf kein Redakteur veröffentlichen, sonst geht diese Arbeit verloren (9.9).
• Ein vollständiges Backup der aktuellen Datenbank und der Dateien, bevor Sie beginnen.
• Der neue Datenbankserver, eine leere Datenbank und ein Benutzer mit dem Recht, Tabellen anzulegen.
• Eine Generalprobe auf einer Kopie, mit Zeitmessung.

Zwischen den SQL-Engines #

Die Schema-Werkzeuge ziehen eine Datenbank zwischen SQLite 3, PostgreSQL, MariaDB, MySQL und (mit ezoracle) Oracle über das von der Engine unabhängige Format .dba von Exponential um. --type nimmt einen Schema-Handler aus settings/dbschema.ini: mysql, postgresql, sqlite3, oracle.

# 1. maintenance on
php bin/php/maintenance.php on --message="Database maintenance" --until=1h --allow-root-user

# 2. 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

# 3. load them into the new one (PostgreSQL in this example)
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

Für SQLite 3 ist das Datenbankargument der Dateiname, wie in der Einstellung Database. Führen Sie beide Skripte zuerst mit --help aus; dort stehen die Optionen je Engine (Host, Port, Socket, Tabellentyp, Zeichensatz).

Warnung --password= setzt das Passwort auf die Kommandozeile, wo andere Benutzer der Maschine es in der Prozessliste sehen können. Führen Sie die Übertragung auf einer Maschine aus, die Sie kontrollieren, oder mit einem temporären Passwort, das Sie danach ändern (9.9).

Nach Oracle oder MongoDB #

• Oracle: Die Erweiterung ezoracle hat eigene Übertragungsbefehle, ext:ezoracle:mysql2oracle-schema und ext:ezoracle:mysql2oracle-data (Oracle für Hoster).
• MongoDB: die Skripte in bin/mongodb/ (export_mysql.sh, mysql2ndjson.py, import_all.sh, validate_ndjson.sh). Prüfen Sie die Grenzen von MongoDB gegen die Erweiterungen des Kunden, bevor Sie den Wechsel zusagen (MongoDB für Hoster).

Zu ändernde Einstellungen #

In settings/override/site.ini.append.php, Block [DatabaseSettings]: DatabaseImplementation und die Schlüssel der Verbindung (Server, Port, Benutzer, Passwort, Datenbank). Ein vergessenes DatabaseImplementation ist der übliche Grund, warum nach einem Wechsel keine Seite lädt (9.9). Die Schlüssel je Engine stehen auf Die Einstellungen: DatabaseSettings in site.ini.

Leeren Sie dann jeden Cache und starten Sie die Worker neu:

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

Unter PHP-FPM laden Sie stattdessen den PHP-FPM-Dienst der Website neu.

Prüfungen vor dem Wiederöffnen #

1. Zählen Sie die Zeilen von ezcontentobject, ezcontentobject_tree und ezcontentobject_attribute auf beiden Seiten; die Zahlen müssen übereinstimmen.
2. Korrigieren Sie auf PostgreSQL die Sequenzen, wenn ezsqlinsertschema.php ein Problem damit gemeldet hat (9.4).
3. Melden Sie sich in der Administration an, öffnen Sie einige Seiten und veröffentlichen Sie ein Testobjekt: Eine Veröffentlichung prüft die Schreibvorgänge, die ein Seitenaufruf nicht prüft.
4. Schalten Sie den Wartungsmodus aus: php bin/php/maintenance.php off --allow-root-user.
5. Stellen Sie den Backup-Job auf das Werkzeug der neuen Engine um (Datenbank-Backups je Engine).

Spätere Upgrades #

Schema-Updates gelten je Engine: Update-Dateien werden nach der Engine gewählt, auf der die Website jetzt läuft, nicht nach der, auf der sie installiert wurde (update/database/mysql/, update/database/postgresql/, update/database/sqlite/ und für Oracle die Dateien in ezoracle; MongoDB hat keine SQL-Update-Dateien). Halten Sie die neue Engine im Datensatz des Kunden fest.

Verwandte Seiten #

• Datenbanken in der offiziellen Reihenfolge
• Eine Website zwischen Hostern umziehen
• Kapitel 9: Datenbanken
• Migrationen oder Umzug einer Site
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.