Schlagwort: galera

Kurztipp: proxysql (1.3.4) mit Galera und proxysql_galera_checker.sh

kero Schreib einen Kommentar

Genauere Informationen zu ProxySQL mit Galera findet man hier. Dort ist auch erklärt wie man das Skript bei proxysql nutzen kann. Das Skript wird vorzugsweise vom ProxySQL Scheduler aufgerufen. Man kann es aber natürlich auch einfach mal auf der Commandline testen.
Meiner Meinung nach wird sich das eh im Laufe der nächsten Versionen nochmal grundlegend ändern. Das ist alles relativ umfangreich,  daher nur ein paar Hinweise.

Das Skript  liegt unter
/usr/share/proxysql/tools/proxysql_galera_checker.sh

Ein Aufruf sieht in etwa so aus

$ ./proxysql_galera_checker.sh 1 0 2 0 /var/lib/proxysql/galerachecker.log

 

Das erste Parameter gibt die Hostgroup für der Writer an, das zweite die Reader Hostgroup. Die 2  ist die Anzahl der genutzten Writers und die letzte 0 gibt an ob Writer auch als Reader agieren sollen wenn sie in der gleichen Hostgroup wie die Reader sind und als letztes Argument der Pfad zum Log.

Schaut man nun in das Logfile findet man folgendes:

Fr 3. Mär 13:22:10 CET 2017 ###### proxysql_galera_checker.sh SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 Hostgroup writers 1
Fr 3. Mär 13:22:10 CET 2017 Hostgroup readers 0
Fr 3. Mär 13:22:10 CET 2017 Number of writers 2
Fr 3. Mär 13:22:10 CET 2017 Writers are readers 0
Fr 3. Mär 13:22:10 CET 2017 log file /var/lib/proxysql/proxysql_galera_checker.log
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE WRITER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera3:3306 is already ONLINE: 1 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera4:3306 is already ONLINE: 2 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE READER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera1:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera1:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera2:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera2:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera3:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera4:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 ###### SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 --> Number of writers that are 'ONLINE': 2 : hostgroup: 1
Fr 3. Mär 13:22:10 CET 2017 --> Number of readers that are 'ONLINE': 2 : hostgroup: 0
Fr 3. Mär 13:22:10 CET 2017 ###### Loading mysql_servers config into runtime ######

Wir haben also 4 Nodes,  Galera3  und 4 aus Hostgroup 1 werden zu Writern und Galera1 und 2 aus Hostgroup 0 werden zu Readern. Galera3 und 4 sind auch in Hostgroup 1, dort werden sie aber Aufgrund des „writes should not be readers“ Arguments deaktiviert.

Wichtig dabei ist:

„…ProxySQL uses a chain of query rules to figure out the routing. If none of the rules apply to a query, query will be routed to the default hostgroup for the user, which created the connection.“

https://severalnines.com/blog/how-proxysql-adds-failover-and-query-control-your-mysql-replication-setup

Das ganze Konstrukt ergibt quasi nur Sinn wenn man auch mit query rules arbeitet.  So kann man aber „bequem“ read/write Anfragen skalieren und die volle Kapazität des Clusters nutzen.

So eine richtige Meinung zu ProxySQL habe ich noch nicht. Diese Sache mit den Hostgruppen finde ich jedenfalls ziemlich gut.  Ob  nun MaxScale oder ProxySQL die bessere Lösung ist kann ich nicht ohne weiteres sagen, sondern das hängt sicherlich von der jeweiligen Anforderung ab.  Für genauere Aussagen müsste man sich das mal in einer Produktivumgebung anschauen und sich ausführlicher mit den beiden Tools beschäftigen. Die Lizenz von ProxySQL ist natürlich deutlich sympathischer.

Link:
http://www.proxysql.com/compare

 

Bugfix Release für Galera

kero 2 Kommentare

Es gibt ein Galera Update. Primär ein Bugfix Release. Ein neues Feature klingt aber recht viel versprechend:

„Plus new experimental feature: weighted quorum (lp:1010225). Weight can be an integer in the range 0-255. Nodes with zero weight don’t participate in quorum calculation. By default all nodes have weight 1.“

http://www.codership.com/content/mysql-wsrep-5529-2373-and-galera-2324-released

Updaten lief ohne Probleme.

Nagios Plugin für glb max connections

kero Schreib einen Kommentar

Ein recht einfaches Nagios Plugin für glb den Loadbalancer für Galera. Getestet mit glb-0.9.0beta2. Das ganze ist schnell zusammengeschrieben, also nicht über Fehler wundern. Zum download gibt es das hier:

http://exdc.net/nagios/check_glbd_connections

Ausgabe:

$ /usr/lib/nagios/plugins/check_glbd_connections 100 450
Warning current connections:257 | 'connections'=257 'maxconnections'=493

$ /usr/lib/nagios/plugins/check_glbd_connections 100 250
Critical current connections:257 | 'connections'=257 'maxconnections'=493

$ /usr/lib/nagios/plugins/check_glbd_connections 100 250
OK current connections:1 | 'connections'=1 'maxconnections'=493

Das Skript:


#!/bin/bash
#########################################################################
# Script:       check_glbd_connections                                  #
# Author:       Thomas Linnemann (mail@exdc.net) http://exdc.net        #
# Purpose:      Monitor GLBS Connections status with Nagios             #
# Thanks to:    Bjoern Herbold, Alexey Yurchenko                        #
# History:      2012.12.18 version 0.0.1                                #
#                                                                       #
#########################################################################

print_usage() {
echo "Usage: check__glbd_connections warning critical  "
echo "e.g.  check_glbd_connections 350 450"
}

