Wenn man Administrator eines produktiv genutzten Mailservers ist, macht man sich schon ab und zu mal Gedanken, wie man die Probleme, welche beim Betrieb des Servers auftreten oder auftreten könnten, mit möglichst wenig Aufwand – jetzt im Sinne von möglichst wenig Aufwand in der Zukunft – lösen kann. Ich betreibe einen kostenlosen E-Mail Dienst mit derzeit ca. 12.000 Usern. Seit 1998 hat sich das Setup des Mailservers eigentlich kaum geändert. Damals war sendmail noch das Nonplusultra, man war stolz dass SMTP-Auth und diverse Workarounds wie POP-Before-SMTP etc funktionierten, und im Allgemeinen gab es auch weniger SPAM. Zu dieser Zeit hatte quickemail.de ca. 500 User und die Welt der Flat-File Konfiguration war noch in Ordnung.

Irgendwann reicht das jedoch nicht mehr aus – Flat-Files werden schnell unübersichtlich und es musste eine Lösung her, um zumindest die E-Mail Accounts und User zu verwalten. Eine mySQL Datenbank war schnell aufgesetzt und mit ein paar Scripts und Cronjobs wuchs die Userbase dann immer weiter an. Da gingen dann aber auch die Probleme los.

SPAM von Botnets == DDOS?

Wenn man mehrere tausend User auf einer physikalischen Maschine hat, bringt das diverse Probleme mit sich. Zum einen braucht man ständig größere Festplatten, zum anderen natürlich auch mehr CPU und RAM. Das lässt sich eigentlich auf normaler Hardware noch relativ einfach erweitern. Problematisch wird das ganze dann, wenn man distributed SPAM von diversen Botnets abbekommt. Nicht nur der Mailserver an sich ist hier dann überfordert – bei jedem Connect wird ein nslookup durchgeführt, was sich auch wieder mit erhöhter Last auf den Nameservern auswirkt. Irgendwann ist dann jedoch Schluss – bei 200 gleichzeitigen Connects und einer Load von >100 kann es schon mal ein paar Minuten dauern, bis man diverse Services gestoppt hat um zumindest die Maschine wieder administrieren zu können.

SPOFs am laufenden Band

Eine einzelne Maschine zu verwenden ist natürlich auch nicht gerade von Vorteil. Fällt die Hardware aus, oder sind die Platten voll, steht die Maschine und nichts geht mehr. Klar kann man solche Ausfälle durch gutes Monitoring minimieren, spätestens jedoch beim nächsten Upgrade steht der Dienst erst mal wieder.

Wie man diese Probleme in den Griff bekommt?

Nun, wenn man nicht gerade im Lotto gewonnen hat, braucht man hier eine günstige Lösung die dennoch gut skaliert und fehlertolerant ist, also die Mails an sich redundant speichert, sowie mehrere Server zur Verfügung stellt um bei einem ausgefallenen System dennoch den Dienst aufrecht erhalten zu können. Das gestaltet sich jedoch gar nicht so einfach. Alleine dafür zu sorgen, dass die Daten auf allen Maschinen synchron sind, ist eine Herausforderung.

Es gibt diverse Lösungen mit NAS oder DRBD, proprietäre Lösungen von diversen Herstellern, Backup-Mailserver, etc – aber eine wirkliche günstige Alternative die mit normaler x86er Hardware auskommt, und bei der man nicht Tausende Euro Lizenzgebühren zahlen muss, hatte ich bisher noch nicht gefunden.

Deshalb habe ich mich mal eine Woche intensiv damit beschäftigt, das Mailproblem, zumindest für mich, ein für alle mal zu Lösen.

Daten redundant speichern…

kann man zum Beispiel mit mysql-ndb – Das war auch mein erster Versuch. Da man seit mySQL 5.1.6 bzw. der 6.2er NDB-Engine endlich Tables auch ondisk speichern kann, dachte ich das sei einen Versuch wert. Allerdings gibt es bei mySQL immer noch das Problem, dass die Indizes in-memory sein müssen. Bei einer Mailbase von sagen wir mal ca. 40GB kommt man so locker auf einen RAM-Bedarf von 8GB und mehr.

