Mysql-DB spiegeln?

[Jonas2]

Hallo Forum,

gibt es einen Weg, eine mysql-Datenbank quasi "on the fly" auf einem anderen Server zu spiegeln? Vielleicht auc h, ohne gleich einen Rootserver zu haben, sondern einen "managed" Server?

Jonas

[j4nk3y]

Hey,

gibt es einen Weg, eine mysql-Datenbank quasi "on the fly" auf einem anderen Server zu spiegeln? Vielleicht auc h, ohne gleich einen Rootserver zu haben, sondern einen "managed" Server?

Du kannst mit dem PHPMyAdmin eine Datenbank exportieren (in eine Datei speichern) und dann auf einem anderen Server wieder importieren (aus der exportierten Datei die DB wieder erstellen).

Gruß
Jo

[Jonas2]

Du kannst mit dem PHPMyAdmin eine Datenbank exportieren (in eine Datei speichern) und dann auf einem anderen Server wieder importieren (aus der exportierten Datei die DB wieder erstellen).

Ich dachte schon an sowas wie eine Replikation.

Zum Anfang würde mir auch schon sowas wie ein incrementelles Backup per SSH reichen, was ich per Cron stündlich einspiele.

Jonas

[j4nk3y]

Hey,

Ich dachte schon an sowas wie eine Replikation.

Zum Anfang würde mir auch schon sowas wie ein incrementelles Backup per SSH reichen, was ich per Cron stündlich einspiele.

Hm, ist die Db überschaubar groß würde ich es auch so machen. Sprich ein Script per Cronjob, was beide Datenbanken vergleicht und fehlende Daten in der Zweiten nachträgt.

Bei größeren Datenbanken würde man aber sicher anders verfahren (aber frag mich bitte nicht wie).

Gruß
Jo

[Google weiß alles]

Hm, ist die Db überschaubar groß würde ich es auch so machen. Sprich ein Script per Cronjob, was beide Datenbanken vergleicht und fehlende Daten in der Zweiten nachträgt.

Vergiss nicht, abhängige Anwendungen zu sperren. Webseiten sollten den Status 503 "Service Unavailable" liefern. Nicht dass Google dann kaputte Seiten als Suchergebnis liefert. Das ist eine böse Blamage.

Insgesamt ist das keine gute Idee. Der vorgeschlagene externe Vergleich der Daten (in einem Skript) dauert lange und Du kannst nicht feststellen, ob auf dem Zielsystem Daten gelöscht wurden oder nie da waren. Schau also zu, dass Du alle Daten auf einem Datenbankserver hast, das ist auch der Sinn von den Dingern.

[TS]

Hallo und guten Morgen,

Zum Anfang würde mir auch schon sowas wie ein incrementelles Backup per SSH reichen, was ich per Cron stündlich einspiele.

Incrementelles Backup ist bei Datenbanken, speziell wenn sie etwas größer werden, nicht mehr lustig. Um damit später die Daten wiederhersstellen zu können, müsstest Du bei MySQL auch das binary Log aktivieren und das schreibt ruck-zuck deine Platte voll.

Es ist auch immer fraglich, was sinnvoller ist. Einen Snapshot der gesamten Datenbank zu bestimmten Zeiten einzufrieren, oder eine Real-Time Synchronisation durchzuführen. Bei der Synchronisation ist auch die Kopie kaputt, wenn jemand Schindluder damit treibt.

Bei MySQL auf Linux-Systemen hat es sich bis zu einer bestimmten Größe der DB als zweckmäßig erwiesen, den Datenbankserver kurz herunterzufahren (disable Login und flush Buffers reichen meistens), die Dateien innerhalb des Hosts auf eine zweite Platte zu kopieren. Zweite deshalb, damit der arme Actuator der Platten nicht vor lauter Sprüngen heiß läuft...

Dann kannst Du den Server schon wieder aktivieren.

Die Kopie kannst Du dann in Seelenruhe in einen Tarball verpacken und kompromieren. Das dauert etwas, deshalb sollte man den Vorgang vom Kopieren getrennt durchführen. Den kompromierten Tarball kannst Du dann noch einmal über Leitung auf ein fernes Gerät kopieren. Damit sollten die Kriterien für eine klassische Datensicherung schon fast erfüllt sein: drei inhaltlich identische Versionen (1 Original und 2 Kopien) derselben Daten auf drei getrennten Datenträgern an drei getrennten Orten aufbewahren.

Grüße
TS