if [ $# -lt 2 ]; then
print_usage
exit 3
fi

conn_info=$(echo "getinfo" | nc -q 1 127.0.0.1 4041|grep Destinations)
conn=$(echo "$conn_info" | cut -d " " -f 5)
maxcon=$(echo "$conn_info" | cut -d " " -f 7)

if [[ $conn -ge $1 && $conn -lt $2 ]]
then
echo "Warning current connections:$conn | 'connections'=$conn 'maxconnections'=$maxcon"
exit 1

elif [ $conn -ge $2 ]
then
echo "Critical current connections:$conn | 'connections'=$conn 'maxconnections'=$maxcon"
exit 2
else
echo "OK current connections:$conn | 'connections'=$conn 'maxconnections'=$maxcon"
exit 0
fi

Performancedaten für Centreon werden auch geliefert (ja gelb ist eine tolle Farbe ich weiß)

galera-lb-1-glbd connections

Nagios Plugin für Galera wsrep_flow_control_paused

kero Schreib einen Kommentar

Ein sehr (sehr, sehr…) einfaches Plugin für den wsrep_flow_control_paused Wert bei Galera. Vielleicht hilft es irgendwem.

#!/bin/bash
if [ $# != 4 ]; then
        echo "Bitte IP,Port, MySQLuser und Passwort eines Galera Nodes angeben"
        exit 1
else
gstat1=$(mysql -h$1 -P$2 -u$3 -p$4 -e "show status like 'wsrep_flow_control_paused'"|grep wsrep_flow_control_paused|cut -f 2)
 if [ $gstat1 == "0.000000" ]
        then
                echo "OK flow_control_paused:$gstat1 | flow_control_paused=$gstat1"
                exit 0
        else
                echo "Achtung flow_control_paused:$gstat1 | flow_control_paused=$gstat1"
                exit 1
 fi
fi

Die wichtigen Werte findet man unter:
http://www.codership.com/wiki/doku.php?id=monitoring&s[]=monitoring

siehe auch:

http://exdc.net/2012/08/24/galera-cluster_size-nagios-check/
http://exdc.net/2012/09/14/galera-nagios-plugin/

Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 3 IP Failover

kero Schreib einen Kommentar

Nun haben wir unseren 4 Node Mysql Galera Cluster (hier sollte man besser eine ungerade Zahl wählen, wegen des Quorum Problems). Wir haben auch einen Loadbalancer auf 2 VMs laufen. Nun wollen wir aber noch einen IP Failover haben, falls eine der LB VMs ausfällt, sei es geplant oder ungeplant. Pacemaker ist meiner Meinung nach ein fantastisches Stück Software. Basis Funktionen, wie IP Failover bekommt man relativ unkompliziert ans Laufen, will man jedoch etwas mehr, wird schnell klar, wie komplex Pacemaker/Corosync ist, aber auch welche sinnvollen Funktionen zur Verfügung stehen. Ich beschränke mich auf das Nötigste, weil ich 1. noch nicht mehr weiß und 2. es für mein Projekt vollkommen ausreicht. Die Links am Ende sollte man sich auf jeden Fall anschauen, ich verspreche es lohnt sich. Ich spare mir in die Tiefe zu gehen, da die angefügten Links eigentlich alles erklären und dies deutlich besser tun, als ich es hier kurz zusammenfassen kann.
Fangen wir also mit den Zutaten an:

  • 3 IPs
  • 2 Server minimum (lb1, lb2)
  • Zeit

Nun gehen wir auf einen der Server, nehmen wir lb1:

aptitude install pacemaker

Danach passen wir /etc/corosync/corosync.conf  an:

interface {
 # The following values need to be set based on your environment
 ringnumber: 0
 bindnetaddr: 123.123.123.0
 mcastaddr: 226.94.1.1
 mcastport: 5405
}

Wobei bindnetaddr ein Netz angibt und keine Rechneradresse. Danach führen wir

corosync-keygen

aus. Das dauert etwas und kann durch etwas i/o beschleunigt werden. Danach

chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey
scp /etc/corosync/authkey lb2:/etc/corosync/authkey
/etc/init.d/corosync start

Sollte corosync seltsamerweise nicht starten, hat bei mir bei ein reboot geholfen. Wo der Fehler dabei lag, kann ich nicht sagen. Schauen wir uns erst mal den aktuellen Zustand an

crm_mon --one-shot -V

Dabei sollte nicht viel erscheinen.

Legen wir also unsere erste Ressource an:

crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="123.123.123.123" nic="eth0" op monitor interval="10s" meta is-managed="true"

Wobei 123.123.123.123 hier die Cluster IP ist.
Stonit und Quorum brauchen wir bei zwei Hosts eigentlich nicht, besonders wenn beide Maschinen auf gleicher Hardware virtualisiert sind ;-).

crm configure property stonith-enabled=false
crm configure property no-quorum-policy=ignore

Soll die IP automatisch wieder auf den aktiven Host zurückspringen oder beim aktuellen  bleiben?

crm_attribute --type rsc_defaults --attr-name resource-stickiness --attr-value 100

default-resource-stickiness=100 ist vergleichbar mit autofailback=false. Default ist der Wert auf 0 gesetzt, bedeutet die Ressource, bei uns FAILOVER-ADDR, springt automatisch wieder  auf den ursprünglichen Host zurück, sobald dieser verfügbar, bzw. Pacemaker gestartet ist.

Das Thema mit der Stickiness ist etwas komplexer, daher verweise ich auf diesen Link, wo der Punkt ausführlich erklärt wird. Der Punkt ist sehr wichtig, da man eventuell nicht immer will, dass die IP sofort wieder auf den Host zurückspringt der z. B. grad rebootet werden musste.

Verschiebt man die IP jedoch von Hand, setzt Pacemaker eine Location Regel für den jeweiligen Host

crm configure show
...
location cli-prefer-FAILOVER-ADDR FAILOVER-ADDR \
rule $id="cli-prefer-rule-FAILOVER-ADDR" inf: #uname eq lb1
...

Diese muss man dann von Hand wieder löschen. Ansonsten wird die Ressource wieder auf den node aus der Location Regel springen, wenn dieser verfügbar ist.
Ein

crm resource unmigrate FAILOVER-ADDR

Löscht die Location Regel.

Mit

crm configure show

können wir uns die  Konfiguration anzeigen lassen. Und mit

crm_mon --one-shot -V

sehen wir den aktuellen Zustand unseres Pacemaker Systems

crm_mon --one-shot -V
============
Last updated: Fri Nov  2 14:09:16 2012
Last change: Mon Sep 10 13:34:26 2012 via crm_attribute on lb1
Stack: openais
Current DC: lb1 - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ lb1 lb2 ]