Dann gibt es noch die Möglichkeit dies einfach mit Master-Slave Replication zu lösen, hier ist jedoch das Problem, dass sobald der Master-Server ausgefallen ist, die User keine Daten mehr schreiben können und man nur noch Read-Only Access hat. Deshalb sind auch Lösungen wie PG-Pool oder Slony nicht wirklich praktikabel. Aber es gibt ja noch PGCluster. PG-Cluster ist im Vergleich zu mySQL-NDB wesentlich besser geeignet, um Daten redundant in einer Datenbank zu speichern. Hier müssen die Indizies nicht in-memory sein. Das derzeitige Release pgcluster1.9-rc5 basiert auf postgres 8.3 und funktioniert – sofern richtig konfiguriert – einwandfrei. Schade ist jedoch, dass auf der offiziellen Webseite von PG-Cluster immer noch die Version 1.3 als aktuell bezeichnet wird und das letzte Update der Seite irgendwann in 2005 war. Deshalb habe ich während der Evaluierungsphase erst PG-Cluster 1.3, dann den Fork cybercluster, und dann erst PG-Cluster 1.9 getestet. Mit PG-Cluster hat man zumindest schon mal das Problem ausgemerzt, dass man sich nicht mehr darum kümmern muss, was mit den Daten passiert. Die Master-Master oder auch Active-Active Replikation von PG-Cluster gewährleistet synchrone Daten über alle Cluster-Nodes hinweg.

Redundante Daten – und was machen wir nun damit?

Nach einiger Zeit googeln bin ich dann auf den dbmail gestossen – ein User aus dem IRC-Channel #linux.de hatte mich darauf hingewiesen, dass es soetwas bereits gibt. Bei dbmail werden alle E-Mails, Accounts, Forward etc. in der Datenbank gespeichert. In Verbindung mit PG-Cluster ergibt sich dann hier eben die Möglichkeit, Mailserver-Nodes zu betreiben die synchron sind. Die Last lässt sich dann via DNS-Roundrobin über die Mailserver und bei der Datenbank  mit dem PG-Loadbalancer verteilen. Mein aktuelles Setup sieht wie folgt aus:

Mit diesem Setup ist man dann in der Lage, solange zumindest ein Node online ist, die Mail-Services aufrecht zu erhalten. dbmail liefert ein Script mailbox2dbmail mit – damit lassen sich Mailboxen im mbox, maildir und mhdir Format leicht in dbmail einpflegen. Wie man so ein Setup bewerkstelligt, möchte ich hier nun kundtun. Ich selbst habe für mein aktuelles Setup ca. eine Woche gebraucht – das liegt aber auch daran, weil ich alles Mögliche getestet habe um herauszufinden, was am Besten funktioniert. Bei dbmail musste ich selbst einige Zeilen im Source-Code ändern. Auch Cyrus SASL muss man patchen, aber am Ende ist es das Alles wert.

Howto begin?

Als aller erstes benötigen wir mind. 2 Server. Wer möchte kann das auch zuerst innerhalb eines VServers oder VMware Session testen – ich rate dringend dazu, um sich mit der Sache etwas vertraut zu machen.

Die Server werden frisch mit Debian Etch installiert. Damit hier pgcluster allerdings kompiliert, müssen einige Pakete nachinstalliert werden – und nach dem ./configure muss man noch ein Makefile anpasssen. Benötigt wird build-essential libreadline5 libreadline5-dev asciidox flex bison libssl-dev rsync ssh. Sollte hier noch etwas fehlen, werde ich es zu gegebener Zeit ergänzen. Wichtig ist, dass das System eine utf8-Locale installiert hat und diese auch verwendet wird – sonst gibt es später Probleme mit PostgreSQL.

wget http://pgfoundry.org/frs/download.php/1705/pgcluster-1.9.0rc5.tar.gz
tar -xvzf pgcluster-1.9.0rc5.tar.gz
cd pgcluster-1.9.0rc5
./configure
make
make install

Postgres wird dann in /usr/local/pgsql installiert. Wer es woanders haben möchte, gibt einen Prefix beim configure mit an.

User anlegen, Rechte setzen:

cd /usr/local
useradd -d /usr/local/pgsql postgres
groupadd postgres
chown postgres.postgres pgsql -R

Hat man dies auf allen Nodes erledigt, wird mit initdb die Datenbank initialisiert:

su postgres
cd /usr/local/pgsql
./bin/initdb --locale=de_DE.utf8 data

