mysqldump von einer Live vBulletin DB

[jaeh]

Hallo,

ich dump jede Nacht die DB meiner vBulletin DB per Skript im Live Betrieb. Soweit so gut. Im Netz begegnet mir immer wieder mal
das Live dumps von MySQL zu Fehlern führen kann, da ja während des Dump Vorgangs Daten verändert werden können, wenn in die
DB geschrieben wird, was zu einer Inkonsistenz führen kann. Es gibt da ja auch zwei Schalter:

-single-transaction (innodb)
und
–lock-all-tables (myisam, weil der obige schalter dort nicht funktioniert)

Soweit ich das sehe besteht die vbulletin ja aus beiden Storage engines bin mir jetzt gar nicht sicher ob man beide Befehle beim
dumpen absetzen kann.

Sprich dann wäre es besser den Apache Server zu stoppen und die DB zu locken und dann erst den Dump ziehen...

Gibts da eventuell Erfahrungswerte? Wie handelt ihr das?

Vielen Dank schonmal!

[pogo]

Du kannst es so in der Art versuchen:
https://dba.stackexchange.com/a/19533

Oder, wenn überhaupt möglich, ein Backuptool installieren, wie z.B. XtraBackup, das genau für diese Zwecke entwickelt wurde.
Allerdings ist das nicht einfach mal so eingerichtet und schnell genutzt und für eine Datenbank wohl dann auch ein wenig zuviel des Guten.

Macht der Hoster keine täglichen Backups?

[Jaydee]

Einige der namhaften Hoster verlangen auch geringe Gebühren für den Zugriff auf regelmäßige DB-Backups, aber das sollte man evtl. investieren. Ist im Bedarfsfall allemal einfacher als der eigene Aufwand über Scripts, Cronjobs usw.
Es gibt aber auch Hoster, die stellen selbst in den Standard-Paketen schon 7-Tages-Backups (also rückwirkend täglich für eine Woche zur Wahl) völlig kostenfrei zu Verfügung.

Nachteil dieser Verfahren ist sicherlich, dass man damit keine einzelnen Tables einspielen kann, sondern immer nur den kompletten Dump (was u.U. weder nötig ist noch fix geht).
Bevor ein Forum dauerhaft crasht, ist das aber sicher eine Alternative zu den diversen Tools.

Was das "Table-Lock" angeht: Die Gefahr im Live-Betrieb besteht zwar grundsätzlich, ist aber relativ gering. Ich sichere unzählige DBs nachts im Livebetrieb und dabei ist in 2 Jahrzehnten noch nie etwas passiert oder verloren gegangen.
Speziell aufs vB bezogen können Dir praktisch nur die wenigen "Echtzeit-Daten" verloren gehen, sprich Sessions-Tabelle, IP-Sperre nach Fehlanmeldungen usw. und darauf kann man getrost verzichten.
Bei Schreibzugriffen auf z.B. post oder thread-Tabellen wird ohnehin vor der Sicherung kurz "gelockt", dabei kann also auch nichts passieren. Selbst wenn nachts in genau der Zehntelsekunde jemand einen Beitrag abschickt, wird der auf den meisten Servern kurz gepuffert und dann sofort nach der SIcherung (und Entsperrung) gespeichert.
Selbst der geht also in der Regel dann nicht verloren.

Ich denke, da wir im Netz oft vieles sehr aufgepuscht und Panik verbreitet, wo gar keine reale Gefahr besteht.
Selbst große Firmen und Plattformen wie z.B. eBay oder Amazon etc. sichern im Livebetrieb und schalten nicht ihre Seiten (oder gar Server) deswegen ab. Und da passiert bekanntlich auch nichts und zur Not gibts noch eine "gespiegelte Redundanz" durch Festplattenverbund etc.

[Andreas]

Gibts da eventuell Erfahrungswerte? Wie handelt ihr das?

Single Transaction & FLUSH TABLES WITH READ LOCK kann man bei entsprechender DB-Größe vergessen - da dauert ein Dump dann selbst bei SSDs etliche Sekunden; das ist für ein aktives Forum zu lange.

