nicht angemeldet
Mysql-Datenbanken 1-2 mal täglich synchronisieren?
Hi,
ich müsste 3 Datenbanken (mysql 5) 1-2 mal am Tag von Server 1 zu Server 2 synchronisieren.
Leider habe ich auf beiden Servern zwar SSH-Zugang, aber nur Userrechte.
Wie bekomme ich damit am einfachsten (liebsten per cron) diese Art von Datensicherung hin?
Viele Grüße, Gin
-
ich müsste 3 Datenbanken (mysql 5) 1-2 mal am Tag von Server 1 zu Server 2 synchronisieren.
Wie bekomme ich damit am einfachsten (liebsten per cron) diese Art von Datensicherung hin?
Willst du jetzt sichern (Dump und per SCP/SFTP oder wie auch immer immer verschieben) oder Synchronisieren (Replikation)?
-
Willst du jetzt sichern (Dump und per SCP/SFTP oder wie auch immer immer verschieben) oder Synchronisieren (Replikation)?
Hi,
sichern würde ich mit etwas Aufwand vermutlich lösen können. Dazu gäbe es ja im mysql-dumper dieses nette crondump.pl-script. Wenn die DBs dann nicht zu groß sind, um die Scriptlaufzeit zu überreizen, würde das schon gehen.
Ich dachte eher an Synchronisation. Replikation wäre sicher der Idealfall, aber ich bin nicht sicher, ob hierzu Userrechte auf dem Server ausreichen. Ich glaube nicht.
Ich dachte, es wäre eventuell möglich, nur die Änderun gen (ich weiß aber nicht, wie) zu erfassen und diese dann automatisiert auf die anderen DB zu übertragen?
Fragende Grüße, Gin
-
Ich glaube du musst dich mit den Begrifflichkeiten auseinandersetzen bevor wir weiterreden - was willst du jetzt.
Ein Backup oder einen verfügbaren 1:1-Stand der Datenbank?
-
Ich glaube du musst dich mit den Begrifflichkeiten auseinandersetzen bevor wir weiterreden - was willst du jetzt.
Ein Backup oder einen verfügbaren 1:1-Stand der Datenbank?
Hi,
einen 1:1 Stand zum jederzeitigen Zeitpunkt wäre natürlich am schönsten. Aber das krieg ich mit meinen Möglichkeiten nicht hin. Dazu bräuchte ich entweder einen echten Root-Zugang (plus etwas mehr Wissen) oder viel Geld, um mir beides einzukaufen ;-)
Also würde mir auch ein 1:1 Stand mit 1 Tag Zeitdifferenz genügen.
Dann aber nicht als Backup, sondern als wirkliche DB.
Viele Grüße, Gin
-
-
-
-
Hi!
ich müsste 3 Datenbanken (mysql 5) 1-2 mal am Tag von Server 1 zu Server 2 synchronisieren.
Was verstehst du in diesem Fall unter synchronisieren? Einweg/Backup oder Zweiweg oder was anderes?
Leider habe ich auf beiden Servern zwar SSH-Zugang, aber nur Userrechte.
Reicht doch, oder nicht?
Wie bekomme ich damit am einfachsten (liebsten per cron) diese Art von Datensicherung hin?
Cron wird wohl Teil der Lösung sein. Der Rest kann je nach konkretem Bedarf komplex oder einfach sein.
Lo!
-
Hi,
Was verstehst du in diesem Fall unter synchronisieren? Einweg/Backup oder Zweiweg oder was anderes?
Einweg.
Reicht doch, oder nicht?
Da bin ich nicht sicher. Klar, wenn ich das über Backup ziehen ---> Backup restoren mache, sollte es ausreichen.
Cron wird wohl Teil der Lösung sein. Der Rest kann je nach konkretem Bedarf komplex oder einfach sein.
Ich dachte, eventuell führt ja mysql einen Log mit, in dem alle Änderungen aufgezählt werden und den könnte man auswerten?
Fragende Grüße, Gin
-
Hi!
Was verstehst du in diesem Fall unter synchronisieren? Einweg/Backup oder Zweiweg oder was anderes?
Einweg.Also Dump inklusive DROP und CREATE TABLE und den auf dem Zielsystem laufen lassen. PHP-Script-Laufzeiten sind dabei egal, denn Shell-Scripts unterliegen dieser nicht. Für PHP-CLI ist die Script-Laufzeit per Default auf 0 gestellt, also unendlich - stört ebenfalls nicht. Du solltest auch prüfen, ob dein SSH-Zugang im chroot läuft und deshalb nur eingeschränkt arbeiten kann.
Eine einfache Lösung könnte sein, auf dem Quellserver per cron einen Dump zu erzeugen. 5 Minuten später läuft dann auf dem Zielserver ein Cron-Job los, der per scp (ssh-copy) die Dumpdatei holt und gegen den lokalen MySQL-Server laufen lässt. (Mit welchen Parametern so ein scp automatisiert gestartet werden kann, inklusive wie man die nötigen Schlüssel erzeugt, ist ausreichend im Web beschrieben.)
Cron wird wohl Teil der Lösung sein. Der Rest kann je nach konkretem Bedarf komplex oder einfach sein.
Ich dachte, eventuell führt ja mysql einen Log mit, in dem alle Änderungen aufgezählt werden und den könnte man auswerten?Ja, das Binary-Log macht sowas. Das wird für die MySQL-Replication verwendet. Man kann es jedoch nur einschalten, wenn man die Konfiguration ändern kann. Ein "Anwender-Log" geht nur über Trigger zu realisieren.
Lo!
-
Hi,
PHP-Script-Laufzeiten sind dabei egal, denn Shell-Scripts unterliegen dieser nicht.
Danke für den Hinweis :-)
Du solltest auch prüfen, ob dein SSH-Zugang im chroot läuft und deshalb nur eingeschränkt arbeiten kann.
Was bedeutet das genau: chrooted SSH-Zugang?
Eine einfache Lösung könnte sein, auf dem Quellserver per cron einen Dump zu erzeugen. 5 Minuten später läuft dann auf dem Zielserver ein Cron-Job los, der per scp (ssh-copy) die Dumpdatei holt und gegen den lokalen MySQL-Server laufen lässt. (Mit welchen Parametern so ein scp automatisiert gestartet werden kann, inklusive wie man die nötigen Schlüssel erzeugt, ist ausreichend im Web beschrieben.)
Ok. Das ist ein klasse Hinweis.
Ja, das Binary-Log macht sowas. Das wird für die MySQL-Replication verwendet. Man kann es jedoch nur einschalten, wenn man die Konfiguration ändern kann. Ein "Anwender-Log" geht nur über Trigger zu realisieren.
Welche der beiden Lösungen ist die "bessere"? Was meinst Du?
Viele Grüße, Gin
-
Hi!
Du solltest auch prüfen, ob dein SSH-Zugang im chroot läuft und deshalb nur eingeschränkt arbeiten kann.
Was bedeutet das genau: chrooted SSH-Zugang?Jetzt sag nicht, dass du nicht "chroot" in die Wikipedia oder eine Suchmaschine eingegeben hast.
[Backup-Script vs. Trigger]
Welche der beiden Lösungen ist die "bessere"? Was meinst Du?Ein Trigger (oder MySQL allgemein) kann keine externen Prozesse anstoßen. Mit einem Trigger kannst du nur Änderungen in einer anderen Tabelle vornehmen. (Ein Trigger kann schon noch etwas mehr, aber das ist für den vorliegenden Fall nicht relevant.) Das nützt dir nur dann etwas, wenn du andere Server über die FEDERATED Storage Engine anbinden kannst. Allerdings würde ich das nur über SSH tunneln wollen und nicht einen offenen MySQL-Server in die Landschaft setzen.
Lo!
-
Hi,
Jetzt sag nicht, dass du nicht "chroot" in die Wikipedia oder eine Suchmaschine eingegeben hast.
Verstehe ich das also recht, dass ein chrooted SSH-Zugang gar nix außerhalb des "home" Verzeichnisses (also seknes roots) darf und ein nicht chrooted SSH-Zugang alles darf, was halt seine Userrechte hergeben?
Worin im Speziellen (also welche Befehle) würden denn hier den Unterscheid machen?
Viele Grüße, Gin
-
Hi!
Verstehe ich das also recht, dass ein chrooted SSH-Zugang gar nix außerhalb des "home" Verzeichnisses (also seknes roots) darf und ein nicht chrooted SSH-Zugang alles darf, was halt seine Userrechte hergeben?
Ja, zumindest was die Dateizugriffe anbelangt. Verbindungen über TCP/IP zum Beispiel sind davon nicht betroffen.
Worin im Speziellen (also welche Befehle) würden denn hier den Unterscheid machen?
Alles was du im chroot-Gefängnis ausführen willst, muss sich dort drin befinden - vom einfachsten ls bis zum komplexesten Programm. Da das komplett individuell gestaltbar ist, kann man als Außenstehender diese Frage nicht genau beantworten.
Lo!
-
-
-
-
Tach,
Eine einfache Lösung könnte sein, auf dem Quellserver per cron einen Dump zu erzeugen. 5 Minuten später läuft dann auf dem Zielserver ein Cron-Job los, der per scp (ssh-copy) die Dumpdatei holt und gegen den lokalen MySQL-Server laufen lässt.
fast gut, aber was wenn das schreiben mal länger dauert oder mit einem Fehler abbricht? Besser nur ein Cronjob der alles tut; je nachdem auf welcher Kiste der läuft muss dann entweder das Dumpen oder das Einlesen per SSH angeschmissen werden.
mfg
Woodfighter-
Hi!
Eine einfache Lösung könnte sein, auf dem Quellserver per cron einen Dump zu erzeugen. 5 Minuten später läuft dann auf dem Zielserver ein Cron-Job los, der per scp (ssh-copy) die Dumpdatei holt und gegen den lokalen MySQL-Server laufen lässt.
fast gut, aber was wenn das schreiben mal länger dauert oder mit einem Fehler abbricht? Besser nur ein Cronjob der alles tut; je nachdem auf welcher Kiste der läuft muss dann entweder das Dumpen oder das Einlesen per SSH angeschmissen werden.Ja, aber bei 1-2 mal täglich spielt es eher weniger eine Rolle, ob es mal nicht klappt, wenn der Backup-Prozess abbricht. Dann hat man entweder eine alte oder gar keine Dump-Datei. Das Ergebnis des Einlese-Jobs ist dann das gleiche als wenn das eine Backup-plus-Transfer-und-Einlesen-Script abbricht.
Etwas mehr Kontrolle (für Fehler in beiden Szenarien) könnte man mit Monit hinbekommen. Wenn Dateidatum sich nicht ändert oder Größe = 0 ist, dann schrei(b eine EMail).
Lo!
-
Tach,
Ja, aber bei 1-2 mal täglich spielt es eher weniger eine Rolle, ob es mal nicht klappt, wenn der Backup-Prozess abbricht. Dann hat man entweder eine alte oder gar keine Dump-Datei. Das Ergebnis des Einlese-Jobs ist dann das gleiche als wenn das eine Backup-plus-Transfer-und-Einlesen-Script abbricht.
vermutlich, aber ein möglicher Worst-Case wäre: der Dump bricht in der Mitte ab, erstellt dabei aber einen syntaktisch korrekten Dump und der SQL-Server verabschiedet sich, kurz danach wird der teilweies vorhandene Dump eingelesen und auch auf der Backup-Kiste fehlen jetzt einige Tabellen.
Etwas mehr Kontrolle (für Fehler in beiden Szenarien) könnte man mit Monit hinbekommen. Wenn Dateidatum sich nicht ändert oder Größe = 0 ist, dann schrei(b eine EMail).
Aber wozu weitere Software installieren, wenn das alles problemlos mit den schon vorhandenen Mitteln machbar ist, um die Mail kümmert sich ja schon cron.
Ich meine
/usr/bin/mysqldump -A |gzip - >/var/backups/mysql.gz && \ /usr/bin/scp /var/backups/mysql.gz user@host:/var/backups/mysql.gz && \ /usr/bin/ssh user@host "/usr/bin/gunzip < /var/backups/mysql.gz | /usr/bin/mysql"(ungetestet, vermutlich nicht ganz richtig und schickt vermutlich mails, weil irgendwo Ausgaben passieren) ist ja nun kein Hexenwerk.
Weiterer Vorteil meiner Methode ist, dass alles nur an einem Ort konfiguriert werden muß, es erzeugt keine Probleme, wenn mal die Serverzeit divergiert ...
mfg
Woodfighter
-
-
-
-
-