MySQL-Server im Teamwork - Replikation und Galera Cluster

Transkript

1 MySQL-Server im Teamwork - Replikation und Galera Cluster FrOSCon 2016, St. Augustin Jörg Brühe Senior Support Engineer, FromDual GmbH joerg.bruehe@fromdual.com CC-BY-SA 1 / 41

2 Über FromDual GmbH Support Beratung remote-dba Schulung 2 / 41

3 Über mich Entwicklung verteiltes SQL-DBMS: Unix-Portierung, SQL-Standardisierung (X/Open), Anschluss Archivierungs-Tools (ADSM, NetWorker) MySQL Build Team (MySQL -> Sun -> Oracle): Release-Builds inkl. Tests, Paketierung, Skripte,... DBA: Web-Plattform, MySQL in Master-Master-Replikation Support-Ingenieur (FromDual): Support + Remote-DBA + Beratung + Schulung für MySQL / MariaDB / Percona mit oder ohne Galera Cluster 3 / 41

4 Inhalt MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 4 / 41

5 Allgemeines Konzepte, nicht Details: der Wald, nicht die Bäume MySQL 5.5 / 5.6 (GA-Versionen) Übertragbar von MySQL (Oracle) auf Percona und MariaDB Nicht anwendbar auf embedded MySQL Nicht betrachtet: NDB = MySQL Cluster 5 / 41

6 MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 6 / 41

7 Client-Server-DBMS App App App Client (Applikation) lokal oder remote Socket, LAN oder Internet Server Server ist eigener Prozess Multi-threaded: 1 Thread je Session Disk Platte / SSD, lokal oder SAN 7 / 41

8 Server intern Application / Client Thread Cache Logging Query Cache Connection Manager mysqld Optimizer User Authentication MySQL ist eine multi-thread und NICHT eine multi-prozess Command Applikation! Access Control Dispatcher Query Cache Module Table Manager Parser Table Open Cache (.frm, fh) Table Definition Cache (tbl def.) Handler Interface MyISAM InnoDB Memory NDB PBXT Aria XtraDB Federated-X... 8 / 41

9 MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 9 / 41

10 Ebenen + Binlog User thread 1 User thread 2... SQL-Ebene: - Parser - Optimizer - Privilegien - Query Cache - Binlog: Alle Datenund Schema- Änderungen MyISAM InnoDB... Handler Interface Datei-Ebene: - Tabellen-Handler - InnoDB: - Satz-Zugriffe - Satz-Sperren - Recovery / 41

11 Binlog Alle ausgeführten Daten-Änderungen Alle ausgeführten Schema-Änderungen Zeitstempel Zwingend für Point-in-Time-Recovery PITR Unabhängig von Tabellen-Handler Formate statement, row und mixed Segmente mit konfigurierbarer Größe Fortlaufend nummeriert 11 / 41

12 MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 12 / 41

13 Replikation bei MySQL Anwendungen kommunizieren mit Master Master protokolliert alle Änderungen Slave hat identischen Anfangszustand Slave holt alle Änderungen vom Master und wendet sie bei sich an Replikation läuft asynchron Slave stoppt Replikation bei Abweichung 13 / 41

14 Slave holt Binlog vom Master User thread 3 User thread 1 User thread 2 MyISAM InnoDB... User thread 1 User thread 2... SQL thread IO thread... Binlog Relay Log Binlog MyISAM InnoDB... Slave: log-bin = FILE, sonst kein Binlog log_slave_updates = 1 für Weiterleitung Master: log-bin = FILE, sonst kein Binlog (keine Master-Funktion) 14 / 41

15 Typische Anwendungen High Availability Geo-Redundanz Höhere Lese-Last unterstützen (= read scale-out ) Read-Only-Instanz(en) für z.b. Backup oder Reports Verzögerte Replikation ist möglich Filterung (nach DB oder Tabelle) ist möglich 15 / 41

16 Replikations-Kaskade MyISAM InnoDB... MyISAM InnoDB... MyISAM InnoDB... User thread 1 User thread 2... SQL thread IO thread User thread 1 User thread 2... SQL thread IO thread User thread 3 User thread 1 User thread 2... Empfehlung: read-only = 1 auf Slave log_slave_updates = 1 mehrere Slaves an einem Master möglich 16 / 41

17 Einträge im Binlog Ursprünglich: Identifikation durch Filename und Position Replikation: change master to... mit Host, Port, User, Password, File, Position Siehe auch mysqldump master data Ab MySQL 5.6: GTID = Global Transaction ID Replikation: change master to... mit Host, Port, User, Password und auto_position = 1 17 / 41

18 Master-Master-Replikation User thread 3 User thread 1 MyISAM InnoDB... User thread 1 User thread 2... SQL thread IO thread User thread 2... Relay Log Binlog MyISAM SQL thread IO thread Binlog InnoDB... Relay Log Überlappende Änderungen sind fatal! 18 / 41

19 Anmerkungen zur Replikation Master-Master ist umstritten, Vorsicht! Replikation erhöht den Lese-Durchsatz, aber nicht/kaum den Schreib-Durchsatz Replikation bringt File-IO und Netzlast Format row ist effizienter, aber weniger lesbar Große Installation: booking.com Lese-Tipp (Giuseppe Maxia, August 2015): datacharmer.blogspot.de Neu in MySQL 5.7: Multi-Source-Replikation in Arbeit: group replication 19 / 41

20 MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 20 / 41

21 Schwächen der Replikation Asynchron Asymmetrisch Nur ein Schreib-Knoten Paralleles Schreiben verursacht Abbruch HA braucht Failover nach Knoten-Ausfall Jeder Knoten ist SPOF für seine Slaves, Ausfall erzwingt Struktur-Änderung (Erleichterung in 5.7 durch Multi-Source-Replikation) Dynamische Änderungen sind schwierig 21 / 41