Bei einem kleinen Forum mit wenig Traffic ist das aber unproblematisch, haben wir selbst etliche Jahre lang so gemacht.

Wir machen tägliche Snapshots des Dateisystems (ZFS) auf einem eigens dafür eingerichteten Slave-Server und sichern diese im Anschluss auf Backup-Storages.

[Jaydee]

Andreas, selbst in größeren Foren passiert da normalerweise nichts (siehe oben).
Zumindest geht nichts Relevantes dabei verloren, selbst wenns mal "einen Moment länger" dauert.
Wenn die gesamte Datenbank mehrere GB im höheren Bereich umfasst, ok, das dürfte kritisch werden und würde ich auch nicht riskieren. Das dürfte bei vB-Foren aber eher die Ausnahme sein.... (und passiert oft auch nur dann, wenn dummerweise die Binary-Dates - wie Fotos etc. - auch in der DB gespeichert werden und unnötig aufblähen und zusätzlich gefährden).

In solchen Fällen würde ich dann evtl. auch auf tägliche (eigene) Backups verzichten und tatsächlich kurz das Forum zur manuellen Sicherung (alle paar Tage) offline nehmen. Aber bis ca. 1,2 GB habe ich immer problemlos im laufenden Betrieb nachts gesichert.

Noch besser ist es natürlich, wenn man ein Backup (als Restore) gar nicht erst braucht und seinerseits alles Menschenmögliche für einen sicheren Serverbetrieb tut (was natürlich kein 100% Garant ist).

[jaeh]

Danke für eure Antworten! Dann werd ich das so lassen. Unser Hoster macht zwar täglich für 10 Tage Server Backups, schreibt aber:

Bitte beachten Sie, dass Tabellen des Typs InnoDB, welche oft durch CMS (beispielsweise Joomla) genutzt werden, nicht konsistent gespeichert werden können

Deshalb wollte ich ein zusätzliches Offsite Backup haben, sicher ist sicher.

Es laufen da ja noch 2 Wikipedia Wikis und Wordpress Blog drauf, aber da die nur für mich persönlich sind, sollten da ebenfalls keine gröberen DB Transaktionen
laufen.

Ich werd bald mal ein Desaster Recovery durchführen dann seh ich eh obs passt.

Vielen Dank auf jedenfall für die Rückmeldungen, ist immer beruhigend zu wissen, wie andere das handhaben

[Andreas]

Andreas, selbst in größeren Foren passiert da normalerweise nichts (siehe oben).

Passieren (im Sinne von Datenverlust) passiert da durch den Dump an sich sicherlich nichts, ja.
Aber es hat bei entsprechender Größe definitiv negative Auswirkungen auf den Produktivbetrieb:

Wenn die gesamte Datenbank mehrere GB im höheren Bereich umfasst, ok, das dürfte kritisch werden und würde ich auch nicht riskieren. Das dürfte bei vB-Foren aber eher die Ausnahme sein.... (und passiert oft auch nur dann, wenn dummerweise die Binary-Dates - wie Fotos etc. - auch in der DB gespeichert werden und unnötig aufblähen und zusätzlich gefährden).

Aber genau davon rede ich, Datenbanken in der Größe von 30+ GB (davon haben wir einige) - ohne Binary-Daten und Volltext-Indexe versteht sich.

Wenn ich davon einen Dump erstelle dann dauert das einige Sekunden, wenn derweil hunderte von Zugriffen hängen finden das die Webserver-Prozesse gar nicht lustig

[Jaydee]

Oh ja, bei solchen Größenordnungen auf jeden Fall. Da sind wir uns einig.
In solchen Foren müsste man zu den vielen Online-Usern dann auch noch entsprechend viele "Gast"-Zugriffe durch SuMa-Bots7Spider usw. rechnen. Auch wenn die nicht "schreiben". In der Summe ist das dann wirklich nicht mehr lustig.

Ich denke aber mal, das betrifft den Großteil der Betreiber hier eher nicht mit den "üblichen" Foren.
Theoretisch könnte man das Forum vielleicht automatisiert über ein Script schließen und öffnen und das in die Crontab einbinden. Aber damit habe ich mich noch nie beschäftigt.

