Problem nach Restore

[pixelpeter]

Hallo,

Folgendes ist mir bei einem Testrestore aufgefallen:
Die VM macht ein "recovery journal".
Die Partition mit der mysql Datenbank hat viele fehler und die DB startet nicht mehr.
Backupmmethode "snapshot", qemu Agent ist installiert, debian 10.

Sollte der quemu Agent nicht das Filesystem in einen konsistenten Zustand versetzen um genau dies zu verhindern?


Peter

 

[fabian]

der qemu agent macht ein freeze - was genau das auslöst ist von betriebssystem zu betriebssystem unterschiedlich (und auch konfigurier- bzw erweiterbar). sh z.b. https://github.com/qemu/qemu/blob/m...t-agent/fsfreeze-hook.d/mysql-flush.sh.sample

bist du dir sicher dass das freeze passiert ist? sollte im backup log ersichtlich sein (agent muss installiert UND in der VM config aktiviert sein)

 

[pixelpeter]

Hallo Fabian,

Vielen Dank für die Info.
Ich sehe gerade das das hier VM seitig fehlt. War mir nicht klar.
Ich teste das und stelle dann auf "gelöst".

Peter

 

[pixelpeter]

Hallo,

Alles klar, die hooks werden definitiv unter Debian 10 nicht ausgeführt.
Irgendwie gibt es kein Konfigurationsfile dafür.
Hat das jemand unter Debian 10 am laufen?

Peter

 

[fabian]

sh. man qemu-ga - das config file für den agent muss angelegt werden

 

[Felix.]

MySQL / MariaDB wird aber trotzdem ein Crash Recovery starten, wenn du die Tabellen flushst.
Es *sollte* dann aber kein Datenverlust entstehen, da die Binlogs das abfedern.
Aber weil der Buffer Pool noch immer offen war, startet die DB erstmal ein Recovery, das kann bei großen Datenbanken auch ein Stück dauern.

Wenn du diese Zeit nicht hast oder haben willst bei einem Restore, dann fahr die DB lieber runter beim "freeze" und starte sie neu beim "thaw" - oder mach gleich ein Backup im Stop-Mode.

Wenn du dir keine Downtime erlauben kannst / willst, dann kannst du auch einen Datenbank Slave verwenden für die DB Sicherung.