MySQL Database binary files copy ohne Lock

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

Frage: Was genau passiert, wenn ich die Datenbank Files einer MySQL 
Datenbank kopiere, ohne die Datenbank anzuhalten?

1. Das File ist mit nennenswerter Wahrscheinlichkeit defekt und kann 
nicht mehr verwendet werden
2. Ich schneide damit in Transaktionen und diese Transaktionen sind dann 
verloren?

Hintergrund:
Ich würde gern ein stündliches Backup der Files machen, dazu möchte ich 
die Datenbank natürlich nicht stoppen. Beim täglichen, das nachts läuft, 
ist das Stoppen kein Problem.

Das ich Transaktionen verlieren würde, wäre nicht so schlimm, bei einem 
stündlichen Backup verliere ich im K-Fall ja sowieso Transaktionen, da 
kommt es auf ein oder zwei mehr auch nicht an.

Vielen Dank

 Timm

[Peter II (Gast)]

Steht alles in der doku:

https://dev.mysql.com/doc/refman/5.5/en/backup-types.html
https://dev.mysql.com/doc/refman/5.5/en/mysqlhotcopy.html

[(prx) A. K. (prx)]

Da du wahrlich nicht der Erste bist, der MySQL-Backups macht: Das 
Internet ist voll von Anleitungen. Ein Weg geht über "mysqldump". Für 
Terabytes ist das etwas unpraktisch, aber wenn sich die Grösse in 
Grenzen hält funktioniert das ganz gut. Nur schauen, dass du alles 
sicherst, --opt allein ist mitunter zu wenig.

Vorteil eines Dumps gegenüber den blanken Files: Das Ergebnis ist les- 
und korrigierbar.

[(prx) A. K. (prx)]

Bei InnoDB wär ich mit mysqlhotcopy etwas vorsichtig, zumindest wenn man 
die Voreinstellung eines zentralen Tablespace verwendet.

[(prx) A. K. (prx)]

Timm R. schrieb:
> Das ich Transaktionen verlieren würde, wäre nicht so schlimm, bei einem
> stündlichen Backup verliere ich im K-Fall ja sowieso Transaktionen,

Du kannst auch mit Binary Logs arbeiten. Darin werden die Transaktionen 
fortlaufend protokolliert. Das kann dann beispielsweise eine tägliche 
Vollsicherung bedeuten, auf dessen Restore aufbauend man dann die 
Binlogs nachzieht. Vorteil: Die Binlogs sind kleiner und brauchen kein 
Locking.

Point in Time Recovery: Wenn du mal Mist gebaut hast, kannst du bis 
genau zu dem Zeitpunkt vor dem Fehler recovern.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

A. K. schrieb:
> Timm R. schrieb:
>> Das ich Transaktionen verlieren würde, wäre nicht so schlimm, bei einem
>> stündlichen Backup verliere ich im K-Fall ja sowieso Transaktionen,
>
> Nicht notwendigerweise. Du kannst auch mit Binary Logs arbeiten. Darin
> werden die Transaktionen fortlaufend protokolliert. Das kann dann
> beispielsweise eine tägliche Vollsicherung bedeuten, auf dessen Restore
> aufbauend man dann die Binlogs nachzieht. Point in Time Recovery.

so, das klingt mal sehr interessant! Kannst Du einen Text empfehlen, der 
das Thema auf einfach Niveau anreißt?

vlg
 Timm

[(prx) A. K. (prx)]

Timm R. schrieb:
> so, das klingt mal sehr interessant! Kannst Du einen Text empfehlen, der
> das Thema auf einfach Niveau anreißt?

Nope, sorry. Zu lange her.

[(prx) A. K. (prx)]

Für Anspruchsvolle: Ich hatte auch schon einen Cluster aus 2 
MySQL-Servern. Diese Binlog-Technik ist nämlich nicht nur für Backups 
nützlich, sondern eignet sich auch dazu, einen zweiten Server nachlaufen 
zu lassen. Der erste schiebt nach anfänglicher Synchronisierung 
permanent die Binlogs dem zweiten rein, so dass bei einem toten 
Primärserver der zweite den aktuellen Stand hat. Ohne gemeinsames 
Medium.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

also die Binlogs, wie blöd kann man sein? Das ist ja ein absolut 
geniales Feature! Hat sich die Frage doch gelohnt, vielen Dank!

Die müssen in meinem Fall zwingend unbedingt eingeschaltet sein.

Herzliche Grüße und vielen Dank

 Timm

[T.roll (Gast)]

Vielleicht noch interessant. Die hier machen das mit Master und Slave:

http://blog.jonaspasche.com/2009/10/26/mysql-backups-aber-wie/

[c.m. (Gast)]

mysql kann inzwischen "binlogs" schreiben? coole sache - ich kenne das 
bisher nur von oracles archive-logs.
definitv ein profi feature!