Im Verzeichnis data legen wir dann auch entsprechend die Konfiguration für den Cluster an. Wichtig ist hierbei dass die Konfiguration bei allen Nodes identisch ist. Zuerst muss man die Datei pg_hba.conf im data Verzeichnis bearbeiten. Hier wird festgelegt, welcher Rechner sich zu der Datenbank verbinden darf. Das Ganze ist IP-basierend. Man sollte in jedem Fall für jeden Host einen eintrag in /etc/hosts machen, um DNS-Problemen innerhalb des Clusters aus dem Weg zu gehen – ich gehe hier bei diesem Howto mal davon aus, dass zuerst das ganze in einer Testumgebung installiert wird:

In pg_hba.conf unter der Zeile:

# IPv4 local connections:

muss für jeden Host des Clusters ein Eintrag gemacht sein:

host  all  all 192.168.0.10/32 trust # node01
host  all  all 192.168.0.20/32 trust # node02

Dies stellt sicher, dass die Nodes des Clusters gegenseitigen Zugriff auf sich selbst haben. Wichtig: man darf es nicht versäumen auch dem lokalen node Connections von sich selbst zu erlauben – daher ist auch bei node01 die IP für den node01 freizugeben.

Nun müssen wir die Datei cluster.conf im data Verzeichnis anlegen. Hier wird festgelegt, wohin repliziert werden soll:

<Replicate_Server_Info>
        <Host_Name> node01 </Host_Name>
        <Port>           5810 </Port>
        <Recovery_Port>  5811 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
        <Host_Name> node02 </Host_Name>
        <Port>           5810 </Port>
        <Recovery_Port>  5811 </Recovery_Port>
</Replicate_Server_Info>
</Replicate_Server_Info>
<Host_Name> node01 | node02 </Host_Name>
# Der Host_Name muss dem jeweiligen Node angepasst werden!
#
<Recovery_Port>         5611 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh </Rsync_Option>
<Rsync_Compress> yes </Rsync_Compress>
<When_Stand_Alone> read_write  </When_Stand_Alone>
<Pg_Dump_Path> /usr/local/pgsql/bin/pg_dump</Pg_Dump_Path>
<Replication_Timeout> 1min</Replication_Timeout>
<LifeCheck_Timeout>3s</LifeCheck_Timeout>
<LifeCheck_Interval>15s</LifeCheck_Interval>

Nachdem die cluster.conf angelegt wurde, fehlt noch die pgreplicate.conf – hier wird festgelegt, von welchen Nodes gelauscht werden soll um die Queries zu replizieren:

<Cluster_Server_Info>
        <Host_Name> node01 </Host_Name>
        <Port>           5432 </Port>
        <Recovery_Port>  5611 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
        <Host_Name> node02 </Host_Name>
        <Port>           5432 </Port>
        <Recovery_Port>  5611 </Recovery_Port>
</Cluster_Server_Info>
<Host_Name> node01 | node02 </Host_Name>
# Der Host_Name muss dem jeweiligen Node angepasst werden!
#
<Replication_Port>    5810    </Replication_Port>
<Recovery_Port>       5811    </Recovery_Port>
<Response_Mode>       normal  </Response_Mode>
<Use_Replication_Log> yes     </Use_Replication_Log>
<RLOG_Port>           8301    </RLOG_Port>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>

Soweit so gut, PG-Cluster sollte jetzt lauffähig sein und Queries replizieren. Starten müssen wir das Ganze auf beiden Nodes noch:

su postgres
cd /usr/local/pgsql
./bin/pg_ctl -D data start
./bin/pgreplicate -D data

Man kann jetzt das ganze einmal testen indem man einfach eine Datenbank erzeugt, eine Tabelle anlegt, und von beiden Nodes Inserts durchführt:

./bin/createdb test
./bin/psql test
create table test ( test varchar(255));

# Dann jeweils auf beiden Nodes abwechselnd
#
insert into test (test) values (test1);
insert into test (test) values (test2);
select * from test;

Man kann jetzt beobachten, wie die Queries repliziert werden.

dbmail Setup

Auch hier müssen wir zuerst dbmail holen, entpacken und installieren:

cd /usr/src
wget http://www.dbmail.org/download/2.2/dbmail-2.2.11-rc3.tar.gz
tar -xvzf dbmail-2.2.11-rc3.tar.get
cd dbmail-2.2.11-rc3
./configure --with-pgsql=/usr/local/pgsql

