Die Updatefalle - Was man beim Update beachten muss

Last edited by DSB on 2009-06-07, 20:00; edited 18 times in total

Im Laufe unserer "Karriere" als Supporter in Sachen MySQL-Backups sind wir nun mit einigen immer wiederkehrenden Fehlern konfrontiert worden. Einer der häufigsten Fehler ist dabei das "Update" von z.B. einer Forensoftware bei gleichzeitiger Übernahme der MySQL-Daten aus der Vorgängerversion.

Deshalb versuche ich hier kurz die Grundlagen zu erklären. Ich hoffe, das gelingt mir auf eine verständliche Weise.
Die folgenden Angaben gelten für jede Art von Software (egal ob CMS, Onlineshop oder Boardsoftware), die aktualisiert wird und die Daten in einer Datenbank ablegt (auch unabhängig davon welche Datenbank letzlich benutzt wird). Da die meisten aber zunächst mit einer Boardsoftware in Berührung kommen, erkläre ich das beispielhaft an einem Forum.

Bei einer Boardsoftware haben wir 2 Seiten:
Die eine besteht aus den ganzen Dateien, die man auch per FTP auf den Webspace befördert.
Diese Dateien kümmern sich um die Logik.
Hier werden Eingaben ausgewertet und die Webseiten vom Layout her generiert.
Diese Dateien ändern sich nicht. Sie haben auch immer die gleiche Größe und regeln das Befüllen and Abfragen der MySQL-Datenbank.

Die zweite Seite ist die MySQL-Datenbank.
Diese nimmt alle Bewegungsdaten auf. Immer wenn ein User ein Posting absetzt, dann wird das nicht in den Dateien, sondern
eben in der Datenbank abgelegt. Die Datenbank läuft völlig unabhängig vom Restforum auf einem eigenen Server - dem MySQL-Server.
Diese Daten kann man deshalb auch nicht einfach per FTP vom Webspaceserver runterladen.
Sie liegen woanders eben auf dem MySQL-Server.

Wer also glaubt, dass er nur alle Dateien seines Webspace per FTP auf seiner Festplatte laden braucht und dann ein komplettes Backup seines Forums hat, ist völlig auf dem Holzweg!
Er hat dann lediglich die nicht veränderten Dateien der Boardsoftware gesichert (im unteren, ersten Bild die linke Seite - die rechte Seite fehlt dann), was letztlich gar nichts bringt, weil sie den gleichen Inhalt, wie zur Installationszeit des Forums haben.
Es befindet sich weder ein Posting, noch die Userdaten in diesem Backup, denn sie sind im MySQL-Server gespeichert.

Wie kann man nun ein Backup seiner Postings, User und sonstigen Tabellen machen?
Man braucht eine Software, die in der Lage ist die MySQL-Datenbank auszulesen.
Genau das macht MySQLDumper.

Aber ich wollte euch die Zusammenhänge erklären...
Wenn die erste Seite (also die PHP-Dateien) eine Seite generiert, dann holt sie sich die Informationen über User und den geposteten Text von der Datenbank. Man muss sich das wirklich vorstellen, wie 2 Menschen die sich unterhalten.

