Skip to the content
Documentation
Help Start
Reading in:
  • German: 9,059 of 9,059 pages
About the help in other languages
All help pages

Upgrades und die SQL-Update-Dateien

Wie die Datenbank-Update-Dateien von Exponential je Engine und Version in update/database geordnet sind, welche Kette eine Datenbank von 3.10 bis 6.0.15 durchläuft, die Regeln für ihre Anwendung, die Verzeichnisse 6.12…

Download as PDF

Address: https://doc.exponential.earth/exphelp/viewer/help/database-administrators/upgrades-and-sql-update-files.md

On this page

This page is a translation. Read the English original

Upgrades und die SQL-Update-Dateien

Diese Seite richtet sich an Datenbankadministratoren, die den Datenbankteil eines Exponential-Upgrades anwenden. Sie beantwortet: wo die Update-Dateien liegen, welche eine Datenbank braucht, die Regeln für ihre Anwendung, welche Verzeichnisse nie angewendet werden dürfen und wie Sie erkennen, auf welcher Version eine Datenbank steht. Das Kapitel Schritt für Schritt ist Kapitel 11, Aktualisieren; die Anleitung für Administratoren ist Aktualisieren.

Inhalt

  1. Auf welcher Version steht die Datenbank?
  2. Wo die Update-Dateien liegen
  3. Die Kette
  4. Regeln
  5. Verzeichnisse, die Sie nicht anwenden dürfen
  6. Hinweise je Engine
  7. Die Update-Dateien selbst prüfen
  8. Checkliste

Auf welcher Version steht die Datenbank?

Der Code und die Datenbank tragen jeweils eine Version; nach einem korrekten Upgrade stimmen sie überein.

php bin/php/console --version
mysql -u USER -p DATABASE -e "SELECT name, value FROM ezsite_data WHERE name LIKE 'ezpublish-%';"
psql -U USER DATABASE -c "SELECT name, value FROM ezsite_data WHERE name LIKE 'ezpublish-%';"
sqlite3 var/storage/sqlite3/exponential.db "SELECT name, value FROM ezsite_data WHERE name LIKE 'ezpublish-%';"

Eine aktuelle Website gibt ezpublish-version 6.0.15stable und ezpublish-release 1 aus. Die Zeilennamen behalten ihre historische Schreibweise mit Absicht: Sie sind Bezeichner, in die jede Update-Datei schreibt. Setup > Systeminformationen zeigt ebenfalls beide Versionen (11.2).

Wo die Update-Dateien liegen

EngineVerzeichnisSchritte
MySQL, MariaDBupdate/database/mysql/3.10 auf 4.0 ... 5.4, dann 6.0/dbupdate-5.4.0-6.0.0.sql, dann 6.0/dbupdate-6.0.0-6.0.15.sql
PostgreSQLupdate/database/postgresql/dieselbe Kette; der Schritt 5.4 ist 6.0/dbupdate-5.4-to-6.0.sql, dann 6.0/dbupdate-6.0.0-6.0.15.sql
SQLiteupdate/database/sqlite/nur 6.0/dbupdate-6.0.0-6.0.15.sql (die SQLite-Unterstützung beginnt mit 6.0.1)
Oracleextension/ezoracle/update/database/ezpublish/ für die Kernel-Kette bis 5.3, ezoracle/ für die eigenen Tabellen des Treibers
MongoDBkeinesdie Audit-Collections von 6.0.15 kommen aus createaudittables.php

Die Kette

Jede Datei bringt eine Datenbank von einer Version auf die nächste. Eine Datenbank durchläuft die Kette der Reihe nach, jede Datei einmal:

Sie betreibenWeg
3.10 bis 5.3die alte Kette bis 5.4, dann auf 6.0.0, dann auf 6.0.15
5.4.0 oder 5.90auf 6.0.0, dann auf 6.0.15
6.0.0 bis 6.0.14dbupdate-6.0.0-6.0.15.sql

Die vollständige Tabelle der Dateien von 4.0 bis 5.4 steht in 11.3. Wenden Sie eine Datei mit dem Client der Datenbank an:

mysql -u USER -p DATABASE < update/database/mysql/6.0/dbupdate-6.0.0-6.0.15.sql
psql -U USER -d DATABASE -f update/database/postgresql/6.0/dbupdate-6.0.0-6.0.15.sql
sqlite3 var/storage/sqlite3/exponential.db < update/database/sqlite/6.0/dbupdate-6.0.0-6.0.15.sql