Unter Debian Etch man/Makefile editieren, Zeile 547:
von:         asciidoc -b docbook -d manpage $<
zu:          asciidoc --unsafe -b docbook -d manpage $<

make
make install

dbmail ist jetzt in /usr/local/sbin installiert. Die Konfiguration dbmail.conf kann man nach /etc/ kopieren und anpassen. Wer pglb (Loadbalancer) verwenden will, muss vor dem kompilieren in modules/dbpgsql.c nach Zeile 110 Folgendes einfügen:

        g_string_append_printf(cs, " sslmode='disable'");

und der eigentliche MTA?

nun fehlt noch postfix. Postfix wird mit apt-get install postfix postfix-pgsql installiert. Wenn man sasl verwenden möchte, sei darauf hingewiesen, dass man hier ein gepatchtes sasl braucht, welches gecryptete Passwörter in der DB zulässt. Meine main.cf für Postfix sieht dann so aus:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
myhostname = node01
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, mysql:/etc/postfix/sql-mydestination.cf
mynetworks = 127.0.0.0/8
mailbox_command = procmail
mailbox_size_limit = 0
recipient_delimiter = +
local_recipient_maps = pgsql:/etc/postfix/dbmail_rcpt.cf, pgsql:/etc/postfix/dbmail_rcpt_alias.cf
local_transport = dbmail-smtp:
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
                           permit_mynetworks,
                           reject_invalid_hostname,
                           reject_non_fqdn_sender,
                           reject_non_fqdn_recipient,
                           reject_unknown_recipient_domain,
                           reject_unauth_pipelining,
                           reject_unknown_sender_domain,
                           permit_sasl_authenticated,
                           reject_unauth_destination
smtpd_sender_restrictions =
                           permit_mynetworks,
                           reject_authenticated_sender_login_mismatch,
                           permit_sasl_authenticated,
                           reject_sender_login_mismatch,
                           reject_unknown_sender_domain,
                           reject_unauth_destination,
                           reject_unknown_recipient_domain
check_sender_access = hash:/etc/postfix/sender_access
smtpd_sender_login_maps = pgsql:/etc/postfix/dbmail_sender_login.cf, pgsql:/etc/postfix/dbmail_sender_login_alias.cf
content_filter = smtp-amavis:[127.0.0.1]:10024

Dann hier noch die Files welche für sasl benötigt werden:

cat dbmail_rcpt.cf
user = dbmail
password = xxxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT userid FROM dbmail_users WHERE userid='%s'

cat dbmail_rcpt_alias.cf
user = dbmail
password = xxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT alias FROM dbmail_aliases WHERE alias='%s'

cat dbmail_sender_login.cf
user = dbmail
password = xxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT userid FROM dbmail_users WHERE userid='%s'

cat dbmail_sender_login_alias.cf
# SMTP AUTH - check if the alias exists
user = dbmail
password = xxxxxxxxxx
dbname = dbmail
hosts = node01
query = SELECT userid FROM dbmail_users JOIN dbmail_aliases ON ( CAST (dbmail_aliases.deliver_to as bigint)=cast(dbmail_users.user_idnr as bigint)) WHERE dbmail_aliases.alias='%s';

cat sql-recipients.cf
user = dbmail
password = xxxxxxxxxxxxx
hosts = node01
dbname = dbmail
query =  SELECT alias FROM dbmail_aliases WHERE alias='%s' UNION SELECT userid FROM dbmail_users WHERE userid='%s';

Ich selbst habe meine relay-Domains noch in der mySQL Datenbank stehen, hier kann aber auch einfach nur das Hash-File verwendet werden. Jetzt steht die Postfix Konfiguration auch soweit. Wir müssen jetzt noch das DB-Layout in der Datenbank anlegen:

su postgres
cd /usr/local/pgsql
./bin/createdb dbmail
./bin/createuser dbmail
./bin/psql -U dbmail dbmail </usr/src/dbmail-2.2.11-rc3/sql/postgresql/create_tables.pgsql

Nun kann man postfix starten/restarten. Die pop3 und imap services startet man in /usr/local/sbin mit ./dbmail-imapd sowie ./dbmail-pop3d – Nützlich ist auch dbmail-users und dbmail-util.

