Magento und die Wiederherstellung

**first backups** Joined: 24 Apr 2010 Posts: 1

Hallo liebe mysqldumper Gemeinde. Ich bin neu hier und gelange mit folgender Frage an Euch:

Für mich war es bis dahin nie ein Problem, meine Projekte mittels PHPmySQL zu sichern und wiederherzustellen. Auch sehr grosse Datenbanken, zum Beispiel von Typo3, konnte ich immer sichern und wiederherstellen.

Nun musste ich mich mit dem Shopsystem Magento näher auseinender setzen. Bevor ich mit einem Script arbeite, widme ich mich dem Sichern und der Wiederherstellung um die Arbeit nicht in den Wind zu setzen.

Ich verwende Magento 1.4.0.1 mit den Sampla Data 1.2.0. Die Datenbank hat ein Gewicht von 15.390 mbyte. Die Installation liegt auf einem hauseigenen Server mit Win2003 und Plesk in der neuesten Version.

Der Export funktioniert aus PHPmySQL. Der Import schlagt fehl. Meldung: execution Time 300 error, also die Zeit wurde überschritten. Natürlich habe ich die php.ini meines Servers längstens angepasst für grosse Typo3 Projekte.

Zum Beispiel so:

max_execution_time = 60000 ;
max_input_time = 60000 ;
memory_limit = 160M ;

Das Magento Problem führte mich zur Suche, daher kam ich auf diese Seite. Leider lässt sich auch mittels mysqldumper die DB nicht wiederherstellen. Ich habe eine neue Installation von Magento gesichert mit msd mit beiden Möglichkeiten, also 1 File und gesplittete Files. Auch ein mit PHPmySQL gesichertes File spielte ich mit msd zurück, was mit einer Endlose Schlaufe endete. In beiden Fällen keine Fehlermeldung, jedoch ist die Installation danach zerschossen.

Hat jemand Erfahrung mit der Sicherung und Wiederherstellung von Magento? Einen klaren Lösungsansatz habe ich nirgends gefunden, daher erlaube ich mir diesen Beitrag.

Gruss aus der Schweiz René

**knows MySQLDumper** Joined: 07 Jul 2010 Posts: 2

Hallo René, hallo Gemeinde,

wir haben gestern leider bittere Erfahrungen sammeln müssen im Bezug auf MySQLDumper und Magento. So wie es aussieht zerschießt MySQLDumper in der Version 1.24 irgendwas beim Zurückspielen. Zuerst war das Backend nicht mehr erreichbar (es ging zum Glück um eine Testinstallation um den Dumper zu testen). Magento neu aufgesetzt, Backup gemacht, Backup zurückgespielt, Benutzergruppe angelegt, beim Speichern plötzlich weiße Seite, System unbrauchbar. Gleicher Prozess ohne Backup und Wiederherstellung = Kein Problem. Die Probleme sind reproduzierbar.

Beim Backup (sowohl via Cron, als auch PHP), sowie dem Wiederherstellen werden seitens MySQLDumper übrigens keine Fehlermeldungen ausgegeben. Man wiegt sich also erstmal in Sicherheit, was natürlich im Prinzip noch problematischer ist.

Gerne hätten wir auch die 1.25 getestetet, aber da war im aktuellen SVN die Installationsroutine unbrauchbar.

Gibt es hier jemanden, der weitere Erfahrungen mit Magento und MySQLDumper hat oder auch andere Tools empfehlen kann? Wir müssen täglich etwa 100 DB's sichern, sowohl InnoDB als auch MyISAM.

Eigentlich sehr schade, da der MySQLDumper nach außen hin einen tollen Eindruck hinterläßt und gerade auch die 1.25 Lust auf mehr macht, aber wenn es unter der Haube so massive Probleme gibt ist ein Nutzung faßt ausgeschlossen.

Freue mich auf Feedback.

Viele Grüße,

ASchweti

Posted: 2010-07-07, 15:14 (No subject)

Das ist kein Problem von MySQLDumper, sondern ein ziemlich schrecklicher Design-Fehler in Magento. So weit ich weiß, benutzt Magento den Wert 0 für Primärschlüssel mit auto_increment. Das MUSS beim Einspielen Probleme geben, da MySQL beim Wert 0 in Feldern dieses Typs davon ausgeht, dass es den nächst höheren Index erzeugen soll.

Siehe: http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html#sqlmode_no_auto_value_on_zero

Du wirst das Problem also mit jedem Tool haben.
Selbst wenn man den Modus des SQL-Servers kurzfristig mittels "NO_AUTO_VALUE_ON_ZERO" beeinflusst, gibt das wieder die gleichen Probleme, wenn Du die Tabellen optimierst. Das muss also konzeptionell von Magento gelöst werden.

