Embed Size (px)
Citation preview
www.fromdual.com
1 / 41
MySQL-Server im Teamwork -Replikation und Galera Cluster
FrOSCon 2016, St. Augustin
Jörg BrüheSenior Support Engineer, FromDual GmbH
CC-BY-SA
www.fromdual.com
2 / 41
Über FromDual GmbH
Support
remote-DBA
Schulung
Beratung
www.fromdual.com
3 / 41
● 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 + Schulungfür MySQL / MariaDB / Perconamit oder ohne Galera Cluster
Über mich
www.fromdual.com
4 / 41
Inhalt
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
5 / 41
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“
www.fromdual.com
6 / 41
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
7 / 41
Client-Server-DBMS
App App App
Server
Disk
Client (Applikation)lokal oder remote
Socket, LAN oder Internet
Server ist eigener ProzessMulti-threaded: 1 Thread je Session
Platte / SSD, lokal oder SAN
www.fromdual.com
8 / 41
Server intern
mysqld
MySQL ist eine multi-Thread und NICHT eine multi-Prozess Applikation!
Application / Client
ThreadCache
ConnectionManager
User Au-thentication
CommandDispatcherLogging
Query CacheModule
QueryCache
Parser
Optimizer
Access Control
Table Manager
Table OpenCache (.frm, fh)
Table DefinitionCache (tbl def.)
Handler Interface
MyISAM Memory NDB PBXTInnoDB ...Aria XtraDB Federated-X
www.fromdual.com
9 / 41
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
10 / 41
Ebenen + Binlog
MyI
SA
M
Inn
oD
B
...
Use
r th
read
2
Use
r th
read
1
...
SQL-Ebene:- Parser- Optimizer- Privilegien- Query Cache- …
Handler Interface
Datei-Ebene:- Tabellen-Handler- InnoDB: - Satz-Zugriffe - Satz-Sperren - Recovery - ...
Binlog:Alle Daten-und Schema-Änderungen
www.fromdual.com
11 / 41
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
www.fromdual.com
12 / 41
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
13 / 41
Replikation bei MySQL
● Anwendungen kommunizieren mit „Master“● „Master“ protokolliert alle Änderungen● „Slave“ hat identischen Anfangszustand
● Slave holt alle Änderungen vom Masterund wendet sie bei sich an
● Replikation läuft asynchron● Slave stoppt Replikation bei Abweichung
www.fromdual.com
14 / 41
Slave holt Binlog vom Master
Use
r th
read
2
Use
r th
read
1
...
Use
r th
read
3
MyI
SA
M
Inn
oD
B
...
Use
r th
read
2
Use
r th
read
1
...
SQ
L t
hre
ad
IO t
hre
ad
BinlogRelayLog
MyI
SA
M
Inn
oD
B
...
Slave:“log-bin = FILE”, sonst kein Binlog“log_slave_updates = 1” für Weiterleitung
Master:“log-bin = FILE”, sonst kein Binlog (keine Master-Funktion)
Binlog
www.fromdual.com
15 / 41
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
www.fromdual.com
16 / 41
Replikations-Kaskade
Use
r th
read
2
Us
er t
hre
ad 1
...
Us
er t
hre
ad 3
MyI
SA
M
Inn
oD
B
...
MyI
SA
M
Inn
oD
B
...
MyI
SA
M
Inn
oD
B
...
SQ
L t
hre
ad
IO t
hre
ad
Use
r th
read
2
Us
er t
hre
ad
1
...
SQ
L t
hre
ad
IO t
hre
ad
Use
r th
read
2
Use
r th
rea
d 1
...
● Empfehlung: „read-only = 1“ auf Slave„log_slave_updates = 1“
● mehrere Slaves an einem Master möglich
www.fromdual.com
17 / 41
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 masterdata“
Ab MySQL 5.6:● GTID = „Global Transaction ID“
● Replikation: „change master to ...“mit Host, Port, User, Passwordund „auto_position = 1“
www.fromdual.com
18 / 41
Master-Master-Replikation
Use
r th
read
2
Use
r th
read
1
...
Use
r th
read
3
MyI
SA
M
Inn
oD
B
...
Use
r th
read
2
Use
r th
read
1
...
SQ
L t
hre
ad
IO t
hre
ad
BinlogRelayLog
MyI
SA
M
Inn
oD
B
...
Binlog
SQ
L t
hre
ad
IO t
hre
ad
RelayLog
● Überlappende Änderungen sind fatal!
www.fromdual.com
19 / 41
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-Replikationin Arbeit: ”group replication“
www.fromdual.com
20 / 41
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
21 / 41
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
www.fromdual.com
22 / 41
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
www.fromdual.com
23 / 41
Galera Cluster
App App App
Load balancing (LB)
Node 2 Node 3Node 1
wsrep
Galera replication
wsrep wsrep
Inklusive Ausfall-Erkennungund Redirection für HA
“Working Set Replication”
Vorzugsweise eigenes Netz
lokale Platten,jeweils Daten komplett
= =
“shared nothing” Architektur
www.fromdual.com
24 / 41
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
www.fromdual.com
25 / 41
Ablauf
Graph by Vadim Tkachenko(Percona):
http://www.mysqlperformanceblog.com/2012/01/19/percona-xtradb-cluster-feature-2-multi-master-replication/
www.fromdual.com
26 / 41
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)
www.fromdual.com
27 / 41
Zertifizierung bei Commit
http://galeracluster.com/documentation-webpages/certificationbasedreplication.html
www.fromdual.com
28 / 41
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
29 / 41
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, ...)
www.fromdual.com
30 / 41
Vergleich (1)
Replikation Galera Cluster
Standard Zusatzprodukt
alle Handler InnoDB
beliebige Plattform Linux
aufwärts-kompatibel gleiche Versionen
mind 2 Knoten mind 3 Knoten
HA durch Failover HA ohne Änderung
Kommunikation:
hierarchisch, Kette symmetrisch, parallel
asynchron quasi-synchron
Verzögerung möglich sofort
Filtern möglich alles
www.fromdual.com
31 / 41
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
www.fromdual.com
32 / 41
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, automatisch,
Schnappschuss + Binlog, Komplett-Transfer,
Master bleibt verfügbar Donor tlw. blockiert
www.fromdual.com
33 / 41
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.“
https://de.wikipedia.org/wiki/CAP-Theorem
www.fromdual.com
34 / 41
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Vergleich
Beispiele / Wann was (nicht)
www.fromdual.com
35 / 41
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
www.fromdual.com
36 / 41
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 !
www.fromdual.com
37 / 41
Beispiel: Globale Produktion
Lösung:Replikation mit
Filterung
Anforderung:Zentrale (D) undWerke (BR, CN, ...) mitselektiver Übertragung
www.fromdual.com
38 / 41
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 !
www.fromdual.com
39 / 41
Hot Spot
Parallele Änderungen derselben Zeile(n) führen zu Konflikten:
● Replikation: Häufig AbbruchInhalte werden unterschiedlich!
● Galera: Häufig Rollback
=> Einen Schreib-Knoten auswählen !
www.fromdual.com
40 / 41
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
www.fromdual.com
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
www.fromdual.com/presentations