[Andreas]

Theoretisch könnte man das Forum vielleicht automatisiert über ein Script schließen und öffnen und das in die Crontab einbinden. Aber damit habe ich mich noch nie beschäftigt.

Das geht nicht nur theoretisch sondern auch praktisch, haben wir früher so gemacht als wir noch keine Backup-Slaves hatten.
Allerdings reicht es nicht aus das Forum einfach per Einstellung offline zu setzen, auch in diesem Fall laufen weiterhin Queries auf und bleiben im Fall von MyISAM/FLUSH TABLES WITH READ LOCK hängen.
Man muss also bereits den Aufbau einer DB-Verbindung unterbinden, dies hatten wir durch entsprechenden Code in der config.php realisiert - falls Backup-Lockfile vorhanden -> Wartungsmeldung & Exit.
Das auf Webserver-Ebene zu machen wäre auch eine Option gewesen, hätte aber - da Prä-FPM - einen Reload der Config und somit eine Invalidierung des OpCode-Cache zur Folge gehabt was sich on Tests signifkant negativ auf die Performance auswirkte.

Aber das war Mist :-)

Da die Maschinen damals noch keine SSDs hatten mussten wir IO stark throttlen damit uns die anderen DBs während des Backup nicht um die Ohren geflogen sind.
Somit hat der Dump einer "großen" DB ca. 8 Minuten gedauert.
Dies hatte zur Folge dass Google ständig über "Serverausfälle" gemeckert hat, denn es wurde während des Dump eine Wartungsmeldung mit Status 503 ausgeliefert.

Summa summarum: Bei entsprechender Größe und Last ist ein Dump von einer für Produktivzwecke genutzten MySQL-Instanz nicht wirklich praktikabel.

[Jaydee]

Hallo Andreas,

genau wegen dieses letzten Satzes tendiere ich dann immer eher zur manuellen Methode:

Summa summarum: Bei entsprechender Größe und Last ist ein Dump von einer für Produktivzwecke genutzten MySQL-instanz nicht wirklich praktikabel.

In solchen Fällen würde ich dann evtl. auch auf tägliche (eigene) Backups verzichten und tatsächlich kurz das Forum zur manuellen Sicherung (alle paar Tage) offline nehmen.

Und zwar hatte ich das in 2 oder 3 Fällen dann in der Form gemacht, dass ich das Forum gar nicht erst groß geschlossen habe, sondern gleich "knallhart" vom Server getrennt und stattdessen kurz eine eigene Wartungsseite vorgeschaltet habe. Die hat natürlich keinerlei Datenbank-Anbindung oder ähnliches, sondern dient nur der Information.
Dann ist das Thema nach wenigen Minuten durch und das Forum kann sofort wieder online gehen.

Die Crux dabei ist sicher, dass genau das wiederum in sehr großen Foren nur bedingt Sinn macht.
Denn wo ein normal großes (wie immer man das jetzt definieren mag) Hobby-Forum sicher gut damit leben kann, dass nur alle paar Tage mal gesichert wird und man im "worst case" evtl. die letzten Tage verliert, wäre das bei gewerblich genutzten, sehr großen Foren ein absolutes no-go.
Aber auch dort will sicher niemand diesen täglich-nächtlichen, manuellen Aufwand treiben.
Bei solchen Betreibern würde ich aber unterstellen, dass sie ohnehin im Slave-Betrieb ALLES regelmäßig sichern.

Also kurz: Ich denke, für den "Standard-Privat-Betreiber" gibt es genug praktikable Lösungen zur Sicherung. Das Problem dort sehe ich eher darin, dass Viele von ihnen erst gar nicht an Backups denken bzw. sich der (möglichen) Gefahren ohne Fallnetz bewusst sind, wenn sie keine Betreuung haben.

Wie oft wurde ich erst dann von jemandem angesprochen, wenn das Kind bereits in den Brunnen gefallen war (Malware, Hackangriffe, ...) und auf meine Frage nach Backups dann meist sowas kommt wie "öhm.... hmmmm.... nö, wo sollten die denn sein? Keine Ahnung... " usw.