Resource Group: Balancer
FAILOVER-ADDR    (ocf::heartbeat:IPaddr2):    Started lb1
GLBD    (lsb:glbd):    Started lb1

Nun testen wir mit

crm resource migrate FAILOVER-ADDR lb2

Ob sich unsere  Ressource verschieben lässt. Danach sollte in etwa folgendes erscheinen:

crm_mon --one-shot -V
============
Last updated: Fri Nov  2 14:15:16 2012
Last change: Fri Nov  2 14:15:12 2012 via crm_resource on lb1
Stack: openais
Current DC: lb1galera - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ lb1 lb2 ]

Resource Group: Balancer
FAILOVER-ADDR    (ocf::heartbeat:IPaddr2):    Started lb2
GLBD    (lsb:glbd):    Started lb2

Unsere FAILOVER-ADDR Ressource wurde also erfolgreich auf lb2 migriert. Mit dem Befehl

ip addr show

auf beiden Maschinen, können wir das nochmal unabhängig von Pacemaker überprüfen.
Dies GLBD, was erscheint, kann vorerst ignoriert werden. GLBD ist bei mir der MySQL Loadbalancer, der mit FAILOVER-ADDR zu der Gruppe „Balancer“ hinzugefügt wurde. Wie man den glbd Loadbalancer  mit in das Konstrukt aufnimmt, schreibe ich dann hoffentlich in Teil 4 (Pacemaker, Loadbalancer und Nagios) .

Pacemaker bitte eine ganze Reihe von praktischen Befehlen, Funktionen und Möglichkeiten zum anpassen der Konfiguration. Ich spare mir das mal alles und verweise auf die Links am Ende und auf google.

Link zu Teil 1:
http://exdc.net/2012/08/15/galera-cluster-mit-ubuntu-12-04-64bit-und-mysql-5-5-teil-2-loadbalancerproxy/

Links, die man sich auf jeden Fall anschauen will:
http://earlruby.org/corosync-pacemaker-notes/
http://blog.foaa.de/2010/10/intro-to-pacemaker-on-heartbeat/
http://blog.foaa.de/2010/10/intro-to-pacemaker-part-2-advanced-topics/
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/
http://wiki.techstories.de/display/IT/Pacemaker+HA-Cluster+Schulung+GFU+Koeln

update:

glbd kann sich auch an jedes beliebige Interface binden. Dazu reicht es einfach nur den listening Port anzugeben oder 0.0.0.0:port.

Linux Cluster Management Console

kero Schreib einen Kommentar

Für zwischendurch.

Linux Cluster Management Console is a GUI that helps to configure Pacemaker, DRBD and KVM clusters.

Damit ist eigentlich alles gesagt. Habe ich nicht zum Einrichten von Pacemaker genutzt, ist aber nett um sich das Ergebnis anzuschauen. Bei größeren Umgebungen, kann so ein Tool sicherlich sehr nützlich sein. Bei mir läuft auf den Nodes nur Pacemaker&co und glbd als MySQl Proxy. Bei der 1.3er Version war das Anlegen der Hosts nicht besonders intuitiv, vielleicht ist es bei der neuen 1.4er verbessert worden. DRBD ist natürlich nicht nötig, aber möglich.

httpvh://youtu.be/nEPn5RJA1Ig

p.s. damit teste ich auch gleich mal ob der osbn feed funktioniert