Angenommen ein Block auf der Portalseite will Textausschnitte der letzten 5 Postings anzeigen, dann fragt PHP die MySQL-DB:
"Hallo DB, nenne mir mal alle Texte aus der Tabelle `postings`, absteigend sortiert nach der Spalte Erstellungsdatum,
aber nenne mir nur die 5 letzten Einträge."
Übersetzt auf "SQL" heisst das dann: SELECT * FROM `postings` ORDER BY ´erstellungsdatum` DESC LIMIT 5

Die Datenbank antwortet dann mit den entsprechenden Datensätzen und übergibt die Texte und sonstigen Daten an die PHP-Dateien.

PHP nimmt die Daten entgegen, speichert sie in Variablen und zeigt sie dann letztlich auf der Webseite an.
Damit können die statischen Dateien von PHP die Inhalte der Datenbank an entsprechenden Stellen einsetzen.
Wenn Du Dir also ein Posting in einem Board ansiehst, dann ist die PHP-Datei, die das anzeigt (z.B. viewtopic.php) immer die gleiche!
Aber der zurückgemeldete Text kommt aus der Datenbank und damit sieht die Seite bei jedem Posting eben anders aus.

Ich will hiermit zeigen, dass es sich um 2 unabhängige Systeme handelt, die über die Sprache SQL miteinander kommunizieren.

Was hat das nun alles mit der Updateproblematik zu tun?

Um das zu verstehen muss ich Dich zunächst noch etwas mit Grundwissen nerven. Very Happy

Schauen wir uns einmal genau an, was bei der Installation einer Boardsoftware passiert:
Du hast Dir also gerade eine Boardsoftware heruntergeladen, entpackt und wie in der Installationsanleitung (die Du selbtsverständlich und mit 100%iger Sicherheit natürlich gaaaaaanz genau gelesen hast!) angegeben, per FTP
auf Deinen Webspace hochgeladen.
Nach dem Upload der Dateien (aber vor dem Start der Installation) sieht das wie folgt aus:

Nun startest Du die entsprechende Installationsdatei. Diese will zunächst die erforderlichen Tabellen in der Datenbank anlegen.
Die Tabellen nehmen dann alle Bewegungsdaten auf. Das sind zum Beispiel die User, ihre Einstellungen, die Texte der Postings und vieles mehr.

Damit die PHP-Dateien aber überhaupt mit dem MySQL-Server kommunizieren können, musst Du ihnen mitteilen, mit welchen Zugangsdaten diese das tun müssen. Bei jeder Datenbankverbindung werden diese Authentisierungsdaten angegeben, und nur wenn diese stimmen, antwortet der MySQL-Server.
Damit auch der richtige MySQL-Server angesprochen wird, muss man der Boardsoftware auch den URL des MySQL-Servers mitteilen.
Wir erinnern uns: der MySQL-Server ist ein eigenständiger Server, der sich physikalisch auf einer anderen Maschine (ja sogar in einem anderen Land) befinden kann (aber nicht muss).
Bei den Anbietern, die den MySQL-Server auf der gleichen Maschine laufen lassen, wie den Webserver selbst, reicht die Angabe "localhost". Bei allen anderen muss man den richtigen URL eingeben.

Wir sind also nun an der Stelle, wo man folgende Daten angeben muss:
MySQL-Server: das ist der URL des MySQL-Servers, zb. "localhost" oder "www.sql.anbieter.de"
MySQL-User: der Benutzername des MySQL-Users - diese Angabe erhält man vom Webspaceanbieter, der diesen User extra für Dich eingerichtet hat
MySQL-Passwort: das Passwort für den User - erhält man auch vom Anbieter
MySQL-Datenbank: der Name der MySQL-Datenbank, die die Daten aufnehmen soll; kommt auch vom Anbieter oder mit erweiterten Rechten
darf man sich selbst eine oder sogar mehrere Datenbanken anlegen

Stimmt eine der Angaben nicht, so zeigt einem der MySQL-Server eine lange Nase und lässt keine Verbindung zu! Liar

Das Ergebnis ist natürlich, dass es jede Menge Fehlermeldungen hagelt.
Kein Script dieser Welt kann Daten in einer MySQL-DB speichern oder abfragen, wenn die Zugangsdaten nicht stimmen.
Leider zeigt die Praxis, dass viele User hier bereits überfordert sind und nicht genau wissen, was sie dort angeben müssen. Viele versuchen ihre FTP-Zugangsdaten einzugeben, was an dieser Stelle natürlich falsch ist.
Die FTP-Daten sind zur Authentifizierung beim FTP-Server und die MySQL-Daten eben zur Authentifizierung beim MySQL-Server!
Ich hoffe, dass ist nun etwas klarer und Du gibst die richtigen Zugangsdaten an. Very Happy

"Intelligente" PHP-Programme (wie z.B. der MySQLDumper *g*) prüfen die Eingaben des Users direkt nach der Eingabe und bauen eine Testverbindung zur MySQL-DB auf. Schlägt diese fehl, wird dem User das Formular wieder vorgelegt, damit er seine Angaben korrigieren kann.

Ok, jetzt hast Du also die richtigen Daten angegeben und das PHP-Script kann sich erfolgreich am MySQL-Server anmelden.
Dann werden im nächsten Schritt die benötigten Tabellen angelegt, die später die Daten aufnehmen. PHP beauftragt MySQL bestimmte Tabellen einzurichten, in denen dann später die Daten abgelegt werden.

Nach diesen Installationsanweisungen sieht das dann ungefähr so aus:

Du siehst also, dass sich die Boardsoftware die Tabellen so einrichtet, wie sie sie benötigt. Nun kannst Du die Boardsoftware aufrufen und Dein Forum funktioniert.

Nachdem sich nun endlich einige User im Forum angemeldet haben und auch die ersten sinnvollen Gespräche im Forum laufen, möchtest Du gern ein Backup Deiner wertvollen Daten haben und benutzt z.B. den MySQLDumper, um eine Sicherung zu erstellen.
Bis jetzt ist noch alles in bester Ordnung.

Jetzt entdeckst Du, dass es ein Update der Boardsoftware gibt und willst natürlich auch up to date sein.
Du installierst also die neue Software - das klappt einwandfrei.
Dann benutzt Du MySQLDumper, um die Sicherung der Datenbank auf dem MySQL-Server einzuspielen - auch das klappt einwandfrei.

Nun willst Du Dein neues Forum aufrufen und - was ist das? - erhältst Fehlermledungen, die Du vorher noch nie gesehen hast.
Z.B. sowas wie "unknown column 'xxx' oder 'cannot initiate session'.
Was ist schief gelaufen?

Ganz einfach:
die neue Version der Boardsoftware hat Erweiterungen eingebaut. Es gibt zusätzliche Möglichkeiten, bei denen auch zusätzliche (neue) Daten in der Datenbank abgelegt werden.

Nehmen wir als Beispiel eine Geburtstagsliste.
Gehen wir davon aus, dass in der alten Version keine Geburtstage angegeben werden konnten und dies als neues Feature nun in der neuen
Version geht. Natürlich muss der Geburtstag jedes Users auch irgendwo gespeichert werden. Das geschieht natürlich in der MySQL-Datenbank (logischer- und sinnigerweise in der Tabelle `User`).
In der alten Version gab es aber noch keine Spalte Geburtstag - in der neuen Version aber schon.

Jetzt haben wir die Konstellation, dass die neue Boardsoftware versucht die Spalte `geburtstag` beim MySQL-Server abzufragen.
Dieser schaut in die Tabelle `user`, findet diese nicht (weil wir ja eine Backup der alten Version ohne diese Spalte in der DB haben) und gibt uns korrekterweise die Fehlermeldung zurück: 'unknown column `geburtstag`'.
Oder zu deutsch: die Spalte `geburtstag` ist mir nicht bekannt.

Halten wir also fest:
man kann nicht einfach ein Update der PHP-Dateien vornehmen und dann "hoffen", dass diese einwandfrei mit dem MySQL-Server
zusammenarbeiten. Das geht mit fast 100%iger Wahrscheinlichkeit, wie oben beispielhaft beschrieben, schief.

Wie macht man nun ein korrektes Update?
Nun, das Problem ist, dass die Struktur der MySQL-Tabellen eben auch an die neue Boardsoftware angepasst werden muss.
Jeder Boardsoftwareanbieter bietet dazu in seinem Softwarepaket spezielle Updateroutinen an, die genau das erledigen.
Sie enthalten Befehle, um die MySQL-Tabelle um das gewünschte Feld `geburtstag` zu erweitern und müssen lediglich einmal aufgerufen werden.
(Die entsprechenden SQL-Anweisungen beginnen mit "ALTER TABLE `xxx` ..." und haben nichts mit dem Alter der Tabellen zu tun Very Happy

, sondern bedeuten :"Bearbeite Tabelle `xxx`...)

Die richtige Vorgehensweise ist also:
- Zuallererst ein Backup der vorhandenen Daten machen, damit man im Notfall (falls doch etwas schief geht) diese Sicherung wieder einspielen kann - und zwar sowohl von den Dateien auf dem Webspace per FTP, als auch der Daten in der Datenbank per z.B. MySQLDumper
- Wenn es sich um einen Umzug zu einem neuen Server handelt: Backup der alten Datenbank in den MySQL-Server einspielen
- PHP-Dateien der neuen Software per FTP auf den Webspace laden
- die Updateroutine (nicht die Routine für eine Neuinstallation) aufrufen, die dem Versionswechsel von alt auf neu entspricht
- Fertig!

Wenn man sich daran hält und vor allem zunächst in aller Ruhe die Installations- bzw. Updateanleitung durchliest, dann ist das kein Problem. Wenn man 5 Minuten länger liest und sich informiert, hat man höchstwahrscheinlich mehrere Stunden an
aufwändiger Fehlersuche gespart.

Ich hoffe, dass Dir meine kleine Grundsatzerklärung den Zusammenhang etwas verdeutlichen konnte.
Und der nächste, der mir im Board erzählt, dass MySQLDumper nicht vernünftig funktioniere, und ich dann dahinterkomme, dass es sich nur um den oben erwähnten Userfehler handelt, dem reiße ich persönlich virtuell den Kopf ab. :-)
Wer nicht liest und wild drauflosinstalliert ist selbst schuld.

Vielleicht kann ich mit dem kleinen Tutorial hier einige Pannen vermeiden.

Fröhliche Installationsgrüße,

Euer Daniel

**Donator** Joined: 12 Jan 2005 Posts: 202 Location: Köln

Lieber Daniel,

Kompliment und danke schön für diese wirklich verständliche Aufklärung. Du hast dir sehr viel Arbeit gemacht. clap

Grüße
Fabio

**MySQLDumper-Translator** Joined: 16 Nov 2005 Posts: 91

Super Erklärung habe viel dazugelernt, macht weiter so... und danke Wink

Posted: 2005-11-18, 00:55 Re: Die Updatefalle

Yo Daniel, fein gemacht. clap

mich erschreckt es auch jedesmal wenn ich im "offiziellen phpbb2.de" Board bin Shocked

Posted: 2005-11-18, 01:35 Re: Die Updatefalle

Posted: 2005-11-18, 10:31 (No subject)

Beispiel: Jemand hat eine Board SW installiert mit Modifikationen....macht ein update...."DB Änderungen" und danach wird mit MysqlDump die alte DB eingspielt und die neuen Änderung gekillt.....und wundert sich dann, das Fehlermeldungen kommen.

Posted: 2005-11-18, 10:36 (No subject)

oder ganz einfach...User benutzt Board SW phpbb2 2.10.8, löscht diese, instaliert phpbb2 Plus 1.52 2.10.18 und überspielt danach die neu angelegten DB Tabellen mit dem DB Backup vom phpbb2 2.10.8

Boing......kommt leider sehr sehr oft vor

Posted: 2005-11-18, 12:00 Re: Die Updatefalle

Ach so meinst Du das.
Ja, damit man das versteht, habe ich mir die Mühe mit dem langen Artikel gemacht.
Ich hoffe, so kann man leichter erklären warum die "Probleme" auftreten.
Künftig poste ich auch immer nur noch einen Link auf diesen Artikel.
Es ist anstrengend das immer wieder aus Neue zu erklären. Wink

**knows MySQLDumper** Joined: 12 Apr 2006 Posts: 8

Wahnsinn! Vielen vielen Dank für diese Informationen! Ich speichere sie mir auf meinem PC - und werde sie gründlich studieren.

Ich weiß es nervt immer die gleichen Fragen zu hören... ich benutze auch immer die Suche, aber auf solchen Schätzen lande ich leider nie :-(

Danke nochmal für die Infos - UND für das Proggy (irgendwer hat das ja geschrieben!).

Posted: 2006-04-12, 19:49 (No subject)

Danke für Dein nettes Feedback.
Wenn es Dir geholfen hat den ein oder anderen Zusammenhang besser zu verstehen, dann hat es sich aus meiner Sicht schon gelohnt den Artikel zu verfassen.

Posted: 2006-08-10, 18:27 (No subject)

Ich hätte da noch eine Anregung für ein folgendes Dumper-Release...

Wie wäre ein Tool das es ermöglicht, die Tabellenstruktur abzugleichen?
Ablauf folgendermaßen:
BB-Forum alt mit Mods = erweiterte Tabellen (z.B. Feld "birthday" in phpbb_user)
BB-Forum neu ohne Mods = neue Felder durch neue Version, wegfall der MOD-Felder

1. Schritt: Struktur-Backup der alten Datenbank, und separates Datenbackup, sowie einmal komplett (sicher ist sicher).
2. Schritt: Forensoftware-Update / DB-Update
3. Schritt: Abgleich der neuen Struktur mit der alten zuvor gesicherten.

Das Tool sollte so arbeiten, das die fehlenden Tabellenfelder ergänzt werden, damit man die zuvor separat gesicherten Daten wieder einspielen kann. Zusätzliche Felder die evtl. mit der neuen Foren-Version kamen dürften nicht stören, aber es stört sehr, wenn "alte" Felder fehlen, und das Backup deswegen dauernd stehen bleibt oder mit einer Fehlermeldung terminiert.

Beispiel: alte Felder im Backup: birthday,zodiak,foo,bar
Diese Felder sind nach dem Update weg, und werden vom Tool automatisch wieder eingefügt, ohne die bestehende Struktur der neuen Tabellen zu überschreiben, denn es werden ja nur fehlende Felder hinzugefügt.

Wehrmutstropfen: Wenn das Update Mods gekillt hat, muß man die ja neu Modden, aber wenigstens gehen die alten Daten dann nicht dabei drauf!

Posted: 2006-08-10, 19:01 (No subject)

Das hieße, man müßte jede einzelne Forensoftware und jedes Update und jede Tabellenzelle, die wegfällt oder hinzukommt kennen?
Das geht nicht.
Da ist es einfacher, wie DSB beschrieben hat.
1.) Backup
2.) Upgrade

Posted: 2006-08-12, 13:46 (No subject)

@Fraggy

Im Ansatz habe ich ein solches Script einmal programmiert.
Mit dem Script "write_definitions.php" wird aus einer bestehenden Datenbank die Struktur inklusive aller Datenbankfelder und ihrer genauen Definition in eine Datei geschrieben.

Mit dem Script "vergleichen.php" wird die Struktur aus der Datei mit einer Datenbank verglichen und sämtliche Unterschiede, fehlende Tabellen oder Felder genaustens aufgelistet (es werden keinerlei Daten verändert - nur eine Liste wird ausgegeben).
So hat man ganz schnell einen genauen Überblick darüber welche Felder sich geändert haben oder neu hinzugekommen sind.
Das Script löscht und ändert aber nichts an der DB, da Du als Admin wissen musst, ob neue Mods beabsichtigt sind oder nicht.
Aber es hilft schon einmal ernorm, um sich einen genauen Überblick zu verschaffen.

Gemünzt habe ich das damals auf ein Orion-Board, um damit alte, nicht mehr benötigte Felder in der DB-Struktur zu finden. Man kann damit aber jede beliebige DB-Struktur mit jeder anderen beliebigen DB-Struktur vergleichen. Vielleicht hilft das ja schonmal.

Hier das Script:

**knows MySQLDumper** Joined: 17 Sep 2006 Posts: 7

Posted: 2006-10-22, 14:57 (No subject)