[Jonas2]

Bei MySQL auf Linux-Systemen hat es sich bis zu einer bestimmten Größe der DB als zweckmäßig erwiesen, den Datenbankserver kurz herunterzufahren (disable Login und flush Buffers reichen meistens), die Dateien innerhalb des Hosts auf eine zweite Platte zu kopieren. Zweite deshalb, damit der arme Actuator der Platten nicht vor lauter Sprüngen heiß läuft...

Dann kannst Du den Server schon wieder aktivieren.

Die Kopie kannst Du dann in Seelenruhe in einen Tarball verpacken und kompromieren.

Danke, das ist schonmal ein guter Ansatz, wie ich finde. Wenn ich jetzt nicht den ganzen DB-Server als Ganzes, sondern die einzelnen DBs so behandele, dürfte der Ausfall gar nicht so lange sein.

Jonas

[Google weiß alles]

die Dateien innerhalb des Hosts auf eine zweite Platte zu kopieren. Danke, das ist schonmal ein guter Ansatz, wie ich finde.

• Dafür brauchst Du (System-)Root-Rechte auf BEIDEN Servern. Hattest Du nicht was geschrieben, dass Du diese nicht hast? Falls doch kannst Du auch replizieren.

Wenn ich jetzt nicht den ganzen DB-Server als Ganzes, sondern die einzelnen DBs so behandele, dürfte der Ausfall gar nicht so lange sein.

• Geht nicht mit dem Standardformat InnoDB, denn da sind die einzelnen Datenbanken/Tabellen nicht auf einzelne Ordner verteilt wie z.B. bei MyIsam. Schau einfach mal nach /var/lib/mysql/ (Standardordner für die MySQL-Datenbanken unter Linux).

##Lösungswege##

A:

Wenn direkte Netzwerkzugriffe auf mindestens einen der beiden SQL-Server (Standardport 3306) möglich sind und die Datenbanken nicht allzu groß sind kann man auch mit mysqlexport bzw. mysqlimport arbeiten.

• Dann wäre als "best of" noch mysqldbcopy im Angebot.

B:

Wenn Netzwerkzugriffe auf mindestens einen der beiden SQL-Server via SSH möglich sind und die Datenbanken nicht allzu groß sind kann man auch direkt mit mysqldump arbeiten.

Das sieht dann ETWA so aus:

user@HostLocal~> mysqldump -u user [[optionen] parameter] -p datenbank | ssh user@HostEntfernt mysql -u user --passwort="GeHeim" datenbank
# (Alles vorstehende ist eine Zeile!)

Es geht sowohl

• mysqldump | ssh user@HostEntfernt | mysql

(local nach entfernt)

als auch

• ssh user@HostEntfernt mysqldump | mysql.

(entfernt nach local)

Das ist das Prinzip, Optionen und Parameter fehlen.

Wenn die Datenbanken klein sind und einfach alles von A nach B geschaufelt werden soll sind das die gangbarsten Wege. Denk dran, die Webseiten bzw. Anwendungen zu sperren. Die Tabellen zu leeren oder zu droppen geht, in dem Du beim dumpen die Optionen setzt.

Geheimtipp: Teste das sehr gründlich bevor Du produktive Daten zerstörst.

[Google weiß alles]

Geheimtipp: Teste das sehr gründlich bevor Du produktive Daten zerstörst.

Weiterer Geheimtipp:

• Mach Backups auf beiden Seiten! Vertipper oder falsch gesetzte Optionen, womöglich einfache Verbindungsabbrüche sind geeignet um auf beiden Seiten die Daten, Datentabellen oder Datenbanken ins Nirwana zu "droppen".
• Kopiere ggf. die Backups(Dumps) mit ssh/scp/sftp statt zweimal zu dumpen.

[Jonas2]

die Dateien innerhalb des Hosts auf eine zweite Platte zu kopieren. Danke, das ist schonmal ein guter Ansatz, wie ich finde.

• Dafür brauchst Du (System-)Root-Rechte auf BEIDEN Servern. Hattest Du nicht was geschrieben, dass Du diese nicht hast? Falls doch kannst Du auch replizieren.

Sorry. Mein Fehler. Ich hatte überlesen, dass es um das Kopieren der Dateien ging. Insofern scheidet das bei mir natürlich aus.

Wenn direkte Netzwerkzugriffe auf mindestens einen der beiden SQL-Server (Standardport 3306) möglich sind und die Datenbanken nicht allzu groß sind kann man auch mit mysqlexport bzw. mysqlimport arbeiten.

