lsyncd: inotify + rsync = admin-heaven

Ein Tool welches mir inzwischen an vielen Stellen exzellente Dienste leistet ist lsyncd.

Was macht lsyncd?

lsyncd kombiniert die Vorteile von inotify mit der Funktionalität von rsync. Das bedeutet, lsyncd hält eine entfernte Kopie eines Verzeichnisses dauerhaft auf dem Stand, der dem lokalen Verzeichnis entspricht.

Technisch gesehen beginnt lsyncd beim Start mit einen vollen rsync-Lauf, setzt aber gleichzeitig auf alle zu überwachenden Verzeichnisse und Unterverzeichnisse inotify-Watches. Alle Änderungen am Datenbestand werden jetzt vom Kernel an lsyncd gemeldet. Dieser Sammelt diese Meldungen und initiiert dann in kurzen Abständen für die geänderten Dateien einen erneuten rsync-Lauf.

Dieses Konzept ist einem periodischem Start von rsync doppelt überlegen. Zum einen erzeugt lsyncd wesentlich weniger Last (IO und CPU) auf dem System, zum anderen sind die möglichen Update-Intervalle deutlich kürzer.

Ok, bis hier habe ich die Möglichkeiten von lsyncd deutlich vereinfacht. Tatsächlich kann man bis ins kleinste Detail Skripten, welche Operationen lsyncd ausführt, wenn es eine inotify-Nachricht bekommt. Es gibt dazu aber drei Standardvorgaben, die für viele Zwecke vollkommen ausreichend sind.

Die Vorgaben sind rsync, rsyncssh und direct. Die ersten Beiden sind im Grunde identisch und gleichen nach dem ersten rsync weitere Änderungen immer per rsync aus. Es gibt bei rsyncssh aber eine Optimierung für die Fälle, in denen Dateien bzw. Verzeichnisse verschoben werden. Diese Verschiebeoperationen werden bei rsyncssh mittels eines per ssh aufgerufenen mv-Kommandos durchgeführt. direct ist nur für die lokale Verwendung geeignet, nach dem ersten rsync werden hier die Dateien per cp, rm und mv aktualisiert.

Das Konfigfile

Den grundlegenden Aufbau des Konfigfiles /etc/lsyncd.conf möchte ich an einem Beispiel auch noch vorstellen.

Der settings-Bereich definiert die Grundeinstellungen für den daemon. Die Option nodaemon kann auf true gesetzt werden, damit lsyncd beim starten nicht in den Hintergrund forkt. Logfile ist klar, statusFile gibt die Position einer von lsync regelmäßig aktualisierten Stausdatei an.

In der Statusdatei findet sich neben einem Zeitstempel Angaben über die ausstehenden Aktionen und die Liste aller inotify-Watches.

Danach folgen ein oder mehrerer sync{…}-Blöcke. Hier werden Quellverzeichnis, Ziel-Host und -Verzeichnis angegeben sowie diverse Optionen für rsync gesetzt.

settings  {
   logfile    = "/var/log/lsyncd.log",
   statusFile = "/var/run/lsyncd.status",
   nodaemon   = false
   }
sync {
   default.rsyncssh,
   source    = "/var/www/",
   host      = "10.0.0.2",
   targetdir = "/var/www/",
   delete = true,
   rsync = {
     archive = true,
   }

  sync {
    ...
  }

  ...

}

In diesem Beispiel wird als der Ordner /var/www zum Zielhost 10.0.0.2:/var/www gesynct. Zusätzlich wird lsync angewiesen Löschungen auch auf dem Ziel durchzuführen und die rsync-Option -a wird gesetzt.

Wie oft ein Abgleich durchgeführt wird steuert man mit den Optionen delay und mayDelays. Delay gibt die Zeit in Sekunden an, in denen lsynd Ereignisse bis zum nächsten Abgleich sammelt und maxDelays die Anzahl Ereignisse, nach denen lsyncd einen Abgleich startet auch wenn delay noch nicht abgelaufen ist. Ein Durchlauf wird also gestarten, wenn entweder delay Sekunden vergangen sind oder schon mayDelays Ereignisse gesammelt wurden.

Wozu nutzt man das jetzt?

Vielleicht überall wo man bisher rsync verwendet hat? Ich werde hier mal ein paar Szenarien vorstellen.

Cheap Failover

Das Szenario finde ich überaus nett. Man kann mit lsync und mysql-Replikation so ziemlich alle bekannteren CMS, Shop- oder Blogsysteme ausfallsicher machen. Ich synce also /var/www und die Datenbanken auf einen zweiten Server bei einem anderen Hoster, stellt die TTL im DNS halbwegs niedrig ein (z.B. 30 min). Wenn der Webserver stirbt setze ich im DNS die IP auf den Standby-Knoten und fertig.

Natürlich ist das kein tolle Umschaltzeit, es können sogar Datenverluste auftreten, aber für sehr viele Fälle ist das dennoch mehr als ausreichend. Im Gegenzug ist so ein Setup schnell aufgebaut, wenig komplex und komplett Providerunabhängig. Kosten-Nutzen-Mäßig absolut unschlagbar.

Cheap Undelete

