Eine Datenbank wiederherstellen #

Diese Seite richtet sich an Datenbankadministratoren, die eine Exponential-Datenbank wiederherstellen, nach einem Ausfall, einem misslungenen Upgrade oder für einen Wiederherstellungstest. Sie beantwortet: in welcher Reihenfolge Sie anhalten, wiederherstellen und neu starten, welcher Befehl jede Engine wiederherstellt, was danach geleert werden muss und was Sie prüfen, bevor die Website wieder öffnet. Quellen: 10.9 Wiederherstellung und SQLite sichern und wiederherstellen.

Inhalt #

1. Bevor Sie beginnen
2. Das Verfahren
3. Der Wiederherstellungsbefehl je Engine
4. SQLite: .restore oder die Datei ersetzen
5. Nach der Wiederherstellung
6. Prüfungen vor dem Wiederöffnen
7. Wiederherstellungen testen
8. Checkliste

Bevor Sie beginnen #

• Wissen Sie, welche Sicherung Sie wiederherstellen und dass die Dateisicherung (var/storage, settings/override) vom selben Zeitpunkt stammt.
• Behalten Sie eine Kopie der aktuellen, defekten Datenbank: Sie brauchen vielleicht später etwas daraus.
• Informieren Sie die Redakteure: Alles, was nach der Sicherung veröffentlicht wurde, geht verloren.

Das Verfahren #

1. Wartungsmodus an, damit niemand schreibt:

   php bin/php/maintenance.php on --message="Restoring" --allow-root-user

2. Unter Velocity den Server anhalten, damit kein Worker die alte Datenbank hält:

   php bin/php/console exp:velocity stop --allow-root-user

3. Die Datenbank wiederherstellen (nächster Abschnitt) und die Dateien über die Installation entpacken; Eigentümer und Modus korrigieren.

4. Jeden Cache leeren und die Autoloads neu erzeugen:

   php bin/php/ezcache.php --clear-all --allow-root-user
   php bin/php/ezpgenerateautoloads.php -e

5. Velocity starten, seinen Antwort-Cache leeren, den Wartungsmodus ausschalten, Startseite und Administration öffnen:

   php bin/php/console exp:velocity start --allow-root-user
   php bin/php/console exp:velocity cache clear --apply --allow-root-user
   php bin/php/maintenance.php off --allow-root-user

Der Wiederherstellungsbefehl je Engine #

SQLite: .restore oder die Datei ersetzen #

Prozesse halten die Datenbank offen: PHP-FPM-Worker, während sie eine Anfrage bearbeiten, Velocity-Worker während ihrer ganzen Lebensdauer. Stellen Sie über die eigenen Sperren von SQLite wieder her, statt die Datei unter ihnen zu ersetzen. .restore kopiert die Sicherung Seite für Seite unter einer Schreibsperre in die laufende Datenbank und gibt bei Erfolg nichts aus.

Meldet es einen Fehler (ein Schreiber hielt die Sperre, oder die Sicherung hat eine andere Seitengröße, die eine Datenbank im WAL-Modus nicht übernehmen kann), ist die laufende Datenbank unverändert. Ersetzen Sie dann die Datei: Halten Sie jeden Prozess an, der sie geöffnet haben kann (Velocity, PHP-FPM, Cron), verschieben Sie die alte Datenbank und ihre Dateien -wal und -shm gemeinsam zur Seite, legen Sie die Sicherung an ihren Platz, korrigieren Sie Eigentümer und Modus (SQLite-Dateien, Eigentümer und Rechte) und starten Sie die Prozesse wieder.

Nach der Wiederherstellung #

• Caches: Sie enthalten noch Seiten, die aus den Inhalten vor der Wiederherstellung erzeugt wurden. ezcache.php --clear-all leert die Caches des Kernels einschließlich des SQL-Abfrage-Cache; um nach einem Schreibzugriff außerhalb von Exponential nur diesen zu leeren: php bin/php/ezcache.php --clear-id=querycache --allow-root-user (Der SQL-Abfrage-Cache).
• Sequenzen: Ein vollständiges pg_restore stellt sie mit den Daten wieder her; nach der Wiederherstellung ausgewählter Tabellen korrigieren Sie sie (PostgreSQL betreiben). Auf Oracle meldet ext:ezoracle:sequence-sync --dry-run Sequenzen, die hinter ihren Tabellen zurückliegen.
• Suchindex: Waren die Tabellen des Suchindex nicht in der Sicherung, oder nach der Wiederherstellung in eine andere Engine, bauen Sie ihn mit php bin/php/updatesearchindex.php --clean --allow-root-user neu auf (Die Tabellen des eingebauten Suchindex).
• MongoDB: Führen Sie bin/mongodb/create_indexes.js aus, wenn die Indizes nicht wiederhergestellt wurden.

Prüfungen vor dem Wiederöffnen #

• Die Versionszeile passt zum Code: SELECT name, value FROM ezsite_data WHERE name LIKE 'ezpublish-%';
• Die Zeilenzahlen von ezcontentobject, ezcontentobject_tree und ezcontentobject_attribute sehen wie erwartet aus.
• Melden Sie sich in der Administration an, öffnen Sie einige Seiten, veröffentlichen Sie ein Testobjekt (eine Veröffentlichung übt die Schreibzugriffe, die ein Seitenaufruf nicht ausführt) und löschen Sie es.
• var/log/error.log zeigt nichts Neues.

Wiederherstellungen testen #

Testen Sie eine Wiederherstellung mindestens einmal und nach jedem größeren Upgrade auf einer anderen Maschine. Eine praktische Übung:

1. Bringen Sie die Sicherung der letzten Nacht auf eine Staging-Maschine.
2. Stellen Sie sie mit diesem Verfahren wieder her; messen Sie die Zeit jedes Schritts.
3. Führen Sie die Prüfungen oben aus.
4. Notieren Sie die benötigte Zeit und was fehlte; das ist Ihre echte Wiederherstellungszeit.

Betriebsanleitungen für Hosting-Personal: Wiederherstellung und Wiederherstellungstests und Aus einer Sicherung wiederherstellen.

Checkliste #

• To do: Wartungsmodus an; Velocity angehalten.
• To do: Datenbank und Dateien vom selben Zeitpunkt wiederhergestellt.
• To do: Alle Caches geleert, auch der Antwort-Cache von Velocity.
• To do: Sequenzen, Suchindex und MongoDB-Indizes geprüft.
• To do: Versionszeile, Zeilenzahlen, Anmeldung und eine Testveröffentlichung geprüft.
• To do: Wartungsmodus aus.

Verwandte Seiten #

• Sicherungen je Engine
• Datenbankfehler beheben
• Wenn etwas schiefgeht
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.