22 Bessere Alternative Synchrone Übertragung Symmetrischer Cluster Schreibzugriffe überall möglich Verteilte Konflikt-Analyse und -Behebung HA durch Kontinuität nach Knoten-Ausfall Dynamischer Eintritt / Austritt möglich 22 / 41

23 Galera Cluster App App App Load balancing (LB) Inklusive Ausfall-Erkennung und Redirection für HA Node 1 Node 2 Node 3 wsrep wsrep Galera replication wsrep Working Set Replication Vorzugsweise eigenes Netz = = lokale Platten, jeweils Daten komplett shared nothing Architektur 23 / 41

24 Eigenschaften von Galera (1) + Basiert auf InnoDB (wg. Transaktionen und Rollback) + Überträgt auch Benutzer-Definitionen usw. + Quasi-synchrone Übertragung beim Commit, Prüfung auf Konflikt-Freiheit, effizient + Symmetrisch, HA ohne Server-Failover, Quorum + Kein Transaktions-Verlust + Scale-Out für Lesen, auch mehr Schreiben + Dynamischer Eintritt / Austritt möglich, automatische Synchronisation 24 / 41

25 Ablauf Graph by Vadim Tkachenko (Percona): percona-xtradb-cluster-feature-2-multi-master-replication/ 25 / 41

26 Eigenschaften von Galera (2) - Patch der MySQL-Quellen (Codership bietet Binaries, auch MariaDB und Percona) - Vorsicht bei Hot Spots (Zeilen) - Späte Konflikt-Erkennung, kompl. Rollback (Prüfung erst bei Commit) - Mindestgröße drei Knoten - Synchronisations-Dauer bei großer DB (mysqldump -> xtrabackup oder rsync) - Linux-only (bisher) 26 / 41

27 Zertifizierung bei Commit 27 / 41

28 MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 28 / 41

29 MySQL-Server im Teamwork Alternativen: Replikation oder Galera Cluster Redundanz bei Maschine und Storage HA Scale-Out, besonders für Lese-Last Instanzen für Reports, Analyse, Backup Daten lokal lese-verfügbar (Filialen,...) 29 / 41

30 Vergleich (1) Replikation Standard alle Handler beliebige Plattform aufwärts-kompatibel mind 2 Knoten HA durch Failover Kommunikation: hierarchisch, Kette asynchron Verzögerung möglich Filtern möglich Galera Cluster Zusatzprodukt InnoDB Linux gleiche Versionen mind 3 Knoten HA ohne Änderung symmetrisch, parallel quasi-synchron sofort alles 30 / 41

31 Vergleich (2) Replikation Galera Lese-Scale-Out Lese-Scale-Out Schreiben konst. Schreiben erhöht 1 Master: 1* Write 1* Write Konflikt lokal: Fehler bei Statement Fehler bei Statement n Master: n* Write n* Write Konflikt verteilt: Replikations-Abbruch Rollback bei Commit 31 / 41

32 Vergleich (3) Replikation Galera kurze Unterbrechung: Replikation fortsetzen IST (inkrementeller Transfer) lange Unterbrechung: Replikation fortsetzen SST (kompletter Transfer) Knoten dazu/weg: manuell / Zusatz-Tool automatisch / dynamisch Aufsetzen: manuell, Schnappschuss + Binlog, Master bleibt verfügbar automatisch, Komplett-Transfer, Donor tlw. blockiert 32 / 41

33 CAP-Theorem C = Consistency (gleiche Daten überall) A = Availability (das System antwortet) P = Partition Tolerance (Netzwerk-Ausfall) In einem verteilten System ist es unmöglich, gleichzeitig die drei Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz zu garantieren / 41

34 MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 34 / 41

35 Kommunikations-Ausfall (1) Galera Cluster: Isolierter Knoten hat kein Quorum => nicht benutzbar Quorum ist gefährdet! Aktive Knoten schreiben gcache als Files, Aufbewahrungsdauer? Umschaltung auf SST droht 35 / 41

36 Kommunikations-Ausfall (2) Replikation: Master schreibt Log-Segmente als Files IO-Thread will von Binlog-Position / GTID lesen, probiert periodisch bis Erfolg purge log vermeiden! Replikation ist toleranter als Galera Cluster! 36 / 41

37 Beispiel: Globale Produktion Lösung: Replikation mit Filterung Anforderung: Zentrale (D) und Werke (BR, CN,...) mit selektiver Übertragung 37 / 41

38 Paralleles Schreiben + Konflikt Galera: Retry von autocommit-statements möglich Transaktions-Konflikt führt zu Rollback => Wiederholung durch Applikation Replikation: Slave bemerkt, kein Kontakt zur Applikation => Replikation bricht ab Replikation braucht Admin-Eingriff bei Konflikt! 38 / 41

39 Hot Spot Parallele Änderungen derselben Zeile(n) führen zu Konflikten: Replikation: Häufig Abbruch Inhalte werden unterschiedlich! Galera: Häufig Rollback => Einen Schreib-Knoten auswählen! 39 / 41

40 Hochverfügbarkeit Replikation: Failover manuell (Reaktionszeit) oder automatisch (korrekt?) Slave Lag, neue Master-Auswahl Galera: Symmetrisch, kein Rollenwechsel Virtuell-synchrone Replikation (kein Lag) => Vorteil Galera 40 / 41

41 Q & A Fragen? Diskussion? Wir haben Zeit für ein persönliches Gespräch... FromDual bietet neutral und unabhängig: Beratung Remote-DBA Support für MySQL, Galera, Percona Server und MariaDB Schulung /presentations 41 / 41