Regeln

  • Zuerst sichern und wissen, wie Sie wiederherstellen (Eine Datenbank wiederherstellen).
  • Der Reihe nach, jede einmal. Eine Anweisung, die scheitert, weil eine Spalte oder Tabelle schon existiert, bedeutet, dass die Datei schon einmal angewendet wurde: Halten Sie an und vergleichen Sie mit der Sicherung.
  • Eine Datei, die mittendrin scheitert: Stellen Sie die Sicherung wieder her und wenden Sie die Datei von vorn an; reparieren Sie nicht von Hand.
  • Cluster-Dateien: Verwendet die Installation den DFS-Cluster, wenden Sie auch die Datei dbupdate-cluster-... desselben Schritts an (MySQL: 4.3, 4.7, 5.2, 5.4).
  • unstable/-Verzeichnisse enthalten Dateien von Vorabversionen; wenden Sie sie nie auf eine Website an, die ein finales Release betrieben hat.
  • Je Engine: Eine Website, die auf eine andere Engine umgezogen ist, verwendet die Update-Dateien der Engine, auf der sie jetzt läuft.

Verzeichnisse, die Sie nicht anwenden dürfen

update/database/<engine>/6.12/, 7.2/ und 7.3/ stammen aus dem Upstream-Legacy-Kernel von 2016 bis 2018, nummeriert nach einer Version eines Symfony-Kernels, nicht nach einem Legacy-Release. Als Dateien angewendet, würde jede die Versionszeile durch eine Zahl ersetzen, die keine Exponential-Version ist. Ihre Änderungen (das breitere ezuser.password_hash, ezcontentobject_trash.trashed und auf PostgreSQL die Sequenznamen <table>_<column>_seq) stecken bereits in den Dateien 6.0 (11.3).

Hinweise je Engine

EngineHinweis
MySQL, MariaDBDateien beginnen mit SET default_storage_engine=InnoDB;. Kopien von vor Oktober 2026 enthielten SET storage_engine=InnoDB;, entfernt in MySQL 5.7.5 und MariaDB 12.0: Nehmen Sie die aktuellen Dateien. Tabellen müssen UTF-8 und InnoDB sein (MySQL und MariaDB: utf8mb4).
PostgreSQLAbgesicherte Schritte sind DO-Blöcke (PostgreSQL 9.0+); digest() aus pgcrypto muss existieren.
SQLiteJedes ALTER TABLE fügt eine Spalte hinzu, und SQLite hat kein ADD COLUMN IF NOT EXISTS: Ein zweiter Lauf scheitert mit "duplicate column name". Führen Sie die Datei einmal aus, nach einer Online-Sicherung.
OracleDie eigenen Dateien der Erweiterung bis 5.3; die Audit-Tabellen von 6.0.15 aus createaudittables.php.
MongoDBKein SQL; die Upgrade-Prüfung gibt die mongosh-Befehle für fehlende Collections aus.

Die Update-Dateien selbst prüfen 

php bin/php/console exp:checkdbfiles --no-verify-branches

Es prüft die Update-Dateien gegen den Upgrade-Weg, jedes Verzeichnis von 4.0 bis 7.3 auf jeder Engine, und gibt je Problem eine Zeile aus: ! für eine fehlende Datei, ? für eine überzählige. Keine Ausgabe bedeutet, dass die Dateien vollständig sind. Ohne --no-verify-branches versucht es außerdem ein stillgelegtes SVN-Repository und gibt eine Zeile C aus; ignorieren Sie sie oder fügen Sie die Option hinzu.

Checkliste

  • To do: Versionszeile vorher und nachher gelesen.
  • To do: Sicherung erstellt und Wiederherstellung bekannt.
  • To do: Nur die Dateien Ihrer Engine und Ihres Weges, der Reihe nach, jede einmal.
  • To do: Keine Datei aus 6.12/, 7.2/, 7.3/ oder unstable/ angewendet.
  • To do: Cluster-Dateien angewendet, wo der Cluster verwendet wird.
  • To do: exp:checkdbfiles gibt nichts aus.

Verwandte Seiten

Werden Sie Exponential-Partner

Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.

Partner: hier beginnen Wie Sie sich bewerben

Something wrong on this page? Report an error

Documentation license

This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.

Exponential Copyright © 1998-2026 Exponential Foundation and 7x