Downtimeless MySQL-Backups mit kleinem Budget

Mein derzeitiges MySQL-Backup-Szenario besteht darin, unsere Datenbank auf einen zweiten Server zu replizieren und mysqldump auf diesem Server auszuführen, um Ausfallzeiten durch das Sperren von Tabellen oder Zeilen zu vermeiden. Dies funktioniert gut, kostet aber $ 150 pro Monat für den zweiten Server (australisches Hosting ist viel teurer als US.)

Ich habe hier eine Menge Fragen dazu gelesen, die meisten Leute brauchen Hilfe bei den geplanten Backups und was nicht ist, was ich brauche. Ich muss mysqldump (vorzugsweise alle 4 Stunden) ohne Ausfallzeit ausführen. Die Datenbank ist ~ 7 GB unkomprimiert, daher kann der mysqldump je nach Server einige Zeit in Anspruch nehmen.

Ich habe überlegt, auf dieselbe Maschine zu replizieren, aber ich wollte nicht, dass der Sklave in den dringend benötigten Speicher kommt. Ich bin mir nicht sicher, ob ich die Speichernutzung pro DB einschränken kann. In beiden Fällen wird der Server dadurch belastet, während die Datenbank gesichert wird.

Ich habe gerade diese http://www.zmanda.com/quick-mysql-backup.html gelesen und es sieht gut aus, 300 Dollar pro Jahr sind in Ordnung, das spart mir viel.

Leider kann ich nicht auf Amazon RDS replizieren, aber ich könnte auf eine Micro-RC2-Instanz replizieren, aber die Replikation würde über das Netz erfolgen und der Ping-Wert beträgt ~ 220 ms.

Ich habe ein paar Leute hier gesehen, die über LVM-Schnappschüsse gesprochen haben, was eine gute Option sein könnte. Ich weiß nicht viel über diese Option.

Meinungen würden sehr geschätzt.

Wenn Sie Innodb-Tabellen verwenden, können Sie verwenden

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Dadurch wird ein Speicherauszug Ihrer Datenbank erstellt, der von ihren Tools auch ohne Sperren importiert werden kann. Ich glaube, wenn Sie Myisam-Tische haben, werden diese gesperrt.

Wenn Sie innodb oder ein anderes Backend verwenden, das vollständig transaktionell ist, können Sie es verwenden mysqldump --single-transaction .... Ich habe dies für relativ große (~ 100 GB) Datenbanken mit guten Ergebnissen verwendet. Wenn die Datenbank stark ausgelastet ist, kann dies Stunden dauern , ohne dass die Tabellen gesperrt werden. Die Replikation ist im Allgemeinen besser, aber manchmal möchten Sie eine schöne solide Dump-Datei. Denken Sie daran, dass Sie auch einen MySQL-Replikations-Slave sichern können.

Auf der mysqldump-Seite (beachten Sie die Vorbehalte zu Vorgängen, die in die Transaktion eindringen):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

Ich sehe kein großes Problem bei der Replikation über eine Verbindung mit hoher Latenz zu einem billigen VPS in den USA. Die hohe Latenz sollte eigentlich kein so großes Problem sein. Die Replikation soll auch dann schnell aufholen können, wenn ein Slave stundenlang im Rückstand ist, dh asynchron arbeiten kann.

Solange Sie so viel ausgehende Bandbreite auf Ihrem australischen Hosting-Plan aushalten können.

Hier finden Sie eine detailliertere Antwort darauf, ob die hohe Latenz von Bedeutung wäre

Realistisch gesehen ist nur die Zeit, die zum eigentlichen Export der Datenbank benötigt wird, eine Ausfallzeit. Tun Sie es in einem Zeitraum, der langsam genug ist und es sollte kein Problem geben. Was erwartet eine IT-Abteilung mit diesem Budget wirklich?

Sie sollten in der Lage sein, eine 7-GB-Datenbank innerhalb von maximal 5-10 Minuten zu sichern, die Lese- / Schreibsperre aufzuheben und die Ausfallzeit zu Ende zu bringen. Sie können dann den effektivsten Weg zur Bandbreite der 7-GB-Datei auf dem neuen Server finden (siehe: HOHE KOMPRESSION). Sie haben genügend Zeit, um die Datei auf den neuen Server zu übertragen und in MySQL zu importieren. Geben Sie dann die Masterlog-Informationen ein und starten Sie die Replikation. Sollte ein Kinderspiel sein!

Die MySQL-Dokumentation ist fantastisch : http://dev.mysql.com/doc/refman/5.0/en/replication.html

Ich bin mir nicht sicher, ob ich die Speichernutzung pro Datenbank einschränken kann

Natürlich können Sie - Sie müssen nur den Slave mit einem anderen /etc/my.cnf ausführen

Sie können sogar Dinge tun, um die Planungspriorität / CPU-Affinität auf dem Master und dem Slave mit nice / renice und taskset zu manipulieren (vorausgesetzt, es handelt sich um einen Linux-Server).

aber die replikation würde über netz stattfinden und der ping ist ~ 220ms

Die Latenz spielt keine Rolle - das Wichtigste ist die Bandbreite - und die Datenbankbandbreite (vorausgesetzt, Sie replizieren keine Sitzungsdaten) ist um mehrere Größenordnungen geringer als die HTTP-Bandbreite.

Ich muss [eine konsistente Sicherung der Datenbank erstellen] (vorzugsweise alle 4 Stunden) ohne Ausfallzeit

Aber die Strategien, die Sie besprechen, erlauben zu dieser Zeit keine Erholung.

Ich denke, die billigste Option wäre ein Slave auf demselben Computer - und wenn sich dies nachteilig auf die Leistung auswirkt, über das hinaus, was Sie neu konfigurieren können, aktualisieren Sie das aktuelle Hosting-Paket.

Sie können auch in Betracht ziehen, einen getrennten Slave auszuführen: Aktivieren Sie die Bin-Protokolle auf dem aktuellen Server. Erstellen Sie eine Sicherungskopie, stellen Sie die Sicherungskopie auf einem lokalen Computer wieder her, kopieren Sie die Bin-Protokolle, während sie gedreht werden, und führen Sie eine aktualisierende Recovery auf dem lokalen DBMS durch .

Mein Vorschlag:

1 - Behalten Sie Ihr zweites Konto / Ihren zweiten Server bei und implementieren Sie die Replikation in eine Datenbank in Ihrem ursprünglichen Konto / Server.

2 - Stoppen Sie die Replikation auf dem zweiten Konto / Server.

3 - Überwachen Sie die Leistung für einige Tage. Stellen Sie sicher, dass Sie es lange genug überwachen, um Ihre geschäftigsten Perioden einzuschließen.

4 - Seien Sie bereit, auf Ihr altes Setup umzuschalten, wenn ein schwerwiegendes Leistungsproblem vorliegt. Aus diesem Grund haben Sie das zweite Konto geführt.

5 - Kaufen Sie mehr Kapazität / Upgrade-Server in Ihrem ursprünglichen Konto. Dies sollte billiger sein als die Zahlung für zwei Server, glaube ich.

6 - Zweites Konto kündigen.

Viel Glück!