**knows MySQLDumper** Joined: 07 Jul 2010 Posts: 2

Hallo René,

danke für Deine sehr prompte Antwort. Sorry hatte keine Nachricht bekommen, dass Du geantwortet hast (evtl. Spamordner), was der Grund ist warum ich erst jetzt Deinen Post gelesen habe.

Wir haben bereits Magento-DB's manuell zurückgespielt, es muss also irgendwie gehen, wobei ich selbst nicht der Fachmann bin. Mein Entwickler wird sich das Thema nochmal im Detail anschauen. Vielleicht gibt es ja doch eine Möglichkeit MySQLDumper in der 1.25 "Magento-save" zu machen.

Prinzipiell hast Du natürlich recht, bei so kapitalen Designfehlern müßte eigentlich Magento reagieren. Wer allerdings schon in den Genuss gekommen ist sich mit Magento rumzuschlagen, der dürfte wissen, dass sich die Entwicklerfirma einen ziemlichen Dreck um die Open-Source-Gemeinde kümmert und wohl lieber die Enterprise Version promoted und Support verkauft für Bugfixes.

Wir melden uns nochmal mit unseren Analyseergebnissen...

Viele Grüße,

ASchweti

Posted: 2010-07-10, 16:53 (No subject)

**knows MySQLDumper** Joined: 17 Jul 2010 Posts: 2

Hallo Daniel,

vielen Dank für Deine ausführliche Antwort und Stellungnahme zum Thema.

Ich habe mir die Problematik nun auch noch einmal näher angeschaut und bin prinzipiell der Meinung, dass es mit wenig Mehraufwand möglich sein sollte, MySQLDumper sicher im Zusammenhang mit dem Backup und Restore von Magento-Datenbanken zu machen. Hierzu müsste lediglich für die Restore-Session die von Dir bereits angesprochene Server-System-Variable 'SQL_MODE' auf den Wert 'NO_AUTO_VALUE_ON_ZERO' gesetzt werden.

Optimal wäre meines Erachtens eine Erweiterung des Bereichs 'Konfiguration' in MySQLDumper um eine Checkbox o.Ä., die es erlaubt, diese Variable für alle Restore-Sessions zu setzen. Auf diese Weise könnte MySQLDumper problemlos auch Magento-Datenbanken wiederherstellen ohne die derzeit auftretende Problematik.

Du hast sicherlich Recht damit, dass die Verwendung des Wertes 0 für ein AUTO_INCREMENT-Feld in MySQL nicht empfehlenswert ist. Dennoch ist die Verwendung grundsätzlich möglich und es existiert mit Magento auch zumindest eine weit verbreitete Anwendung, die solche Werte benutzt. Insofern denke ich schon, dass sich eine erfolgreiche Backup-Software der normativen Kraft des Faktischen beugen sollte und zumindest eine optionale Unterstützung für solche Produkte hinzugefügt werden könnte.

Ich verstehe allerdings Deine Argumentation sehr gut, denn auch ich als Entwickler lege großen Wert auf saubere Softwaredesigns und betrachte den gegenwärtigen Zustand von Magento als suboptimal. Wie aber einer meiner Vorredner schon sehr richtig geschrieben hat, ist es eher unwahrscheinlich, dass sich die hinter Magento stehende Firma dieses Problems in absehbarer Zukunft annehmen wird. Die Liste der offenen Bugs spricht für sich...

Grundsätzlich halte ich Deinen Vorschlag bezüglich des globalen Aktivierens des SQL_MODE 'NO_AUTO_VALUE_ON_ZERO' für den gesamten Server für problematisch. Zwar hätten wir als Hoster prinzipiell root-Zugriff auf unsere MySQL-Server, doch könnte das globale Aktivieren dieses Modus negative Auswirkungen auf andere Software haben, die den Wert 0 in AUTO_INCREMENT-Feldern verwendet, um den Server anzuweisen, eine neue automatische ID zu generieren. Auch das wäre meiner Meinung nach schlechter Stil, aber eben dennoch nicht auszuschließen.

Es wäre nett, wenn Du nochmal über meinen Vorschlag bezüglich des Setzens des genannten SQL_MODE in den Restore-Sessions von MySQLDumper nachdenken könntest. Da diese Änderung generell keine negativen Auswirkungen auf Restore-Sessions hätte (von philosophischen Gesichtspunkten einmal abgesehen), könnte man sogar auf die oben beschrieben Erweiterung des Konfigurationsdialogs verzichten.