Netzwerkzugriff sollte auf beiden Servern vorhanden sein. Kannst Du mir mal definieren, was bei einer Datenbank als "nicht allzu groß" bewertet wird?

• Dann wäre als "best of" noch mysqldbcopy im Angebot.

Ok.

Wenn Netzwerkzugriffe auf mindestens einen der beiden SQL-Server via SSH möglich sind und die Datenbanken nicht allzu groß sind kann man auch direkt mit mysqldump arbeiten.

Da isses wieder: "nicht allzu groß" :-)

Das sieht dann ETWA so aus:

user@HostLocal~> mysqldump -u user [[optionen] parameter] -p datenbank | ssh user@HostEntfernt mysql -u user --passwort="GeHeim" datenbank
# (Alles vorstehende ist eine Zeile!)

Es geht sowohl

• mysqldump | ssh user@HostEntfernt | mysql

(local nach entfernt)

als auch

• ssh user@HostEntfernt mysqldump | mysql.

(entfernt nach local)

Das ist das Prinzip, Optionen und Parameter fehlen.

Sieht gut aus. Mein Problem ist, ich sichere momentan 2 x täglich. Im Falle des falles gehen dan aber immer noch massig Daten verloren. Ich würde gerne etwas öfter sichern.

Geheimtipp: Teste das sehr gründlich bevor Du produktive Daten zerstörst.

Keine Frage.

Jonas

[Google weiß alles]

Netzwerkzugriff sollte auf beiden Servern vorhanden sein. Kannst Du mir mal definieren, was bei einer Datenbank als "nicht allzu groß" bewertet wird?

Da sind viele Unbekannte drin. Faustformel: Was Du vorhast dauert nur eine vertretbare Zeit.

Mein Problem ist, ich sichere momentan 2 x täglich. Im Falle des falles gehen dan aber immer noch massig Daten verloren. Ich würde gerne etwas öfter sichern.

## dbbackup.sh
filename="$(date +%Y-%m-%d_%H:%M)_dump.gz";
ssh user@host "mysqldump -u USER --password='geHeim' DATENBANK | gzip -c > /DIR/${filename}";
scp user@host://DIR/${filename}  ~/backups/;

Wenn die entfernte Datenbank direkt erreichbar ist:

## dbbackup.sh
filename="$(date +%Y-%m-%d_%H:%M)_dump.gz";
mysqldump -h HOST -u USER --password='geHeim' DATENBANK | gzip -c > /DIR/${filename};

Finden und löschen zu alter Backups geht mit find.

Wiederherstellen:

~> gzip -cd <  DATEI.gz | mysql -u USER --password='geHeim'

Wenn es nur um Backups geht dann besteht keine Notwendigkeit, die Daten in eine Datenbank einzulesen.

[Jonas2]

Wenn es nur um Backups geht dann besteht keine Notwendigkeit, die Daten in eine Datenbank einzulesen.

Prinzipiell richtig.Ixch hatte zuletzt einen längeren Serverausfall, da wärs einfach schön gewesen, komplett switchen und weiter arbeiten zu können. Danke für Deine Tips, die sehen sehr gut aus, ich arbeite gerade daran, sie in meiner Testumgebung einzubinden und ausgibig zu testen. Da ich das in wamp/cygwin mache, müssen noch ein paar Änderungen rein, aber das sieht bisher schon ganz gut aus.

Jonas

[Kay nicht angemeldet]

Hallo Forum,

gibt es einen Weg, eine mysql-Datenbank quasi "on the fly" auf einem anderen Server zu spiegeln? Vielleicht auc h, ohne gleich einen Rootserver zu haben, sondern einen "managed" Server?

Jonas

Mit DRBD kann man so einiges anstellen.

[Jonas2]

Hi Kai,

Mit DRBD kann man so einiges anstellen.

Wohl wahr. Aber nicht, wenn Du nicht volle Rotrechte auf beiden Servern hast ;)

Jonas

[Jonas2]

Wohl wahr. Aber nicht, wenn Du nicht volle Rotrechte auf beiden Servern hast ;)

Rotrechte != Rootrechte, ich weiß ;)

[MudGuard]

Hi,

Rotrechte != Rootrechte, ich weiß ;)

Worauf gründet sich dieses Wissen? Hat Dir das jemand eingebläut? ;-)

cu,
Andreas a/k/a MudGuard