MySQL-Server im Teamwork - Replikation und Cluster
Werbung
www.fromdual.com MySQL-Server im Teamwork Replikation und Cluster Administrator-Runde Berlin, 2016-Jan-7 Jörg Brühe Senior Support Engineer, FromDual GmbH [email protected] CC-BY-SA 1 / 41 FromDual GmbH www.fromdual.com Support Beratung remote-DBA Schulung 2 / 41 Zur Person ● www.fromdual.com 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 / 41 Inhalt www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 4 / 41 Allgemeines ● ● ● www.fromdual.com 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 / 41 www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 6 / 41 Client-Server-DBMS App App App www.fromdual.com Client (Applikation) lokal oder remote Socket, LAN oder Internet Server Disk Server ist eigener Prozess Multi-threaded: 1 Thread je Session Platte / SSD, lokal oder SAN 7 / 41 Server intern www.fromdual.com Application / Client Thread Cache Logging Query Cache Connection Manager mysqld Parser Optimizer User Authentication MySQL ist eine multi-Thread und NICHT eine multi-Prozess Applikation! Access Control Command Dispatcher Query Cache Module Table Manager Table Open Cache (.frm, fh) Table Definition Cache (tbl def.) Handler Interface MyISAM InnoDB Memory NDB PBXT Aria XtraDB Federated-X ... 8 / 41 www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 9 / 41 www.fromdual.com SQL-Ebene: - Parser - Optimizer - Privilegien - Query Cache -… ... User thread 2 User thread 1 Ebenen + Binlog Datei-Ebene: ... InnoDB Binlog: Alle Datenund SchemaÄnderungen MyISAM Handler Interface - Tabellen-Handler - InnoDB: - Satz-Zugriffe - Satz-Sperren - Recovery - ... 10 / 41 Binlog www.fromdual.com ● 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 www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 12 / 41 Replikation bei MySQL www.fromdual.com ● 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 Slave: “log-bin = FILE”, sonst kein Binlog “log_slave_updates = 1” für Weiterleitung www.fromdual.com ... ... User thread 2 InnoDB Binlog User thread 1 User thread 3 IO thread Relay Log MyISAM ... SQL thread User thread 2 ... InnoDB Binlog MyISAM User thread 1 Slave holt Binlog vom Master Master: “log-bin = FILE”, sonst kein Binlog (keine Master-Funktion) 14 / 41 Typische Anwendungen ● „High Availability“ ● Geo-Redundanz ● ● www.fromdual.com 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 ● ● ... InnoDB MyISAM ... InnoDB MyISAM ... InnoDB MyISAM ... User thread 2 User thread 1 User thread 3 IO thread SQL thread ... User thread 2 User thread 1 IO thread SQL thread ... User thread 2 User thread 1 Replikations-Kaskade www.fromdual.com Empfehlung: „read-only = 1“ auf Slave „log_slave_updates = 1“ mehrere Slaves an einem Master möglich 16 / 41 Einträge im Binlog www.fromdual.com 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 Binlog ● ... InnoDB MyISAM Relay Log Binlog ... InnoDB MyISAM IO thread SQL thread ... User thread 2 User thread 1 User thread 3 IO thread SQL thread ... User thread 2 User thread 1 Master-Master-Replikation www.fromdual.com Relay Log Überlappende Änderungen sind fatal! 18 / 41 Anmerkungen zur Replikation www.fromdual.com ● ● 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 / 41 www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 20 / 41 Schwächen der Replikation www.fromdual.com ● 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 Bessere Alternative www.fromdual.com ● 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 Galera Cluster App www.fromdual.com App App Inklusive Ausfall-Erkennung und Redirection für HA Load balancing (LB) Node 1 Node 2 Node 3 wsrep wsrep wsrep Galera replication = = “Working Set Replication” Vorzugsweise eigenes Netz lokale Platten, jeweils Daten komplett “shared nothing” Architektur 23 / 41 Eigenschaften von Galera (1) www.fromdual.com + 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 Ablauf www.fromdual.com Graph by Vadim Tkachenko (Percona): http://www.mysqlperformanceblog.com/2012/01/19/ percona-xtradb-cluster-feature-2-multi-master-replication/ 25 / 41 Eigenschaften von Galera (2) www.fromdual.com - 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) 26 / 41 Zertifizierung bei Commit www.fromdual.com http://galeracluster.com/documentation-webpages/certificationbasedreplication.html 27 / 41 www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 28 / 41 MySQL-Server im Teamwork www.fromdual.com ● 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 / 41 Vergleich (1) Replikation Standard Alle Handler Aufwärts-kompatibel Mind 2 Knoten HA durch Failover www.fromdual.com Galera Zusatzprodukt InnoDB gleiche Versionen Mind 3 Knoten HA ohne Änderung Kommunikation: Hierarchisch, Kette asynchron Verzögerung möglich Filtern möglich symmetrisch, parallel Quasi-synchron sofort alles 30 / 41 Vergleich (2) Replikation Lese-Scale-Out Schreiben konst. www.fromdual.com Galera Lese-Scale-Out 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 Vergleich (3) Replikation www.fromdual.com Galera kurze Unterbrechung: Replikation fortsetzen IST (inkrementeller Transfer) lange Unterbrechung: Replikation fortsetzen SST (kompletter Transfer) Struktur-Änderung: Manuell / Zusatz-Tool Automatisch / dynamisch Aufsetzen: Schnappschuss, Master bleibt verfügbar Komplett-Transfer, Donor tlw. Blockiert 32 / 41 CAP-Theorem www.fromdual.com ● 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.“ https://de.wikipedia.org/wiki/CAP-Theorem 33 / 41 www.fromdual.com MySQL Server: Architektur Binlog Replikation Galera Cluster Vergleich Beispiele / Wann was (nicht) 34 / 41 Kommunikations-Ausfall (1) www.fromdual.com 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 Kommunikations-Ausfall (2) www.fromdual.com 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 Beispiel: Globale Produktion www.fromdual.com Lösung: Replikation mit Filterung Anforderung: Zentrale (D) und Werke (BR, CN, ...) mit selektiver Übertragung 37 / 41 Paralleles Schreiben + Konflikt www.fromdual.com 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 Hot Spot ● Replikation: Häufig Abbrüche ● Galera: Hohe Rollback-Häufigkeit www.fromdual.com => Einen Schreib-Knoten auswählen ! 39 / 41 Hochverfügbarkeit www.fromdual.com Replikation: ● ● Failover manuell (Reaktionszeit) oder automatisch (korrekt?) Slave Lag, Master-Auswahl Galera: ● Symmetrisch, kein Rollenwechsel ● Virtuell-synchrone Replikation (kein Lag) => Vorteil Galera 40 / 41 Q&A www.fromdual.com 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 www.fromdual.com/presentations 41 / 41
