MariaDB - REDO-Log Modus

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Status
Für weitere Antworten geschlossen.

cpam

Benutzer
Registriert
14. Sep. 2013
Beiträge
228
Reaktionspunkte
0
Punkte
0
Hi zusammen,

weiß jemand, ob man die MariaDB anstatt mit FullBackups auch im Log-Modus (REDO-Log) fahren kann?
Wenn ja,hat jemand passende Artikel hierzu?

LG
 
Du müsstest in Konfig-File die DB-Engine auf INNO-DB konfigurieren.
Wie das geht, kannst Du hier in Erfahrung bringen: http://dev.mysql.com/doc/

Soweit zur Theorie.

Übrigens, der Standard-DB-Server des DSM läuft mit der Version 5.5 ...

Praktisch habe ich das mit der Anpassung nicht gemacht. Jedoch kann ich mir gut vorstellen, dass Syno bei einem Upgrade das Konfig-File überschreibt, und somit Deine Anpassungen hinfällig sind.
Demnach wäre es wohl sinnvoll, wenn Du Dir einen weiteren, persönlichen MySQL-Server manuell einrichtest.
 
Ich habe jetzt mal den binary-log aktiviert
Jetzt bekomme ich jede Menge mysqld-bin.000000 Dateien.

Nur mit dem abrollen der Dateien habe ich noch nicht ganz verstanden.
Hätte es mittels mysqlbinlog versucht bzw. auch mit den Optionen.
Aber iwie funktioniert das nicht ganz wie gewollt...
Ist das überhaupt das richtige?

LG
 
Ja, das ist die einzige Möglichkeit, die MySQL vorsieht.
 
Danke für die Info.

Eins kapier ich aber noch nicht ganz.
Dh wenn ich einen Restore mache, mache ich zuerst einen Full-Restore des Dumps und rolle die DB dann mittels mysqlbinlog bis zu dem gewünschten Zeitpunkt vorwärts, richtig?

Jetzt habe ich aber gestern bei einem Test gesehen, dass beim Full-Restore durch den Dump auch in die bin-files jede Menge geschrieben.
Wird jede Änderung des Dump-Restores denn auch wieder in die BIN-Files geschrieben?

Das wäre dann ja komisch, weil normal rollt man bei einem Disaster-Recovery die REDOs bis zum letzten möglichen Zeitpunkt vorwärts.
In diesem Fall würde das aber heißen, ich lade zuerst sämtliche Änderungen seit dem Dump rein und anschließend aber gleich nochmals alle Änderungen welcher der Dump-Restore gemacht hat.
Dh ich bin dann wieder nur auf den Zustand des Dumps???

Muss ich den Zeitpunkt des Dump-Restores ausklammern aus dem mysqlbinlog oder verstehe ich etwas falsch?
Oder wird ein DUMP-Restore im BIN-LOg eh nie abgerollt?

LG
 
Im BINLOG wird alles mitgeschrieben, was im DB-Server passiert.
Andernfalls würdest Du ja nicht zeitpunktgenau restoren können.
 
ja schon, aber dass ist nicht logisch bzw. kenn ich von anderen dbs auch nicht (zB oracle) dass hier der dump restore wieder in den log geschrieben wird.
dh ich erzeuge ja eine unmenge an transaktionen darin, aber egal.

Um auf meine Frage zurückzukommen heißt dass, ich muss die DumpRestores dann aus den bin-dateien exkludieren (bin bin redo)
Kann ich das auf eine einfache Weise machen?
 
Aus Mangel an praktischer Erfahrung (Habe es noch nicht nutzen müssen), würde ich nach folgenden Dokumenten vorgehen:
- http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html
- http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery-times.html
- http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery-positions.html

Bevor das direkt in die DB geschrieben wird, schaue Dir den "Umweg" über ein temporäres Text-File an.
So solltest Du dann verfolgen können, was genau passiert, bevor Du das dann in die DB schiebst.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat