News:
ASPICON Lab :: MySQL InnoDB Cluster

Sehen wir den MySQL InnoDB Cluster als horizontale Möglichkeit des Aufbaus einer HA-Umgebung, definieren wir den Failover-Cluster als vertikalen Aufbau.

Icon Unternehmen

Einleitung


Mit dem Relase 5.7.17 hat das Plugin "Group Replication" den GA-Status erreicht. Oracle veröffentlicht hiermit für MySQL das native Feature zum Aufbau eines Replikations-Clusters, was man zuvor nur durch die Mithilfe von Coderships "Galera" oder der Implementierung selbigem im Fork des MySQL-Servers von Percona kannte. Alle Produkte nutzen das Feature der Storage-Engine "InnoDB", und der Binary-Logfiles, mittels DDL- und DML-Statements, Datenbanken zu replizieren und somit synchron zu halten.

Mit dem kurz darauf folgendem Release 5.7.18 hat der "MySQL InnoDB Cluster" ebenfalls den GA-Status erreicht. Viele sehen in den beiden Bezeichnungen auch zwei unterschiedliche Produkte, jedoch gilt folgende Begriffserläuterung:

  • "Group Replication" ist ein Plugin für den Aufbau einer Replikation im Master-Slave-, alternativ Multi-Master-Verbund
  • als "MySQL InnoDB Cluster" wird das Zusammenspiel zwischen dem Plugin "Group Replication", der MySQL-Shell und des MySQL Routers bezeichnet


Kurzum: Die Group Replication bildet die Grundlage für einen High-Availabilty-Aufbau, welcher mit MySQL-Shell und MySQL-Router vervollständigt wird.

"Failover" wird in der Dokumentation von MySQL selten, bis gar nicht behandelt, jedoch gibt es offizielle Publikationen, welche den Aufbau eines Cluster, basierend auf einer Instanz, welche per Shared-Storage erreichbar und, mittels Schwenk, auf mehreren Servern betrieben werden kann.


Idee

MySQL InnoDB Cluster Failover
 

Sehen wir den MySQL InnoDB Cluster als horizontale Möglichkeit des Aufbaus einer HA-Umgebung, definieren wir den Failover-Cluster als vertikalen Aufbau. Die Idee dieses Labs ist die Kombination beider Möglichkeiten: der MySQL InnoDB-Cluster bildet die Grundlage, der Failover das "Backup" der Hochverfügbarkeit einer bzw. mehrerer Nodes im Desaster- bzw. Wartungsfall.

Da Applikationen und Anwender die Datenbank als ein Ganzes sehen und sich keine Gedanken über Verbindungsparameter und ~routen machen sollten, kommt ein Router für selbiges on top. Hierbei durchbrechen wir - im vorliegenden Laboraufbau - die Definition des MySQL InnoDB Clusters und ersetzen den MySQL Router durch das Open Source Produkt "ProxySQL". Trotzdem werden wir im weiteren Verlauf des Artikel dem Begriff "MySQL InnoDB Cluster" treu bleiben.

"Warum das ganze?" - Gegenfrage: "Warum nicht?". Datenbanken bzw. Services im Allgemeinen hochverfügbar zu machen, steht im Mittelpunkt einer jeden aktuellen Infrastruktur. Ein Cluster allein bildet schon die Grundlage für Hochverfügbarkeit und Lastverteilung. "Stapelt" man nun eine weitere Möglichkeit oben auf, erhöht sich der Grad der Verfügbarkeit, vielleicht nicht in der täglichen Nutzung der Datenbank bzw. des Services, jedoch aber im Desaster- bzw. Wartungsfall.
Ein Beispiel wäre das Upgrade des Betriebssystems: Man schwenkt kontrolliert ("Switchover") eine Datenbankinstanz auf den Failover-Host. Der Cluster agiert ohne Unterbrechung vorerst mit den zwei verbliebenen Nodes weiter. Ist der Switchover vollzogen, joined die Instanz wieder dem Cluster. Das Betriebssystem des nun freien Hosts kann mühelos geupdatet, der Host neugestartet und im Anschluss der Urzustand durch einen weiteren Switchover wiederhergestellt werden.


Setup
 

  • 3 Datenbanknodes  (im Verbund der "MySQL InnoDB Cluster")
  • 1 Failover-Node (kann die Funktion jeder einzelnen Datenbanknode übernehmen; im äußersten Notfall kann die Nodes ALLE Datenbankserver beherbergen)
  • 2 Proxynodes (ein Failoververbund für den Dienst des/ der MySQL-Proxies)
     

Für die Datenreplikation kommt DRBD (Distributed Replicated Block Device) zum Einsatz. Alle relevanten Daten (Datenfiles, InnoDB-Logfiles und Binary-Logfiles) werden zwischen den Datenbankservern repliziert.

Die Clusterware bilden, ebenfalls aus dem Open Source Umfeld, Pacemaker und Corosync.

Als Betriebssystem kommt Oracle Enterprise Linux in der aktuellen Version 7.3, mit dem U(nbreakable) E(nterprise) K(ernel) 4, zum Einsatz.

Softwarekomponenten

  • Oracle Linux: 7.3, UEK4   (4.1.12-94.2.1.el7uek.x86_64)
  • MySQL: 7.1.18
  • MySQL-Shell: 1.0.9 (mysql-shell-1.0.9-1.el7.x86_64)
  • ProxySQL: 1.4.0 (proxysql-1.4.0-1-centos7.x86_64.rpm)
  • DRBD: 8.4  (drbd84-utils-8.9.8-1.el7.elrepo.x86_64, kmod-drbd84-8.4.9-1.el7.elrepo.x86_64)
  • Corosync: 2.4 (corosync-2.4.0-4.el7.x86_64, corosynclib-2.4.0-4.el7.x86_64)
  • Pacemaker: 1.1.15 (pacemaker-libs-1.1.15-11.el7.x86_64, pacemaker-cli-1.1.15-11.el7.x86_64, pacemaker-cluster-libs-1.1.15-11.el7.x86_64, pacemaker-1.1.15-11.el7.x86_64)
     

Aufbau


Betriebssystem

Ob die Installation der MySQL-Datenbanksoftware per Paketmaneger aus dem offiziellen Repository, oder, wie vom Autor präferiert, per MySQL "MOCA"), die Auswahl und die richtige Installation bzw. Konfiguration des Betriebssystems steht am Anfang einer gute geplanten HA-Infrastruktur.

Folgende Punkte sollten auf der Bullet-List einer jeden Installationsroutine vermerkt und beachtet werden:

  1. Einsatz einer individuellen Partitionierung inklusive des Einsatzes von LVM
  2. minimale Installation von Softwarepaketen
  3. Anpassung von Kernelparameter
  4. Anpassung von Sicherheitskomponenten
  5. Anpassung der Netzwerkkonfiguration
  6. Synchronität der Systemzeiten

    
1. Partitionierung und LV

Die Installationsroutine einer jeden Distribution bietet eine automatisierte, bzw. vorgegebene, Partitionierung der vorhandenen Festplatten. Für den einfachen Anwender scheint dies die komfortabelste Lösung zu sein, jedoch sollte man sich für eine professionelle Installation die Zeit nehmen, sich der Aufteilung der Partitionen detailierte zu widmen. Generell sollten die Systempartitionen zu Beginn ein, aus Erfahrungen definierter, minimaler Platz zur Verfügung gestellt werden, mit der Option auf eine Vergrößerung zur Laufzeit.