Die amavis Konfiguration sowie das Anlegen und Verwalten von Usern möchte ich hier nicht weiter behandeln, da hier wohl jeder Admin seine eigenen Preferenzen hat. Dennoch hoffe ich hier etwas Wissen in PG-Cluster und dbmail vermittelt zu haben und wünsche viel Spass mit dem neuen Mailsetup. Die bisherigen Probleme sollten damit alle passé sein.

Um diese defekten Tabellen zu reparieren, kann man z.B. myisamchk mit den Optionen -rf im Datenverzeichnis von mySQL (unter Debian /var/lib/mysql) die Datenbanken reparieren. Alternativ kann man dies jedoch auch direkt mit mySQL erledigen, der Syntax lautet dann REPAIR TABLE <tabellenname>.

Dies jedoch manuell über alle Tabellen auszuführen, ist lästig, weshalb ich hier einen Code-Schnipsel bereitstelle, der alle Tabellen in allen Datenbanken repariert – dies funktioniert jedoch nur mit der Datenbank Engine MYISAM:

<?php

$db=mysql_connect(“localhost”,”root”,”<passwort>”);

$sql = “show databases;”;

$res_db = mysql_query($sql,$db);

while ($dat_db = mysql_fetch_array($res_db)) {

$datab = $dat_db["Database"];

mysql_select_db($datab,$db);

$sql = “show tables;”;

$res = mysql_query($sql,$db);

while ($dat = mysql_fetch_array($res)) {

$table = $dat[0];

$sql2 = “repair table $table”;

$res2 = mysql_query($sql2,$db);

}

}

?>

Man kann dieses Script speichern, die Modes auf executable setzen und es am Ende in /etc/init.d/mysql anfügen, damit die Tabellen automatisch nach jedem Start von mysql repariert werden.

Meist wird dann hierzu ein Loadbalancer (ob Hardware oder Software ist erst mal egal) aufgesetzt, welcher die Anfragen an mehrer Server verteilt, welche sich einen gemeinsammen Massenspeicher teilen. Dadurch ist es möglich, dass einzelne Server gewartet werden können, bzw. auch ausfallen können, ohne dass die Applikation dadurch gestört wird.

Leider beschränkt sich diese Variante auf nur eine Location, d.h. wird aus irgendwelchen Gründen z.B. die Internetanbindung an das System unterbrochen, ist die Applikation offline.

Dies kann man damit umgehen, dass man das System multihomed aufbaut, d.h. mehrere Server an unterschiedlichen Standorten betreibt, um bei einem Ausfall von einem Standort trotzdem noch erreichbar zu sein. Diese Variante hat den Nachteil, dass die Daten des Systems sehr aufwändig synchronisiert werden müssen, falls ein Standort nicht mehr erreichbar war. Weiterhin muss man auch bei Updates etc. aufpassen, dass es keine Versionskonflikte bei der Applikation gibt, denn man kann die Software nicht an beiden Standorten gleichzeitig aktualisieren.

Benötigt wird für so eine Lösung also zum einen eine Datenbank, welche automatisch repliziert und dies auch über mehr als einen Standort hinweg, weiterhin dazu noch ein Dateisystem, welches verteilten Host-Systemen eine gemeinsame Datenbasis bereitstellen kann.

Zu diesem Zweck habe ich auf mehreren Test-Systemen eine solche Umgebung aufgebaut und will hier diesen Test dokumentieren. Ich habe dazu einfach 2 Systeme innerhalb eines VMware Servers erzeugt:

mysqlfsdevelop01 sowie mysqlfsdevelop02, mit folgender Konfiguration:

• 2 GB HDD Space
• Netzwerkkarte
• 256MB RAM
• CD-ROM (mit gemountetem Disk-Image Debian-Etch 4.0)

Nachdem man die Hosts in VMware angelegt hat, und Debian Etch auf diesen installiert ist, muss man noch einige Pakete nachinstallieren, mit

apt-get install build-essentials

zuerst alle benötigten Pakete installieren, damit man selbst Software kompilieren kann.

Weiterhin werden dann noch folgende Pakete benötigt:

apt-get install fuse-utils afuse libfuse-dev libmysqlclient15-dev libmysql++-dev glibc-dev mysql-server-5.0

Eine Liste aller installierten/benötigten Pakete gibt es hier

Nachdem also unser Debian auf beiden Host-Systemen installiert ist, müssen wir noch unseren mySQL Server so konfigurieren, dass auf diesem NDB läuft. Dazu müssen auf beiden Host-Systemen Änderungen an der /etc/mysql/my.cnf vorgenommen werden:

• unter [mysqld] den Paramenter ndbcluster ohne Option hinzufügen
• [MYSQL_CLUSTER] suchen und die Rauten entfernen
• ndb-connectstring=127.0.0.1 kann beibehalten werden

Dann die Datei speichern. mySQL noch nicht neu starten!

Dann wird in /etc/mysql/ die Datei ndb_mgmd.cnf angelegt, und folgender Inhalt eingefügt:


[NDBD DEFAULT]
NoOfReplicas=2

[MYSQLD DEFAULT]

[NDB_MGMD DEFAULT]

[TCP DEFAULT]

# Section for the cluster management node
[NDB_MGMD]
# IP address of the management node (this system)
HostName=192.168.200.40

#IP des ersten Nodes (mysqlfsdevelop01)

[NDB_MGMD]
# IP address of the management node (this system)
HostName=192.168.200.41

#IP des zweiten Nodes (mysqlfsdevelop02)

# Section for the storage nodes
[NDBD]
# IP address of the first storage node
HostName=192.168.200.40
DataDir= /var/lib/mysql-cluster

[NDBD]
# IP address of the second storage node
HostName=192.168.200.41
DataDir=/var/lib/mysql-cluster

# one [MYSQLD] per storage node
[MYSQLD]
[MYSQLD]

Die Datei muss auf beiden Systemen angelegt werden, bei mysqlfsdevelop02 allerdings bei [NDB_MGMD] die IP des zweiten Servers angeben, so dass auf beiden Systemen ein Management-Daemon läuft.

Nun starten wir zuerst den Management-Daemon, dann die NDB-Datenbank und zuletzt restarten wir mysql selbst (als API):

/etc/init.d/mysql-ndb-mgm start

/etc/init.d/mysql-ndb start

/etc/init.d/mysql restart

Danach kann man mit ndb_mgm eine Konsole auf den NDB-Cluster öffnen. Ein “show” sollte folgenden Output erzeugen:

ndb_mgm> show
Connected to Management Server at: 127.0.0.1:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=3 (not connected, accepting connect from 192.168.200.40)
id=4 @192.168.200.41 (Version: 5.0.32, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 2 node(s)
id=1 @192.168.200.40 (Version: 5.0.32)
id=2 @127.0.0.1 (Version: 5.0.32)

[mysqld(API)] 2 node(s)
id=5 @192.168.200.40 (Version: 5.0.32)
id=6 @192.168.200.41 (Version: 5.0.32)

Wenn dies soweit läuft, ist der erste Schritt getan.

Jetzt muss mysqlfs mit cvs heruntergeladen werden und übersetzt werden.

Dazu wechseln wir nach /usr/src und geben ein:

cvs -d:pserver:anonymous@mysqlfs.cvs.sourceforge.net:/cvsroot/mysqlfs login

und dann:

cvs -z3 -d:pserver:anonymous@mysqlfs.cvs.sourceforge.net:/cvsroot/mysqlfs co -P mysqlfs

sowie:

./cvs-bootstrap
./configure

Falls es hier Fehler gibt, kann man mit autoreconf -i –force fehlende Teile automatisch erstellen lassen – spätestens jetzt sollte das configure ohne Probleme durchlaufen.

Jetzt musst allerdings noch das mysql-Schema gepatched werden – mit der Version vom CVS wird NDB-Cluster nicht unterstüzt:

diff -Nuar mysqlfs/schema.sql mysqlfs-mrjack/schema.sql
--- mysqlfs/schema.sql 2007-03-28 15:05:48.000000000 +0200
+++ mysqlfs-mrjack/schema.sql 2008-03-31 22:59:06.000000000 +0200
@@ -25,7 +25,7 @@
`seq` int unsigned not null,
`data` blob ,
PRIMARY KEY (`inode`, `seq`)
-) ENGINE=MyISAM DEFAULT CHARSET=binary;
+) ENGINE=NDBCLUSTER DEFAULT CHARSET=binary;

–
– Table structure for table `inodes`
@@ -45,7 +45,7 @@
`size` bigint(20) NOT NULL default ‘0′,
PRIMARY KEY (`inode`),
KEY `inode` (`inode`,`inuse`,`deleted`)
-) ENGINE=MyISAM DEFAULT CHARSET=binary;
+) ENGINE=NDBCLUSTER DEFAULT CHARSET=binary;