Galera cluster_size Nagios check

kero Ein Kommentar

Ein kleiner Nagios Check für MySQL / Galera.  Die Variable wsrep_cluster_status habe ich nur als zusätzliche Information mit rein genommen. Sobald mehr Zeit, erweitere ich das um die anderen wichtigen Variablen ( wsrep_ready, wsrep_connected, wsrep_flow_control_paused usw.)  und unterscheide ein paar mehr Fälle. Natürlich sind mit dem Skript kaum Fälle abgefangen, aber für so auf die schnelle funktioniert es. Nett wäre es, wenn die Galera Leute direkt ein Plugin zur Verfügung stellen würden, die kennen sich immerhin am besten damit aus.

#!/bin/bash
if [ $# != 1 ]; then
 echo "Bitte Anzahl der erwarteten MySQL Galera Nodes angeben"
 exit 1
else

 mysqlhost=127.0.0.1
 port=3306
 mysqluser=mysqluser
 password=mysqlpassword
 gstat1=$(mysql -h$mysqlhost -P$port -u$mysqluser -p$password -e "show status like 'wsrep_cluster_size'"|grep wsrep_cluster_size|cut -f 2)
 gstat2=$(mysql -h$mysqlhost -P$port -u$mysqluser -p$password -e "show status like 'wsrep_cluster_status'"|grep wsrep_cluster_status|cut -f 2)

  if [ $gstat2 == "Primary" ]
   then
    if [ "$gstat1" == "$1" ]
     then
     echo "OK wsrep_cluster_size:$gstat1 wsrep_cluster_status:$gstat2"
     exit 0
    else
     echo "Achtung wsrep_cluster_size:$gstat1 wsrep_cluster_status:$gstat2"
     exit 1
    fi
  else
   echo "Achtung wsrep_cluster_status:$gstat2"
   exit 2
  fi
fi

Link:
http://www.codership.com/wiki/doku.php?id=monitoring&s[]=monitoring

Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 2 Loadbalancer/Proxy

kero Ein Kommentar

Nun da Galera mittlerweile auf vier Nodes läuft, wäre ein Loadbalancer eine gute Sache. HAProxy fand ich etwas zu mächtig für mein Anliegen, obwohl er  von vielen Benutzern als Option präferiert wird . Getestet habe ich mysql-proxy direkt von Mysql und glbd von Galera. Beides scheint größtenteils problemlos zu laufen. Bei einfachen Benchmarks, konnte ich bisher keine gravierenden Unterschiede erkennen, dazu aber mehr in Teil 4. Mysql-proxy ist seit längerer Zeit im Alphastatus und glbd liegt in der Version 0.7.5 vor. Also beides ausbaufähig ;-). Mein Favorit ist glbd, weil er genau das tut, was er soll und nicht unnötig viele Einstellung benötigt oder bietet. Die Syntax ist recht einfach:

glbd --daemon --threads 8 --control 127.0.0.1:4041 123.123.123:4040 node1:3306:3 node2:3306:3 node3:3306:3 node4:3306:1

Ein –help zeigt alle Optionen:

glbd --help
Usage:
glbd [OPTIONS] LISTEN_ADDRESS [DESTINATION_LIST]
OPTIONS:
--help                  this help message.
--daemon                run as a daemon.
--fifo <fifo name>      name of the FIFO file for control.
--control [HOST:]PORT   listen for control requests on this address.
--threads N             number of working threads (connection pools).
--source_tracking       turn on source tracking: route connections from one
source to the same destination.
--verbose               turn on verbose reporting.
--version               print program version.
LISTEN_ADDRESS:
[IP:]PORT               where to listen for incoming TCP connections.
DESTINATION_LIST:
[H1[:P1[:W1]]] [H2[:P2[:W2]]]...  - a space-separated list of destinations
in the form address:port:weight.