Den Komponenten der Datenbank sollten hingegen separate Festplatten/ LUNs zur Verfügung gestellt werden. Hierbei sollte man die Aspekte Hochverfügbarket (RAID) und Performance (SSD) genauer betrachen. Zusätzlich ist ein Teil des Arbeitspeichers, bzw. eine RamDisk, für temporäre Tabellen zu reservieren (https://www.aspicon.de/unternehmen/news/meldung/dba-tipp-mysql-performanceboost-dank-tmpfs).
    
2. Softwarepakete

TL;DR
Nur genau die Softwarepakete installieren, die man für den Betrieb des Systems und der Datenbank benötigt.
    
3. Anpassung von Kernelparametern

Jede, sei es doch so kleine, Anpassung der Kernelparameter (/etc/sysctl.conf) kann ausschlaggebend für die Performance und Verfügbarkeit des gesamten System sein. Einen Anfang macht hier das aktuelle Paket "oracle-rdbms-server-12cR1-preinstall" aus dem Public-Repository von Oracle. Neben diverser andere Konfigurationen werden hier auch grundlegene Anpassung des Kernels getätigt.
    
4. Anpassung von Sicherheitskomponenten

Sowohl die Limit-Einstellungen für den Daemon-Nutzers der MySQL-Software, als auch Portfreigaben in der Firewall der Distribution sollten genau betrachtet und konfiguriert werden. Die Sicherheitskomponenten per se zu deaktivieren, ist, in einer gewissen Hinsicht, nicht immer die bessere Alternative.
    
5. Anpassung Netzwerkkonfiguration

Ob DNS, DHCP oder statischen Zuteilungen von IP-Adressen und Hostname, diese Konfigurationen müssen stimmen! Ist dies nicht der Fall, kann es in einer Fehlersituation zu langen Ausfällen und einer ausgedehnten Fehlersuche kommen.
    
6. Synchronität der Systemzeiten

Stellen Sie sicher, dass jeder Ihrer Datenbankknoten - und Ihre Infrastruktur generell - eine synchrone Systemzeit besitzt.
    

Failover

Grundprinzip
Die Basis für einen Failover-Cluster bilden mindestens zwei Knoten. Der spezifische Dienst wird betrieben, indem er entweder auf node1 oder node2 (alternativ nodeX) gestartet ist. Für die transparente Konnektivität ist eine virtuelle IP-Adresse an den Dienst bzw. die aktive Node gebunden, welche im Failover-Fall zusammen mit dem Service auf den/ einen der verbliebenen Host(s) überführt wird.

Genau so verhält es sich mit dem Datenspeicher. Dieser ist bei allen Hosts vorhanden und wird über einen Interconnect synchron gehalten. Lediglich am aktiven Host ist die Festplatte/ sind die Festplatten hierbei gemountet.

Die Verwaltung der Abhängigkeiten von Dienst, Datenspeicher und VIP übernimmt die Clusterware, welche im Fehler- oder Wartungsfall den Service auf dem, noch aktiven, Host stoppt, die Festplatte(n) unmountet und die VIP auf dem neuen Host überführt. Der synchronisierte Datenspeicher wird auf dem Zielhost gemountet und der Dienst zum Abschluss gestartet.
    
ProxySQL

Der redundant ausgelegte Proxy dient als Kommunikationsmedium zwischen dem MySQL InnoDB Failover Cluster und dem User/ der Anwendung. Mit einem konfiguriertem Read-Write-Split kann die Primärinstanz entlastet werden, indem SELECT-Statement auf den synrchonen/ die synchronen Slaves ausgelagert werden. Somit kann eine leseintensive Software, zum Beispiel für ein Reporting, direkt auf den Slave ausgerichtet werden.

c-two-proxysql-failover-n01 <-> proxysql-datadir <-> c-two-proxysql-failover-n02

MySQL InnoDB Cluster Clusterware ProxySQL Pacemaker CRM Status

Die Datenbankserver "schieben" wir in der ProxySQL-Konfiguration in spezifische Hostgroups: 
1 = offline
2 = writer
3 = reader
4 = backup writer

Ab der Version 1.4.0 bringt ProxySQL eine native Unterstützung für die Group Replication mit und handelt die Zugehörigkeit von Datenbankhost zu Hostgroup voll automatisiert aus.

Beispiele:
MySQL InnoDB Clulster ProxySQL Cluster ProxySQL Admin Servers in Hostsgroups 01MySQL InnoDB Clulster ProxySQL Cluster ProxySQL Admin Servers in Hostsgroups 02

MySQL

Die, zu Beginn der Installation autark agierenden, Datenbanken werden so installiert, dass Datenfiles, InnoDB-Logs und Binary-Logfiles getrennt von einander, auf unterschiedlichen Festplatten liegen, welche per DRBD zwischen den Datenbank- und dem Failover-Hosts synchronisiert werden.

c-two-mysql-grprpl-n01 <->  node01-datafiles  <-> c-two-mysql-failover-n03 
c-two-mysql-grprpl-n01 <->  node01-iblogs     <-> c-two-mysql-failover-n03  
c-two-mysql-grprpl-n01 <->  node01-binlogs    <-> c-two-mysql-failover-n03

c-two-mysql-grprpl-n02 <->  node02-datafiles  <-> c-two-mysql-failover-n03
c-two-mysql-grprpl-n02 <->  node02-iblogs     <-> c-two-mysql-failover-n03
c-two-mysql-grprpl-n02 <->  node02-binlogs    <-> c-two-mysql-failover-n03
        
c-two-mysql-grprpl-n03 <->  node03-datafiles  <-> c-two-mysql-failover-n03
c-two-mysql-grprpl-n03 <->  node03-iblogs     <-> c-two-mysql-failover-n03
c-two-mysql-grprpl-n03 <->  node03-binlogs    <-> c-two-mysql-failover-n03

Eingebunden in den Pacemaker-Cluster zeigt sich am Ende der Installation folgendes Bild:
MySQL InnoDB Cluster Clusterware MySQL Pacemaker CRM Status

Sicherlich können alle relevanten Files auch auf einer separaten Disk liegen, jedoch ist, aus Performance- und Verfügbarkeitsgründen dazu zu raten, eine MOCA-Installation durchzuführen.

MySQL InnoDB Cluster

Wie bereits erwähnt, wird die Definition des InnoDB Clusters leicht abgeändert und der MySQL-Router durch ProxySQL ersetzt. Der Grundfunktionalität tut das jedoch keinem Abbruch. Auch wird ein Schritt extra gegangen und zuerst eine Group Replication eingerichtet und anschließend diese per MySQL-Shell als InnoDB CLuster importiert. Der Grund ist im Abschnitt "Lessons Learned - 2. Es ist halt erst ein GA-Release..." genauer beleuchtet.

Die Konfigurationsparameter für die Group Replication sind hierbei folgende:

loose-group-replication-start-on-boot                           = ON
loose-group-replication-group-name                              = '550fa9ee-a1f8-4b6d-9bfe-c03c12cd1c72'
loose-group-replication-local-address                           = 'mysql-node57-01:6601'
loose-group-replication-group-seeds                             = 'mysql-node57-01:6601,mysql-node57-02:6602,mysql-node57-03:6603'
loose-group-replication-compression-threshold                   = 10000
loose-group-replication-poll-spin-loops                         = 1024

Dabei ist zu beachten, dass den Hostnames "mysql-node57-0[1-3]" die VIPs hinterlegt sind, welche im Failoverfall schwenken und die Datenbanken somit hochverfügbar machen. Wichtig ist hierbei, dass die Definition von "Host:Port" nicht den Zugriff auf die Datenbanken von User/ Appplikation beschreibt, sondern die Verbindung zur Kommunikation der Replikation (kurz: "Interconnect").

Der Parameter `bind_address` darf hierbei nicht bzw. wenn, muss er zwingend auf "alles", also "0.0.0.0", gesetzt sein, damit dies auch nach einem Failover funktioniert. Dadurch muss auch auf unterschiedliche Ports - auch für den Datenbankzugriff (default: 3306) - geachtet werden.

Sofern die Konfiguration (hier ein Auszug der minimalen Voraussetzungen) der Binlogs korrekt ist

binlog-format                   = ROW
binlog-checksum                 = NONE

steht der Group Replication nichts im Wege.

Ist die Group Replication erfolgreich konfiguriert, und per MySQL-Shell importiert, findet man folgendes finales Setup vor:

MySQL InnoDB Cluster MySQL Shell Cluster Status 01

Nach dem Schwenk einer Datenbankinstanz zeigt sich folgender Cluster-Status:

MySQL InnoDB Cluster MySQL Shell Cluster Status 02

Wie in den Screenshots erkennbar, setzen wir, wie per Default konfiguriert, auf eine Master-Slave-Replikation.
Die Group Replication bzw. der MySQL InnoDB Cluster beinhaltet auch die Möglichkeit einer Multi-Master-Replikation, jedoch ist von dieser abzuraten, sofern die Applikation, welche den Cluster nutzen soll, mit jeglicher EInschränkung leben kann.


Lessons Learned
 

1.) Wer schwenkt wohin... und warum sollte er das nicht?!