/*!50003 SET @OLD_SQL_MODE=@@SQL_MODE*/;
DELIMITER ;;
@@ -58,16 +58,16 @@
–
– Table structure for table `tree`
–
-
+SET FOREIGN_KEY_CHECKS = 0;
DROP TABLE IF EXISTS `tree`;
CREATE TABLE `tree` (
`inode` int(10) unsigned NOT NULL auto_increment,
- `parent` int(10) unsigned default NULL,
+ `parent` int(10) unsigned,
`name` varchar(255) NOT NULL,
- UNIQUE KEY `name` (`name`,`parent`),
+ PRIMARY KEY `name` (`name`, `inode`),
KEY `inode` (`inode`),
KEY `parent` (`parent`)
-) ENGINE=MyISAM DEFAULT CHARSET=utf8;
+) ENGINE=NDBCLUSTER DEFAULT CHARSET=utf8;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;

Nun kann man mysqlfs mit make compilieren.

Anschliessend muss man das Schema in die mysql-Datenbank importieren.

Dazu zuerst die Datenbank “mysqlfs” auf beiden Servern anlegen:

mysql> CREATE DATABASE mysqlfs;
mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON mysqlfs.* TO mysqlfs@"%" IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;

Sowie anschliessend das Schema importieren:

$ mysql -uroot -p mysqlfs < schema.sql

Dann einen Mountpoint anlegen, z.B. /mysqlfs mittels mkdir /mysqlfs

und das File-System mounten mit:

./mysqlfs -ohost=localhost -ouser=mysqlfs -opassword=password -odatabase=mysqlfs /mysqlfs


Man kann auch in der /etc/mysql/my.cnf einen Abschnitt [mysqlfs] erzeugen und diese Daten dort hinterlegen:

[mysqlfs]
host=localhost
user=mysqlfs
password=password
database=mysqlfs

Nun kann man das Filesystem einfach mit ./mysqlfs /mysqlfs mounten.

Ein “mount” gibt nun folgende Ausgabe:

mysqlfs on /mysqlfs type fuse (rw,nosuid,nodev)

Man muss mysqlfs natürlich auch auf dem zweiten, bzw. jedem weiteren Server installieren!

Wenn man nun Dateien in /mysqlfs erzeugt werden diese instantan auch bei dem zweiten Server verfügbar.

Ein Nachteil von mySQL-Fs ist jedoch, dass es relativ langsam ist, da durch mysql-ndb und fuse viel Overhead erzeugt wird. Es sei noch erwähnt, dass mysqlfs kein Locking unterstützt, weshalb man davon absehen sollte, Files mehrfach von unterschiedlichen Hosts gleichzeitig zu öffnen. Insbesondere Session-Daten etc. sind in einer mySQL-DB besser aufgehoben als ein mittels mysqlfs verteiltes /tmp/.

Es reicht allerdings aus, um z.B. PHP-Seiten zentral abzulegen und diese auf vielen verschiedenen Servern verfügbar zu machen, um z.B. ein Loadbalancing mittels DNS-Round-Robin zu realisieren.

mysqlfs ist Opensource und ist bei Sourceforge gehostet:
http://sourceforge.net/projects/mysqlfs/

Man kann jedoch das Module relativ einfach nachinstallieren:

mkdir /root/src
aptitude install apache2-prefork-dev libmysqlclient15-dev
cd /root/src/
mkdir auth_mysql
cd auth_mysql
wget http://download.nuxwin.com/apache2.2-modules/auth_mysql/mod_auth_mysql-3.0.0.tar.gz
wget http://download.nuxwin.com/apache2.2-modules/auth_mysql/patch/apache2.2.diff
tar xzf mod_auth_mysql-3.0.0.tar.gz
mv apache2.2.diff mod_auth_mysql-3.0.0/
cd mod_auth_mysql-3.0.0
patch -p0 < apache2.2.diff mod_auth_mysql.c
apxs2 -c -L/usr/lib/mysql -I/usr/include/mysql -lmysqlclient -lm -lz mod_auth_mysql.c
apxs2 -i mod_auth_mysql.la
echo “LoadModule mysql_auth_module /usr/lib/apache2/modules/mod_auth_mysql.so” > /etc/apache2/mods-available/auth_mysql.load
a2enmod auth_mysql
/etc/init.d/apache2 force-reload