Ein kleiner Schritt für die Entwickler, aber ein großer Schritt für alle MySQLDumper-Nutzer mit Magento-Installationen Wink

Die von Dir beschriebene Problematik mit der Optimierung von Relationen im Hinblick auf den Wert 0 in AUTO_INCREMENT-Feldern, seien es MyISAM oder InnoDB, konnte ich nach einigen Tests zumindest mit aktuellen Versionen von MySQL-Server nicht reproduzieren. In allen von mir durchgeführten Tests blieb der Wert 0 nach der Optimierung stets erhalten. Dies war auch unabhängig vom eingestellten SQL_MODE (mit NO_AUTO_VALUE_ON_ZERO oder ohne).

Abschließend von mir auch nochmal ein Dankeschön für Deine insgesamt sehr gelungene Backupsoftware!

Mit besten Grüßen,

rapedu

Posted: 2010-07-17, 20:25 (No subject)

Hallo rapedu,

auch wenn Deine Bitte eigentlich so ist, dass Du Dir einen Mercedes gekauft hast und die BMW-Werkstatt bittest, die richtigen Reifen aufzuziehen (natürlich kostenlos), weil Mercedes das nicht hin bekommt - ich habe mir die Vor- und Nachteile noch einmal durch den Kopf gehen lassen. Ich will aber vorab deutlich sagen, dass ich die Situation für einen Witz halte, bei dem ich nicht weiß, ob ich lachen oder weinen soll. Wink

Es ist für mich immer eine schwierige Entscheidung, ob ein Feature, das einzig und alleine einen Bug einer einzelne Software betrifft, mit in den Dumper integriert werden soll. Eine möglichst einfachen Bedienung durch gerade eben nicht zu bewältigende Optionen steht dem natürlich entgegen.
Dennoch haben wir den Spagat bisher immer geschafft; der Backup-Konverter ist z.B. nur hinzugekommen, weil es Woltlab in der 2er Reihe nicht geschafft hat das Befehlswort "condition" im Dump in Backticks zu setzen. Hier haben wir also solch ein Beispiel, wo ich aufgrund der immensen Userzahl darauf reagiert habe.

MySQLDumper kümmert sich weiterstgehend selbstständig um potentielle Fehlerquellen. Dennoch gibt es die ein oder andere Situation, wo man sich generell erweiterte Einstellungsmöglichkeiten wünscht. Genau dazu habe ich mir umfassend Gedanken gemacht. Es geht also nicht nur grundsätzlich um Deine Anforderung, sondern um eine allgemeingültige Lösung, die allen Nutzern zu Gute kommt.

Glücklicherweise haben wir hier in den letzten Monaten bereits Vorsorge getroffen. Ich habe lange überlegt, wie man die Einfachheit der Bedienung erhalten, aber dennoch optional erweiterte Einstellungen ermöglichen kann. Die erstaunlich einfache Lösung lautet: ab der nächsten Version kann man MySQLDumper in 2 unterschiedliche Modi schalten: "Einfach" und "Profi"! Die Profi-Einstellung blendet dann entsprechende Optionen ein, die vorher verborgen waren. Bis jetzt ist der Unterschied noch gering, aber das Grundgerüst existiert schon einmal. Hier ist also der richtige Ansatzpunkt für eine allgemeingültige Lösung.

Ich weiß nicht, ob Du Dir die aktuelle Entwicklerversion schon einmal aus dem SVN-Repository installiert hast. Dort ist das bereits enthalten.
Damit haben wir zunächst also einmal die Möglichkeit geschaffen, Zusatzoptionen zu ermöglichen, ohne das Programm an sich komplizierter zu gestalten.

Ein Bereich in der Konfiguration für Queries, die nach jedem Seiten-Selbstaufruf immer wieder geschickt werden, machen da natürlich Sinn. Das ist bis jetzt noch nicht umgesetzt, aber ab jetzt auf der internen Roadmap.

Du kannst Dir derweil selbst helfen: wir senden nach jedem Seitenaufruf den Query "SET FOREIGN KEY_CHECKS=0", um den Restore-Prozess zu beschleunigen. Dort kannst Du Dich einhaken und einfach einen zweiten Query senden, der den 'NO_AUTO_VALUE_ON_ZERO'-Query abfeuert.

Ich selbst werde das für die nächste Version im Hinterkopf behalten. Momentan baue ich intern jedoch an beinahe allen Stellen im Dumper Dinge um und betrachte Deine Anforderung als schmückendes Beiwerk zum Ende. Momentan habe ich noch so viele grundsätzliche, qualitätssichernde Dinge und Umstrukturierungen von wesentlich größerer Tragweite zu erledigen, dass ich zum jetzigen Zeitpunkt keine Zeit für neue Features habe.