Per Definition sind bei einem Pacemaker-Cluster alle einbezogene Hosts, im Falle eines Failovers, potentielle Ziele. Da der Laboraufbau die Datenbanknodes nur jeweils zum Failover-Host, und nicht untereinander, schwenken sollen, gilt es Außnahmen zu definieren. Diese können per "location"-Restriktionen erreicht werden. Beziehungen zwischen den Datenbankservern untereinander werden als eine Art "Ignoranz" konfiguriert; die Beziehungen der einzelnen MySQL-Nodes zum Failover-Server werden präferiert.

2.) Es ist halt erst ein GA-Release...

Der MySQL InnoDB Cluster, sprich die Group Replication, kann sehr einfach mittels der MySQL-Shell eingerichtet werden. Viele Stunden der Fehlersuche und des Troubleshootings zeigten, dass der Detailgrad der Konfigurationsmöglichkeiten jedoch (vielleicht noch) zu gering ist, als das hiermit der Aufbau "out of the box" funktioniert hätte. 


Zum Schluss


Im hier gezeigtem Aufbau wurde jeglicher Traffic über nur ein Netzwerkinterface geleitet. In einer produktiven Umgebung ist es ratsam, diesen über mehrere Schnittstellen laufen zu lassen:

  • 1 Interface für die Kommunikation Proxy -> MySQL (`mysql-vip`)
  • 1 Interconnect für die MySQL InnoDB-Replikation (`mysql-priv`)
  • 1 Interconnect für die DRBD Festplattenreplikation (`drbd-priv`)