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
Gast
#5175835
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
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.
Bei InnoDB wär ich mit mysqlhotcopy etwas vorsichtig, zumindest wenn man die Voreinstellung eines zentralen Tablespace verwendet.
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.
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
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.
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.
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
Gast
#5176006
Vielleicht noch interessant. Die hier machen das mit Master und Slave: http://blog.jonaspasche.com/2009/10/26/mysql-backups-aber-wie/
Gast
#5176028
mysql kann inzwischen "binlogs" schreiben? coole sache - ich kenne das bisher nur von oracles archive-logs. definitv ein profi feature!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.