1Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
MySQL Scaleout
Kristian Köhntopp, Consultant,
MySQL GmbH
<[email protected]>http://blog.koehntopp.de
http://mysqldump.azundris.com
Handy aus?
2Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Warum machen wir das?
• Performance Tuning hat Grenzen– Optimierung der bestehenden Anwendung durch
• Änderung der Datenbank-Konfiguration,• Kompatible Änderung des Schemas (Typen, Indices),• Kompatible Änderung von SQL Query Strings,• Lokale Änderungen der Anwendung,
– PT ist gut für ein Wachstum von 2x bis 3x
• Aber auch nur, wenn der Kunde vorher schlecht war.
• Ein Wachstum von 10x oder mehr zieht immer eine Änderung der Architektur nach sich
– Bei einem boomenden Geschäft dient PT dazu, sich die Zeit für das Scaleout zu erkaufen
3Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Beispiel Mail
• Dienste in einem Mail-Server
– SMTP– SMTP AUTH
• LDAP?– SSL– IMAP– POP– Spam– Antivirus– Vacation/Autoresponder– Addressbook
• LDAP?– Mailinglisten/Mass Mailer– Web Interface
4Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Beispiel Mail
• Wie sieht eine Lösung aus für
– 2 Benutzer (Meine Freundin und mich?)– 200 Benutzer (Ein Verein wie Toppoint.de?)– 20 000 Benutzer (Eine große Firma?)– 2 000 000 Benutzer (Projektgröße hamburg.de)– 20 000 000 Benutzer (web.de)– 200 000 000 Benutzer (Google Mail, Yahoo!, Hotmail)
• Die gebotenen Dienste sind immer dieselben.• Die Lösungen haben zum Teil keine erkennbare
Ähnlichkeit.
• Infrastrukturentwicklung und wachstumsinduzierter Entwicklungsaufwand werden häufig unterschätzt.
– So etwas tötet Firmen!
5Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Wachstumsgrenzen
• Pure Kistengröße
– Theoretische Grenze:
E 25000 von Sun = 72 CPUs, 576 GB RAM, Petabytes Storage
– Praktisch so nicht umsetzbar:
• Investitionsklotz zu groß• Bang/Buck Ratio nicht wirklich attraktiv
• Aber hoher Geek-Acceptance-Faktor
– Realistische Grenze:
8 Core, 64 GB RAM, 28 Spindeln lokal oder SAN
6Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Wachstumsgrenzen
• Synchrone Paradigmen
– Die gewohnte Art zu programmieren saturiert nur einen Core
• F() -> Code von F wird ausgeführt, Hauptstrang wartet
– Das ist ein guter Ansatz für eine kurze Time-To-Market
• Einigermaßen gut verstanden• Vergleichsweise leicht zu debuggen• Personell gut zu bestücken
7Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Wachstumsgrenzen
• Asynchrone Calls erfordern Umdenken und Umstrukturieren des Codes
– Send F() -> Return Handle H(F).– Hauptstrang arbeitet, F() arbeitet.– F benachrichtigt Hauptstrang, daß ein Result vorliegt.– Resynchronisation result(H(F)) -> Hauptstrang.
• Aufgabe des Hauptstranges ist nun:
– Vermeide Waits. Halte so viele Subthreads so busy wie möglich.• Thread Local Storage, Debugging, Ungeeignete API (in Unix)• Queues, Locks, Deadlocks• Latenz
8Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Wachstumsgrenzen
• Wenn man sowieso asynchron arbeitet:
– Parameter einpacken (Marshalling)– Request versenden– Parameter auspacken (Unmarshalling)– F aufrufen– Result verpacken und zurücksenden
• Viele Kopien von F() auf vielen Kisten haben
– Load Balancing– Livetesting, Liste von Kopien aktuell handhaben– ggf. doppelte Funktionsaufrufe (weiche Fehler behandeln)
• MapReduce, Hadoop!– Vorteil: Subthreads müssen nicht auf der lokalen Hardware laufen– Nachteil: Latenzmaschine
9Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Folgerungen für die Architektur
• SOA oder MapReduce– Vertikale Strukturierung vs. horizontale Strukturierung
• Asynchronizität ist zwingend– 2PC ist keine Lösung!
• Netzwerklatenz begrenzt die Commit-Frequenz
– Wir müssen mit Inkonsistenzen leben!• ACID?• Optimistisches Locking!• Sigma2 – Sigma3 als Fehlerrate
• Locality wird wichtiger als Normalität– Redundanzen!
• Ausfälle!– Bei n-> unendlich ist p(Ausfall) -> 1– Redundanzen!
10Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Das Write-Problem
• Reads skalieren ist leicht!
– Wir haben jede Menge Kopien– Wir legen nur mittleren Wert auf Konsistenz
• Writes sind anstrengend
– Writes müssen persistent gemacht werden.– Das erzeugt zwingend Disk-Aktivität.– Das erzeugt zwingend Replikationstraffic für die Read-Kopien.
• Mal n
• Writes sind entweder 2PC oder wir haben einen SPOF– Write anywhere -> 2PC + Locking Latenz– Writes central -> SPOF -> Wir brauchen ein HA-Konzept.
11Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Realisierung
• LB -> Webfrontends
– Webfrontends stateless– Was ist mit Sessions?
• Sessions in memcached
– Eine Datenbank ist sinnlos, wenn die Daten die FormKey -> BLOB
haben.
– Skalierung des memcached als Array– SessionID % Arraysize = Adresse
• Memcached-Ausfall?– Ignorieren, Multicast-Buddies, DHT?– DHT vermutlich Overkill (behandelt hauptsächlich Churnrate)
12Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Realisierung
• Persistenzlayer unterhalb von Webfrontends:2-Tier vs. 3-Tier
• Gründe für 3-Tier:– Web Services
• Middleware mit Auth, http als RPC-Protokoll = Instant Web Service!
– Entwicklungstaktische Probleme• Kapselung auf Projektebene
– API mit Async-Calls + Async-Clients = Multithreading + Scaling
• Gründe für 2-Tier:– Weniger Overhead– Weniger Entwicklungskomplexität
13Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Realisierung
• Standardpfad:
– Entwicklung als Monolith
– 2-Tier
– 3-Tier (oder Tod!)
14Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Redundanzen in der Datenhaltung
• Leicht skalierbare Reads– “Ask any local copy”– Umgang mit veralteten Daten
• Redundanzen veralten oder werden ungültig
– Konsistenzprüfer mit entwickeln– Reparaturprogramme mit entwickeln
– Viele Entwickler haben mit dem Konzept des partiellen Fehlers große Probleme
• Writes skalieren sich immer noch schlecht– Siehe vorne
15Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Writes skalieren
• Wie Writes skalieren?
– Nicht schreiben (Sessions)
– Später schreiben (innodb_flush_log_at_trx_commit = 2, ACID ist Luxus)
– Kleine Writes (1:1 Relationen volatiler Daten)– Kleine Writes (Redo Log schreibt Columns, nicht Rows, nicht
Pages)
– Lineare Writes (Redo Log statt Random I/O)
– PartitionenP(X) = { p(1)...p(n),
ALL(x,y: x!= y): p(x) ∩ p(y) = {},ALL(x): Up(x) = P }
– Funktionale Trennung:3-Tier, lokale Dienste kapseln
16Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Writes distributieren
• Wir müssen die Änderungen an alle Kopien verteilen“Replikation”
– MySQL Replikation:
• Leicht aufzusetzen und zu betreiben.• Schlecht zu filtern.• Skaliert nicht über einen Core hinweg.• Konzeptuelle Grenzen von SBR.
• 5.1 führt RBR ein.• RBR ist prinzipiell parallelisierbar.
– Manuelle Datenpumpen
• Zum Beispiel mk-table-sync aus Maatkit.
– Queueing Services, Transaktionsmonitore• Und schon sind wir wieder 2PC.
17Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Standardarchitektur (mit Shared Disk)• Active/Passive
= Private IP =10.10.10.21
Active Server Passive Server
Cluster Management= Virtual IP =10.10.10.10
= Private IP =10.10.10.20
Cluster Agent
SAN
Web/AppServer
Web/AppServer
Cluster Agent
18Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Standardarchitektur (mit DRBD)
= Private IP =10.10.10.21
Active Server Passive Server
= Private IP =10.10.10.20
Primary DRBD Secondary DRBDDRBD
Linux Heartbeat= Virtual IP =10.10.10.10
Web/AppServer
Web/AppServer
19Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Standardarchitektur
• Der Stack:– DRBD (oder Shared Disk)– LVM– FS (xfs oder ext3)– Datenbank
– Darüber heartbeat• Viele Kunden bereiten den Failover vor, führen ihn aber manuell durch.
• Restore:– Snapshots mit LVM (z.B. Mylvmbackup).– Sicherung pysikalischer Backups.– Restore mit lineare Write-Rate der Platten.– Partielle Restores nicht möglich.
• Man braucht einen Scratch-Host.
20Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Replikation statt DRBD
Web/AppServer
Web/AppServer
Writes & Reads
MySQL Master
I/OThread
SQLThread
Writes
relaybinlog
MySQL Slave
mysqld
data
index &binlogs
mysqld
databinlogReplication
21Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
ReplikationstopologienMaster > Slave
Masters > Slave (Multi-Source)
Master < > Master (Multi-Master)
Master > Slaves
Circular (Multi-Master)
Master > Slave > Slaves
22Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
“Master-Master”
• Ist kein Multi-Master– kein 2PC– Lösung des Insert-Problems mit aio und aii– Updates ungelöst
• Besserer Name: “Ring-mit-n”
• Probleme:– Instanzen sind entkoppelt, insbesondere die Binlog Position
– Probleme mit Slaves beim Failover
– Probleme mit Restore wg Binlog Position• z.B. Rebuild + logisches Restore• z.B. Restore von anderem Host
23Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Anwendungen anpassen
• “Replication Aware” Applications– 2 Datenbank-Links (Master, Any Slave)– Schreiben zum Master– Lesen von beliebigem Slave
• Wie den Slave auswählen?• Leicht lösbar für PHP, Perl, andere Systeme mit transienten Connects• Schwerer lösbar für Java, andere Systeme mit Pools
• Änderung der Anwendung– Änderungsaufwand minimieren durch MySQL LB (mysql-proxy)– Aber es sind Hints in den Transaktionen notwendig
• “Begin” -> Ist dies ein Read oder ein Write?
24Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Anwendungen anpassen
• Synchronisation?– Write zum Master
– SHOW MASTER STATUS
– Auf dem Slave wait_master_pos() mit Timeout
– Wenn Fail: Read vom Master• Wieso vom Master?
• Verbindung steht schon• Erfolg garantiert!• Slave Lag macht den Master langsamer
25Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Architekturen mit unterschiedlichen Slaves
• Nicht alle Slaves müssen gleich sein
– Fast + Slow Query Slaves
– Fulltext Slaves
• Unterschiedliche Datenstände auf den Slaves
– Partitionen wie oben
– Wie bringt man der Anwendung Partitionen bei?
• Aus WHERE-Bedingung folgt Verbindungswahl• Also Änderung der Anwendung oder• Rewrite der Query on-the-fly im MySQL LB (Proxy)
26Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt
Fazit
• Alle “Großen” bauen verteilte, asynchrone Systeme.
• Das ist ein schwieriges Problem für das noch keine Fertigteile existieren.
• Aber die Architektur selbst ist erprobt und getestet.
•Fragen?