Blog von Alexander Windbichler Aristochaot

Sequoia / Continuent Erfahrungen

Da ich mich in letzter Zeit sehr intensiv mit dem Thema MySQL Clustering mit Continuent bzw. Sequoia beschäftigt habe, werde ich hier mal eine Zusammenfassung meiner Arbeit und Tests bereitstellen, da es sonst im Web nahezu keine Erfahrungsberichte oder ähnliches gibt.

Was ist Sequoia / Continuent

Continuent bietet ein skalierbares Cluster für Datenbankserver, egal welcher Art. Einzige Vorgabe ist, dass ein JDBC Treiber vorhanden sein muss. Diesen findet man bei fast allen Datenbankservern, wie MySQL, MSSQL,...

Auf der Webseite wird dieses Cluster als Allheilmittel verkauft, das sowohl alle Skalierungsprobleme, als auch Hochverfügbarkeits-Probleme löst.

Was ist der Unterschied zwischen Continuent und Sequoia

Der einzige Unterschied ist, dass Continuent ein umfangreiches Supportpaket dabei hat, was Sequoia nicht hat, da es Opensource ist. Die Supportpakete sind so viel ich gesehen und gehört habe sehr teuer.

Allgemeines zu Sequoia

Das Cluster soll dazu dienen sowohl Schreibzugriffe, als auch Lesezugriffe auf mehrere Server aufzuteilen. Lesezugriffe sind ja gar nicht das Problem, das Problem - und das weiss jeder Admin der sich damit befasst hat - sind die Schreibzugriffe. Man greift auf das Sequoia Cluster zu und schreibt seine Queries (z.B. INSERT INTO table (testrow1, testrow2) VALUES ('test1', 'test2' ) ). Sequoia teilt diese so auf, dass diese a) auf jedem Node vorhanden sind und b) so geschrieben werden, dass man nicht in die Quere mit irgendwelchen AUTO-INCREMENT Werte kommt.

Soweit klingt das super und natürlich für jeden Administrator interessant.

Wie ist der Ablauf?

a) Man stellt den Query an den Controller - an eine virtuelle Datenbank.

b) Der Controller leitet diesen Request an das jeweilige Node weiter.

c) Ist ein Node nicht erreichbar, wird der Request nicht weitergeleitet.

d) Man bekommt ein Ergebnis zurückgeliefert und der Query ist abgeschlossen.

Die Datenbankserver im Hintergrund

Mit Sequoia kann man seitens der Backendinfrastruktur sämtliche Perversitäten und Vorlieben ausleben. Man kann als ersten Datenbankserver einen MySQL hinstellen, als zweiten einen PostgreSQL und als dritten einen Oracle Server. Das funktioniert wunderbar. Ob es Sinn macht sei dahingestellt, aber es geht.

Erstellen von Datenbanken

Beim Controller vom Sequoia muss eine virtuelle Datenbank zum Beispiel die myDB angelegt werden. Auf jedem weiteren Datenbanknode (Datenbankserver 1, 2 und 3) muss auch eine Datenbank angelegt werden. Da reicht einfaches CREATE DATABASE und man hat die gewünschte Datenbank.

Starten des Controllers und man kann normal auf seine virtuelle Datenbank zugreifen.

Also mit:

USER myDB;

SELECT * FROM table;

Ganz simple.

Schreiben von Datenbankeinträgen (INSERTs, UPDATEs)

Nun kommt das Enttäuschende. Wird nun ein INSERT getätigt, so wird dieser INSERT an jeden einzelnen Backend Server geleitet. Fällt euch was auf? Genau - wenn ich viele Schreibzugriffe habe, dann ist mein Cluster so stark wie das schwächste Glied und auch wenn das schwächste Glied ein Dual Quad Core Xeon mit 16GB Ram oder noch viel besser ist, bin ich irgendwann am Ende. Sprich es gibt keine Endlosskalierung der Schreibzugriffe.

Verwendung von InnoDB, MyISAM,...

Nachdem mein ganzes Cluster eigentlich nur aus einem intelligenten Skript besteht, welches die SQL Queries wie ein Proxy weiterleitet, kann ich im Hintergrund InnoDB, MyISAM, oder egal was sonst noch verwenden. Ich kann die Engines sogar mischen. Es ist nur ein Proxy.

Zugriff auf die virtuelle Datenbank

Lange Zeit hatte ich die Befürchtung, dass ich meine Applikationen auf einen JDBC Treiber umbauen muss, was natürlich für Hosting oder herkömmliche Applikationen total uninteressant wäre. Mit Myosotis bringt die Community einen Connector, der vor den Controller geschaltet wird, dass man herkömmlich über seinen Port 3306 zugreifen kann.

Anlegen von virtuellen Datenbanken

Das Gesamte System besteht aus virtuellen Datenbanken. Ein CREATE DATABASE ist nicht vorhanden. Um eine Datenbank anzulegen muss man die Konfiguriationsdatei vom Controller editieren und dort die Datenbank eintrage und den Controller neu starten.

Praxitext mit diversen Skripten

phpMyAdmin: Loggt man sich mit phpMyAdmin ein, so erscheint nicht die virtuelle Datenbank, sondern die Backend Datenbank. Von der virtuellen Datenbank keine Spur. Will man auf die anderen Datenbanken zugreifen, die am Backend Server liegen, erhält man keinen Zugriff. Ein SHOW PROCESSLIST bringt nur die Last der einzelnen Backend Server, es gibt keine wirklichen Analysefunktionen direkt über die SQL Befehle und ein SHOW DATABASES zeigt keine virtuelle Datenbank.

phpBB3: Dieses Board bringt ein umfangreiches Installationsskript und vor allem viele Datenbanktests mit. Es ist recht komplex aufgebaut, hin und wieder auch etwas langsam, eignet sich aber als nettes Testskript. Eine Installation verlief nicht wirklich erfolgreich, da offenbar Queries fehlgeschlagen sind, die aber auf den normalen Datenbankservern sehrwohl funktioniert haben. Weiters ist mir aufgefallen, dass trotz abgeschalteten Loggings das System sehr langsam war. Als phpMyAdmin die SQL Daten eingespielt hat, dauerte dies ca. 30 Sekunden! Man muss bedenken, dass Controller, MySQL Connector und beide Datenbanken auf ein und dem selben System lagen. Der Server lief auf volle 100% (P4 mit 2,4 GHz, 1 GB RAM). Freilich der Server ist kein starkes Ding, dennoch hätte es aber schneller gehen müssen.

Wordpress: Die Wordpress Installation ist sehr simple (datenbanktechnisch gesehen) und war auch erfolgreich, auch wenn Sequoia ein paar Fehler auswarf, offenbar funktionierte aber alles.

Fazit

Im Allgemeinen war meine Euphorie sehr schnell vorbei. Das System ist langsam, fehleranfällig und bringt weniger Vorteile als ein MySQL Proxy (der mir wenigstens die Readonly-Slaves bei einem Schreibzugriff nicht belastet bzw. nicht so stark, denn die Replikation arbeitet ein wenig anders). Ich habe sehr schnell aufgehört zu testen, nachdem sich das System sehr schnell aus unbrauchbar herausgestellt hat.

Interessant ist das System sicherlich für die ein oder andere Hochverfügbarkeitsanwendung oder bietet sich vielleicht als etwas schwächere Variante für einen MySQL Proxy an, wenn man viele Lesezugriffe hat.

Ich muss sagen, dass ich die Entwicklung weiter verfolgen werde, aber aktuell ist die Software noch lange nicht so weit, um es beispielsweise mit einem Orcale Cluster aufzunehmen.