mysql

ich erstelle Lockall über die win Konsole alle Datenbank Backup von Server dazu lasse ich eine cmd/bat über ein CRON Jobs ausführen


echo Working on: XXX.sql

%mysqldir%mysqldump.exe -u%mysqlusername% -p%mysqlpassword% -h%mysqlhost%  XXX  > %dir%\XXX.sql

timeout /T %timeout%  > nul

wie man siede werden 3 Anweisung ausgeführt eine echo Ausgabe die das erstellen des mysqldump und eine Pausen Anweisung das wird dann für alle DB wiederholt

Mein Problem ist nun das wahren das der Erstellung der Datenbank Backup der Authserver und Worldserver Verbindung Probleme zur DB bekommt jedenfalls ist es nicht möglich wahren der Erstellung sich mit den Server zu verbinden.


ERROR [SQL] Unhandled MySQL errno 1615. Unexpected behaviour possible.

2012-09-12_21:32:17 ERROR [SQL] SQL(p): SELECT a.sha_pass_hash, a.id, a.locked, a.last_ip, aa.gmlevel, a.v, a.s FROM account a LEFT JOIN account_access aa ON (a.id = aa.id) WHERE a.username = 'XXXX'

[ERROR]: [1615] Prepared statement needs to be re-prepared

2012-09-12_21:32:17 ERROR [SQL] Unhandled MySQL errno 1615. Unexpected behaviour possible.

der Server lauft auf Einen Debian 6 Root Server

Je nach größe der Datenbank ist es nicht ungewöhnlich, dass durch den Dump andere Zugriffe blockiert werden. Willst du das verhindern, wirst du nicht drum rum kommen die Datenbank gespiegelt als Beispielsweise Master Master laufen zu lassen.

Alternativ könntest du auch world und realm für die Zeit des Backups abschießen. Also die Shell entsprechend erweitern um einen Eintrag der world und realm runter fährt, das Backup fährt und dann world und realm wieder hoch fährt.

den Server runter zu fahren möchte ich aus mehren grünten nicht

die erste Lösung gefallt mir besser kannst du mir Informationen geben oder wo ich Anleitungen oder so finde wie Mann dies umsetzt.

Hab das selber noch nicht getan aber du kannst ja mal googlen nach sowas wie sql replikation.

Ich habe das zwar auch noch nicht gemacht, würde aber vermuten, dass der Aufwand da wesentlich größer ist als der Nutzen den du davon hast. Ich würde dir einfach vorschlagen deine BackUp’s jeden Montag Morgen gehen 3-4 Uhr zu machen. Fahre solange den Server runter und mach dein BackUp sauber. Wenn dein Server läuft, sind einige der Daten noch nicht gespeichert und du hast unsaubere BackUp’s, währe doch schade.

Zwischen 3-4 werden eh kaum Player ON sein, da Normale Meschen um die Zeit schlafen.

LG

der Aufwand für die SQL Replikation ist gar nicht so groß und ist sehr einfach umzusetzen einzige Voraussetzung ist das Mann zwei getrennte Datenbankserver hat. dann hat Mann immer ein live Backup.

Das mag sein, bleibt trotzdem das Problem das nicht alles direkt in die DB wandert was passiert,

sondern teilweise später gespeichert wird. Somit fallen Daten weg.

Aber Wenn du es so lösen willst, viel erfolg, war nur ein Vorschlag von meiner Seite.

LG

ich habe es schon umgestellt dabei ist es völlig egal wann der Server die Daten Speichert da durch die Spiegelung alle Daten gleichzeitig auf den Spiegelserver übertragen werden.

somit ist ein Daten Verlust fast ausgeschlossen.

außerdem ist dein vor schlag nicht neu genau das selbe hat mir “Micha” auch schon vorgeschlagen.

Ich glaube was Dhiana meint sind inkonsistente Daten. Mal angenommen du startest dein Backup und in der Zeit in der das Backup läuft, ändert sich was in den Daten in einem Bereich der bereits dem Backup zugeführt wurde, so fehlt dir dieser später, oder macht sogar das Backup kaputt. Die wahrscheinlichkeit das das aber passiert ist recht gering. Ich müsst jetzt selbst mal nachlesen, aber ich meine, das der sqldumb die Datenbank für die Zeit des dumps sperrt, was ja genau zu dem beschriebenem Problem führt. Daher ist das zu vernachlässigen.

Weiterer Vorteil der Replikation ist, das sollte tatsächlich mal der Master DB Server abrauchen, steht sofort die Replikation bereit und es kann ohne Verlust weiter gearbeitet werden.

Naja, das meinte ich jetz nicht ganz, aber fast.

Der Server hat einen gewissen Rhythmus in dem er seine z.B. Character Daten in die DB speichert.

Ich bin mir grade nicht sicher wie das eingestellt ist, aber ich glaube Standard ist 5 min.

Zu meiner Activen dev zeit konnte man das zumindest in der Config einstellen und vermutlich hat sich das nicht geändert.

Momentan bastele ich nur so nebenbei bei Problemen an nem Server mit und so für mich an ner 4.3.4 core.

Aber ich schweife ab …

somit werden in den meisten fällen beim backup erstellen meist ca. 5 min felhlen, sollte nun grade ein backup erstellt werden als er saven will, können es auch mal ca. 10 min werden die fehlen, und spieler beschweren sich über jeden rolleback…

Theoretisch ja, in diesem Fall schon, nehmen wir aber mal an, i-wer der Devs baut mist in der DB und merkt es nicht. Server muss neu gestartet werden und startet nun aber dank des Fehlers nicht mehr. Ist normal alles gut, hat der MySQL Backup Server aber in der Zeit auch schon mal sich seine Daten gezogen, tja, dann hat man nichts mehr.

Es is immer gut mindestens 3 Monate vergangene BackUp’s zu haben.

Das wollte ich damit sagen, mehr nicht.

Aber es ist ja seine Entscheidung wie er seine Backups verwalten will.

Aber in der Anwendung ist es immer sinnvol nicht nur eine BackUp quelle zu haben.

es ist völlig Egel in welchen Rhythmus der Server die Daten speichert da alle Daten von Server a an Server b weitergeleitet werden und umgekehrt.

natürlich Solde Mann auch zusätzlich BackUp machen erst recht vor einen Core / DB Updatet das kann aber dann auch über den Spiegelserver geschähen somit hat es keine Auswirkungen

auf den Hauptserver.

Aso, du hast eine dauernten austausch an Daten, das ist natürlich was anderes als das was ich meinte.

Somit währe das hinfällig.

Somit ist dein System aber sehr anfällig für Fehler. wenn der “Live” (so nenne ich mal den SQL Server der für den World zuständig ist) einen Fehler hat, bekommst du ihn automatisch auch an den BackUp Server weitergeleitet. Zumindest wenn ich das was du da Aufgebaut hast, nicht Falsch verstehe.

Stimmt, Oben genanntes Problem, soweit vorhanden aber nun auch in den SQL Backup’s.

EDIT:

Sieh das bitte nicht als böse Kritik, sondern als Konstruktive Kritik.

Versuche dich nur auf Schwachstellen hinzuweisen damit du etwas dagegen tun kannst.