Man nehme einen billigen PC, ein paar günstige Festplatten, btrfs oder zfs und synce seinen Fileserver auf diese Kiste. Dazu ein kleiner Cronjob der fleißig Snapshots erzeugt und alte löscht und fertig ist eine Lösung, mit der ich den Usern ihre gerade gelöschten Dateien wiederherstellen kann. Wer will kann auch seine Backup gegen diesen Host fahren und so die Last vom Fileserver nehmen. Nicht unbedingt Enterprise-Tauglich aber für KMUs erschwinglich und erstaunlich effektiv.

Monitoring nicht vergessen

Der lsyncd ist recht robust gegenüber Netzwerkstörungen, aber auch nicht komplett crashsicher. Daher fahre ich in meinem Monitoring ein kleines Skript gegen das lsyncd-Logfile, welches ein Hängen oder Abstürzen des Daemons erkennt und mich entsprechend alarmiert. Simple aber effektiv.

 

Veröffentlicht unter Allgemein | 3 Kommentare

MySQL – Benutzer und Rechte von einem Server auf den anderen Übertragen.

Eine einzelne Datenbank von Einem auf den anderen Server zu kopieren bzw. zu verschieben ist mit mysqldump einfach und schnell erledigt.

Etwas kniffliger ist das Übertragen der Rechte nur für diese Datenbank. Daher will ich hier zumindest in Grundzügen ein mögliches Vorgehen darlegen.

Grundidee: Mit dem MySQL-Befehl show grants kann man die kompletten Rechte eines Benutzers anzeigen lassen. Praktischerweise spuckt MySQL das gleich so aus, dass man die Befehler per Copy&Paste im Ziel-MySQL ausführen kann.

show grants bekommt als Parameter ein Argument der Form username@host. Um alle Rechte zu übertragen muss ich also alle username@host-Paare kennen, die Zugriff auf die Datenbank haben.

In den meisten Fällen kann ich diese aus der Tabelle db in der Datenbank mysql auslesen. Unter Umständen muss noch die Tabelle host hinzugezogen werden – das lasse ich jetzt hier erst einmal aussen vor.

mysql> select CONCAT(user,'@',host) from db where db='foo';
+-----------------------------------+
| CONCAT(user,'@',host) |
+-----------------------------------+
| foouser@256.239.2.2 |
| fooadmin@localhost |
| foouser@remoteminds.it |
+-----------------------------------+

Jetzt lasse ich auf jeden der user@host-Paare das show grants los:

mysql> show grants for foouser@256.239.2.2;
+------------------------------------------------------------------------------------------------------------------------------+
| Grants for foouser@256.239.2.2 |
+------------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'foouser@'256.239.2.2' IDENTIFIED BY PASSWORD '*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' |
| GRANT SELECT, CREATE TEMPORARY TABLES, LOCK TABLES ON `foo`.* TO 'foouser@'256.239.2.2' |
+------------------------------------------------------------------------------------------------------------------------------+

Die einzelnen GRANT-Statements muss ich jetzt per Copy&Paste auf dem Zielserver ausführen – fertig. Da show grants auch das Passwort mit ausspuckt brauche ich mich um nichts weiter zu kümmern.

Zu guter letzt hier noch ein Link zu einer allgemeinen Übersicht zur Benutzerverwaltung mit MySQL:

http://www1.uni-hamburg.de/RRZ/Software/MySQL/Benutzerverwaltung.htm

Veröffentlicht unter Kniffe, MySQL, SQL | Verschlagwortet mit , , | Hinterlasse einen Kommentar

innotop – innodb lock waits debuggen

Über diesen Artikel bin ich gerade gestolpert – perfekt um Probleme mit MySQL bzw. InnoDB zu debuggen.

Wer große Installationen verwaltet hat sicher schon einmal mit Locking bei MySQL gekämpft. Da ist jede Hilfe recht. Hier also ohne weitere Umschweife der Link:

http://www.xaprb.com/blog/2007/09/18/how-to-debug-innodb-lock-waits/

Hier noch die Liste der Pakete, die ich zum Starten von Innotop installieren musste:

sudo apt-get install libdbi-perl
sudo apt-get install libterm-readline-perl-perl
sudo apt-get install libdbd-mysql-perl

 

Veröffentlicht unter Kniffe, Linux, SQL, Tools | Hinterlasse einen Kommentar

setarch – Abweichende Rechnerarchitektur und Kernel-Version vorgaukeln

Das kleine Tool setarch, Teil von util-linux, manipuliert für damit gestartete Programme die Ausgabe von uname -m.

So etwas braucht man selten genug, mir hat es aber bei einem Problem mit der Ansys Workbench unter Ubuntu 12.04 (Precise Pengolin) gute Dienste geleistet.

Weiterlesen

Veröffentlicht unter Ansys, Kniffe, Linux, Ubuntu | 2 Kommentare

MS SQL Server Express – Backup mit Windows-Bordmitteln

In diesem Aktikel möchte ich zeigen, wie man einen Microsoft SQL-Server Express mit Windows-Bordmitteln auf ein Netzlaufwerk sichert

Dabei vergesse ich auch das Transaktionsprotokoll nicht und richte einen regelmäßigen Datenbankcheck ein.

Weiterlesen

Veröffentlicht unter SQL, Windows | 3 Kommentare