MySQL-Server im Teamwork - Replikation und Cluster
Content
www.fromdual.com
MySQL-Server im Teamwork Replikation und Cluster
DOAG-Konferenz, 2015-Nov-17
Jörg Brühe
Senior Support Engineer, FromDual GmbH
[email protected]
1 / 33
FromDual GmbH
www.fromdual.com
Support
Beratung
remote-DBA
Schulung
2 / 33
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 / 33
Inhalt
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
4 / 33
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 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
6 / 33
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 / 33
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 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
9 / 33
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 / 33
Binlog
www.fromdual.com
●
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
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
12 / 33
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 / 33
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 / 33
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 / 33
●
Empfehlung: „read-only = 1“ auf Slave
●
mehrere Slaves an einem Master möglich
...
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
16 / 33
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 masterdata“
Ab MySQL 5.6:
●
●
GTID = „Global Transaction ID“
Replikation: „change master to ...“ mit Host,
Port, User, Password und „auto_position = 1“
17 / 33
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 / 33
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 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
20 / 33
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, Ausfall erzwingt
Struktur-Änderung
(Erleichterung in 5.7 durch Multi-Master)
●
Dynamische Änderungen sind schwierig
21 / 33
Bessere Alternative
www.fromdual.com
●
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
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 / 33
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 / 33
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 / 33
Eigenschaften von Galera (2)
www.fromdual.com
- 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
Zertifizierung bei Commit
www.fromdual.com
http://galeracluster.com/documentation-webpages/certificationbasedreplication.html
27 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
28 / 33
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 / 33
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 / 33
Vergleich (2)
Replikation
Lese-Scale-Out
Schreib-Knoten:
1* Write
Schreiben konst.
www.fromdual.com
Galera
Lese-Scale-Out
n* Write
Schreiben erhöht
Konflikt lokal:
Fehler bei Statement
Schreib-Knoten:
n* Write
Fehler bei Statement
n* Write
Konflikt verteilt:
Replikations-Abbruch
Rollback bei Commit
31 / 33
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 / 33
Q&A
www.fromdual.com
Fragen ?
Diskussion?
Wir haben Zeit für ein persönliches Gespräch – Stand 308
●
FromDual bietet neutral und unabhängig:
●
Beratung
●
Remote-DBA
●
Support für MySQL, Galera, Percona Server und MariaDB
●
Schulung
www.fromdual.com/presentations
33 / 33
MySQL-Server im Teamwork Replikation und Cluster
DOAG-Konferenz, 2015-Nov-17
Jörg Brühe
Senior Support Engineer, FromDual GmbH
[email protected]
1 / 33
FromDual GmbH
www.fromdual.com
Support
Beratung
remote-DBA
Schulung
2 / 33
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 / 33
Inhalt
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
4 / 33
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 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
6 / 33
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 / 33
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 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
9 / 33
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 / 33
Binlog
www.fromdual.com
●
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
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
12 / 33
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 / 33
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 / 33
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 / 33
●
Empfehlung: „read-only = 1“ auf Slave
●
mehrere Slaves an einem Master möglich
...
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
16 / 33
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 masterdata“
Ab MySQL 5.6:
●
●
GTID = „Global Transaction ID“
Replikation: „change master to ...“ mit Host,
Port, User, Password und „auto_position = 1“
17 / 33
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 / 33
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 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
20 / 33
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, Ausfall erzwingt
Struktur-Änderung
(Erleichterung in 5.7 durch Multi-Master)
●
Dynamische Änderungen sind schwierig
21 / 33
Bessere Alternative
www.fromdual.com
●
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
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 / 33
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 / 33
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 / 33
Eigenschaften von Galera (2)
www.fromdual.com
- 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
Zertifizierung bei Commit
www.fromdual.com
http://galeracluster.com/documentation-webpages/certificationbasedreplication.html
27 / 33
www.fromdual.com
MySQL Server: Architektur
Binlog
Replikation
Galera Cluster
Fazit
28 / 33
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 / 33
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 / 33
Vergleich (2)
Replikation
Lese-Scale-Out
Schreib-Knoten:
1* Write
Schreiben konst.
www.fromdual.com
Galera
Lese-Scale-Out
n* Write
Schreiben erhöht
Konflikt lokal:
Fehler bei Statement
Schreib-Knoten:
n* Write
Fehler bei Statement
n* Write
Konflikt verteilt:
Replikations-Abbruch
Rollback bei Commit
31 / 33
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 / 33
Q&A
www.fromdual.com
Fragen ?
Diskussion?
Wir haben Zeit für ein persönliches Gespräch – Stand 308
●
FromDual bietet neutral und unabhängig:
●
Beratung
●
Remote-DBA
●
Support für MySQL, Galera, Percona Server und MariaDB
●
Schulung
www.fromdual.com/presentations
33 / 33