Wenn Du Dir das SVN-Log der Entwicklerversion und die damit bereits erfolgten Umbauten seit Versioon 1.24 ansiehst, wirst Du verstehen, wovon ich spreche.

Mittelfristig wird es also eine Lösung per MySQLDumper geben. Ich denke auch darüber nach, die Queries frei konfigurierbar zu machen, damit wir sogar Bugs in anderen Skripten abdecken können, die es heute noch gar nicht gibt.
Mehr kann ich Dir und anderen Nutzern nicht entgegen kommen. Wink

**knows MySQLDumper** Joined: 17 Jul 2010 Posts: 2

Hallo Daniel,

ganz herzlichen Dank für Deine schnelle und vor allem auch sehr ausführliche Antwort.

Die aktuelle Entwicklerversion hatte ich mir bereits vor einigen Tagen schon einmal angeschaut. Ich habe diese dann aber wieder gelöscht, nachdem das Zurückspielen von InnoDB-Relationen aufgrund verletzter foreign key constraints abbrach (es ging dabei wieder um Magento).

Ich kann allerdings sagen, dass ich die neuen Funktionen und umbauten in der aktuellen Entwicklerversion sehr begrüße. Insbesondere der von Dir angesprochene "Einfach"- und "Profi"-Modus halte ich für eine sehr gute Idee.

Die Möglichkeit, pro Seitenabruf immer wieder selbstdefinierte SQL-Kommandos mitzusenden wäre gerade für Profis eine sehr wünschenswerte Funktion. Damit ließe sich eine ganze Reihe von spezielleren Anforderungen erfüllen. Vielen Dank, dass Du dieses Feature auf die interne Roadmap aufgenommen hast.

Danke auch für den Tipp mit den FOREIGN_KEY_CHECKS=0. Um zu einer kurzfristigen Lösung zu kommen, hatte ich ohnehin vor, einen kleinen Patch zu schreiben, der das Gewünschte realisiert.

Es geht mir persönlich auch weniger darum, Dich um Implementierung bestimmter Funktionen zu bitten (diese könnte ich als Entwickler auch selbst hinzufügen), sondern darum, MySQLDumper auch für die Gruppe der Magento-Nutzer brauchbar zu machen.

Dein Entgegenkommen ist bereits weit mehr als ich mir erhofft hatte Smile

Ich möchte daher nochmal die Gelegenheit wahrnehmen und mich auch stellvertretend für alle MySQLDumper-Nutzer für Dein unermüdliches Engagement bedanken.

Weiter so!

Viele Grüße

rapedu

Posted: 2010-12-22, 22:25 (No subject)

**knows MySQLDumper** Age: 46 Joined: 16 Nov 2011 Posts: 2

Posted: 2011-11-17, 23:47 (No subject)

Es ist keine Einstellung sondern wird beim Restore automatisch erledigt (siehe inc/mysql.php Zeile 271ff).
Die weisse Seite Deines Frontends muss andere Gründe habe. Vielleicht musst Du den Cache löschen oder den Url in Magento anpassen? Schau dazu in einem Magento-Forum. Dort steht sicherlich beschrieben was nach einem Umzug erledigt werden muss.

**knows MySQLDumper** Age: 46 Joined: 16 Nov 2011 Posts: 2

Du hattest Recht.
Es lag am eingesetzten Theme. Im default-Theme ist alles korrekt. In meinem Fall half die Neuinstallation des Themes. (Theme-Dateien einfach neu per FTP überschrieben)

Warum auch immer das notwendig war? Keine Ahnung, bleibt wohl ein Geheimnis von Magento bzw. dem Theme-Entwickler.

Posted: 2011-11-18, 17:58 (No subject)

Viele Themes (CMS unabhängig) arbeiten mit vorbereiteten Cache-Dateien. Da können dann schon mal irgendwelche festen Hinterlegungen drin sein, die nach einem Serverumzug nicht mehr stimmen. In dem Fall bieten viele Systeme an (bei phpBB ist es z.B. so), den Cache zu löschen und neu erzeugen zu lassen.

**first backups** Joined: 20 Nov 2011 Posts: 1

Posted: 2011-11-20, 18:19 (No subject)

Das hat mit dem bisherigen Thema nichts zu tun.
Stelle in den Wiederherstellungsoptionen des Dumpers ein, dass im Fehlerfall nicht angehalten werden soll und wiederhole die Wiederherstellung.