Home > Codes/Configs, Linux/Unix, Opensource > Kurz notiert: MariaDB, Galeracluster auf Ubuntu 14.04 LTS

Kurz notiert: MariaDB, Galeracluster auf Ubuntu 14.04 LTS

galera_replication1Beginnen wir mit dem Setup welches wir brauchen. Fuer einen Galera Cluster benoetigen wir mind. 2 Maschinen, wenn man jedoch Split Brain Conditions vermeiden/verhindern Enden moechte, muessen es 3 Nodes sein, 2 laufen aber durchaus.
Meine 3 Nodes haben die IP Adressen: 10.13.37.2, 10.13.37.3, 10.13.37.4 und auf diesen Kisten installieren wir nun die notwendigen Pakete, da Ubuntu die passenden Repos nicht mitbringt, koennen wir uns hier dem Repo Konfigurator MariaDB von MariaDB bedienen oder einfach den Schnipseln folgen.
Bitte darauf achten, dass MariaDB 5.5 installiert wird, die 10er Trees haben noch das ein oder andere Problemchen gemacht, daher gehe ich auf die stable Varianten ein. Neben Mariadb brauchen wir noch RSync und Galera als solches, also fuehren wir auf allen Nodes folgendes aus:

apt-get install python-software-properties software-properties-common
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
add-apt-repository 'deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/5.5/ubuntu trusty main'
apt-get update
apt-get install -y rsync galera-3 mariadb-galera-server
service mysql stop

Nachdem die Pakete installiert sind, wird MariaDB als gleich gestoppt und wir widmen uns der Config fuer den Cluster, fuer die lazyppl einfach copy/paste


(
cat <<'EOF'
[mysqld]
#mysql settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
#galera settings
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="my_wsrep_cluster"
wsrep_cluster_address="gcomm://10.13.37.2,10.13.37.3,10.13.37.4"
wsrep_sst_method=rsync
#wsrep_debug=ON
#wsrep_log_conflicts=ON
#wsrep_provider_options="cert.log_conflicts=ON"
EOF
) > /etc/mysql/conf.d/galera.cnf

Bitte beachtet, das die bind-address Settings eher suboptimal sind. In den meisten Setups sollte man darueber nachdenken MariaDB auf ein internes Interface zu binden. Wenn eine Verbindung nach Aussen notwendig ist, weil standortverteilte Nodes auf sichere Passwoerter achten!

Wenn die Config auf allen Nodes verteilt wurde, beginnen wir damit die erste Node zu starten.
Hierfuer brauchen wir fuer den ersten Start einen extra Parameter, dieser sorgt fuer das Initialisieren des Clusters:

root@galera1:~# service mysql start --wsrep-new-cluster
root@galera0:~# mysql -uroot -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'
+--------------+
| cluster size |
+--------------+
| 1 |
+--------------+

Direkt angehaengt findet Ihr eine MySQL Query und seine Ausgabe, sollte hier keine 1 stehen, ist irgendetwas schief gelaufen (kann nicht sein ;)!)
In dem Fall sollte man die kommentierten debugging Optionen auskommentiert werden und der Service neu gestartet werden.
Davon ausgehend, dass es keine Probleme gibt widmen wir uns nun der 2. Instanz:

root@galera2:~# service mysql start
[ ok ] Starting MariaDB database server: mysqld . . . . . . . . . ..
[info] Checking for corrupt, not cleanly closed and upgrade needing tables..
root@galera2:~# ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

Die Fehlermeldung braucht uns vorerst nicht stoeren, das wird im Nachgang gefixed, unser MySQL Query sollte nun wie folgt aussehen:

root@galera2:~# mysql -uroot -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'
+--------------+
| cluster size |
+--------------+
| 2 |
+--------------+

Wenn das passt haengen wir noch Node3 in den Cluster:

root@galera3:~# service mysql start
[ ok ] Starting MariaDB database server: mysqld . . . . . . . . . ..
[info] Checking for corrupt, not cleanly closed and upgrade needing tables..
root@galera3:~# ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)
root@galera3:~# mysql -uroot -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'
+--------------+
| cluster size |
+--------------+
| 3 |
+--------------+

Nun muessen wir noch das DebianMaintainer Problem beheben, dafuer einfach von node01 die /etc/mysql/debian.cnf auf die anderen Nodes deployen und der Fehler verschwindet und die Systeme sind in einem konsistenten Zustand.

Revision 2: Fixing der galera.cnf, danke an Nico fuers aufpassen!

Ähnliche Posts

  1. 4. Februar 2016, 15:05 | #1

    Hey hey, lange ziemlich ruhig hier gewesen. :-)

    Was hast du mit dem Cluster vor? Der Cluster bringt in der Variante nur „Ausfallsicherheit“ oder – keine „Performancesteigerung“, durch verteiltes schreiben?
    Clustering wird bei uns nämlich auch immer interessanter, aber nicht im Hinblick auf „Ausfallsicherheit“. :-p

    Gruß Nico

    PS: Die „wsrep_cluster_address“ in der „galera.cnf“ wäre falsch oder?

  2. 4. Februar 2016, 15:53 | #2

    Moin Nico,

    ja leider habe ich nicht mehr die Zeit und Themen die ich hier veroeffentlichen kann, daher etwas ruhiger.
    Der Cluster in der Version wie er hier dargestellt wird, ist fuer Ausfallsicherheit gedacht, das siehst Du so ganz richtig.
    Wenn man performanter arbeiten moechte, wuerde ich ohnehin weniger auf MariaDB setzen, und meinen Blick eher gen PostgreSQL richten oder wenn moeglich Richtung NoSQL, muss ja nicht immer Relational sein :).
    An der Stelle noch der Hinweis, eine Single Instance ist in den meisten Faellen dem Galera Cluster ueberlegen wenn es um Performance geht.

    Danke fuer den Hinweis mit der wsrep_cluster_address, im ersten Versuch hat WordPress mir das Pasting zerlegt und dann habe ich wohl geschlampt beim 2. pasten und direkt die IPs aus der Staging Umgebung kopiert, drum auch auf einmal nur noch 2 Nodes.

    Regards
    Milan

  1. Bisher keine Trackbacks