Die Optionen nach Bedarf anpassen. Meiner Meinung nach empfiehlt es ich das weight eines nodes relativ niedrig anzusetzen. Dieser kann dann primär für Backups oder als Donor  fuer zusätzliche Nodes dienen, da er während des Syncs mit einem neuen Node im readonly mode ist. Statusabfragen von glbd macht man z.B. mit:

# echo "getinfo" | nc -q 1 127.0.0.1 4041
Router:
----------------------------------------------------
Address       :   weight   usage   conns
node1:3306  :    3.000   0.000     0
node2:3306  :    3.000   0.000     0
node3:3306  :    3.000   0.000     0
node4:3306  :    1.000   0.000     0
----------------------------------------------------
Destinations: 4, total connections: 0

Weiter Informationen finden sich im Readme.  Sehr gute Informationen und eine deutlich detaillierte Anleitung zu glbd findet man unter fromdual.com/mysql-and-galera-load-balancer. Dort ist auch ein Skript hinterlegt um glbd zu administrieren. Bricht ein Node weg, leitet glbd die Anfrage transparent an einen verfügbaren Node weiter. Leider ist die Dokumentation von glbd etwas dürftig, daher werden sich viele Verhaltensweisen erst im Laufe von diversen Tests zeigen. Probleme können eventuell auftauchen wenn man mit Pacemaker/Corosync arbeitet, da glbd sich (zu Recht) weigert,  an ein nicht existierendes Interface gebunden zu werden (Stichwort „crm colocation“), dazu mehr in Teil 3.

Mysql-Proxy ist als Paket bei Ubuntu 12.04 dabei, zwar „nur“ die 0.8.1, dafür  genießt man die Vorteile der Paketverwaltung. Konfiguriert wird mysql-proxy in der

/etc/default/mysql-proxy:

ENABLED="true"
OPTIONS="--proxy-skip-profiling --proxy-address=123.123.123.123:4040 --proxy-backend-addresses=node1:3306 --proxy-backend-addresses=node2:3306 --proxy-backend-addresses=node3:3306 --proxy-backend-addresses=node4:3306 --admin-username=superadmin --admin-password=imnotshyijustdontlikeu --admin-lua-script=/usr/lib/mysql-proxy/lua/admin.lua"

Damit läuft  erst mal die Proxyfunktion. Mysql-proxy kann deutlich mehr als nur  Proxy sein. So kann er zum Beispiel die Mysqlanfragen nach read-write selektieren und mit der --proxy-read-only-backend-addresses Option auf dedizierte Readonly „Slaves“ leiten. Die Dokumentation ist sehr gut, dank auch der  MySQL Integration. MySQL Anfragen können mit Hilfe von Lua Skripten direkt manipuliert  werden. Zum lesen nochmal zwei Links zu mysql-proxy, hier und hier. Der Beitrag von mysqlperformanceblog.com  ist von Juni 2009, daher wurde noch die 0.7.1 getestet. Zu eigenen Benchmarks komme ich in Teil 4.

Ob nun glbd, mysql-proxy, pen oder haproxy, hängt vom Einsatzzweck und System ab. Sicherlich gibt es noch etliche andere Lösungen für ein Mysql Proxy/Loadbalancer Szenarien. Schaut man sich kommerzielle Anbieter an, wird man sicherlich hinter all den Webinterfaces, Firmenlogos und Gedöhns, häufig ein Programm aus der Open Source Welt finden, was dort still und unscheinbar seinen Dienst verrichtet. Teil 3 handelt von Pacemaker und IP Failover und Teil 4 schließlich von Benchmaks zu unterschiedlichen Konfigurationen. Ein wesentlicher Faktor beim Einrichten einer solchen Umgebungen ist natürlich die Zeit, die man dafür zur Verfügung hat. Sollte ich komplett auf dem Holzweg sein, sind Kommentare natürlich willkommen, ansonsten natürlich auch.

Link zu Teil 1:

http://exdc.net/2012/08/06/galera-cluster-mit-ubuntu-12-04-64bit-und-mysql-5-5-teil-1/