MySQL-Server im Teamwork - Replikation und Cluster

Transkript

1 MySQL-Server im Teamwork - Replikation und Cluster DOAG München, 2015-Sep-28 Jörg Brühe Senior Support Engineer, FromDual GmbH joerg.bruehe@fromdual.com 1 / 33

2 FromDual GmbH Support Beratung remote-dba Schulung 2 / 33

3 Zur Person Entwicklung verteiltes SQL-DBMS: Unix-Portierung, Anschluss Archivierungs-Tools (ADSM, NetWorker) MySQL Build Team: Release-Builds inkl. Tests, Paketierung, Skripte,... DBA: MySQL für eine Web-Plattform (Master-Master-Replikation) Support-Ingenieur (FromDual): Support + Remote-DBA für MySQL / MariaDB / Percona mit oder ohne Galera Cluster 3 / 33

4 Inhalt MySQL Server: Architektur Binlog Replikation Galera Cluster Fazit 4 / 33

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

6 MySQL Server: Architektur Binlog Replikation Galera Cluster Fazit 6 / 33

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 / 33

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 / 33

9 MySQL Server: Architektur Binlog Replikation Galera Cluster Fazit 9 / 33

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 / 33

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

12 MySQL Server: Architektur Binlog Replikation Galera Cluster Fazit 12 / 33

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 / 33

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 / 33

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 / 33

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 mehrere Slaves an einem Master möglich 16 / 33

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 / 33

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 / 33

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

20 MySQL Server: Architektur Binlog Replikation Galera Cluster Fazit 20 / 33

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, Ausfall erzwingt Struktur-Änderung (Erleichterung in 5.7 durch Multi-Master) Dynamische Änderungen sind schwierig 21 / 33

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

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 / 33

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 / 33

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

26 Eigenschaften von Galera (2) - Patch der MySQL-Quellen (Codership bietet Binaries) - Vorsicht bei Hot Spots (Zeilen) - Späte Konflikt-Erkennung (Prüfung erst bei Commit) - Mindestgröße drei Knoten - Synchronisations-Dauer bei großer DB (mysqldump -> xtrabackup oder rsync) 26 / 33

27 Zertifizierung bei Commit 27 / 33

28 MySQL Server: Architektur Binlog Replikation Galera Cluster Fazit 28 / 33

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

30 Vergleich (1) Replikation Standard Alle Handler Aufwärts-kompatibel Mind 2 Knoten HA durch Failover Kommunikation: Hierarchisch, Kette asynchron Verzögerung möglich Filtern möglich Galera Zusatzprodukt InnoDB gleiche Versionen Mind 3 Knoten HA ohne Änderung symmetrisch, parallel Quasi-synchron sofort alles 30 / 33

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

32 Vergleich (3) Replikation kurze Unterbrechung: Replikation fortsetzen lange Unterbrechung: Replikation fortsetzen Struktur-Änderung: Manuell / Zusatz-Tool Aufsetzen: Schnappschuss, Master bleibt verfügbar Galera IST (inkrementeller Transfer) SST (kompletter Transfer) Automatisch / dynamisch Komplett-Transfer, Donor tlw. Blockiert 32 / 33

33 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 33 / 33