DAOG SIG: HA Architekturen mit MySQL

  • 454 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
454
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. HA Architekturen mit MySQL DOAG SIG Database MySQL, Hannover, 19. May 2011 Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com http://www.fromdual.com www.fromdual.com 1
  • 2. FromDual GmbH● Wir bieten neutral und Hersteller unabhängig: ● Beratung (on-site und remote) ● Remote-DBA / MySQL Betrieb ● Support (ab EUR 1000.- pro Jahr!) ● Schulung (DBA, Performance Tuning, Scale-Out, High Availability, MySQL Cluster)● Wir sind Consulting Partner der Open Database Alliance (ODBA.org)● Oracle Silver Partner (OPN) www.fromdual.com 2
  • 3. Inhalt HA Architekturen mit MySQL ➢ MySQL Scale-Out vs. Scale-Up ➢ Master-Slave Replikation ➢ Master-Master Replikation ➢ Aktiv/Passiv Failover Cluster mit DRBD ➢ Aktiv/Passiv Failover Cluster mit SAN ➢ MySQL Cluster www.fromdual.com 3
  • 4. MySQL Scale-Out vs. Scale-Up ● Kosten Scale-Up ● MySQL Design ● Physikalische Flaschenhälse ● „Relaxation of Constraints“ Scale-Out www.fromdual.com 4
  • 5. Master – Slave Replikation binlog dump thread master.info IO_ Application thread Async! relay-log.infobinary bin-log.index log Master Slave SQL_ writer thread !thread ... bin-log.m bin-log.n ... relay-log.m relay-log.n www.fromdual.com 5
  • 6. Der MySQL Scale-Out Ansatz Application ro rtw Slave Reporting SlaveM Master Slave Backup Slave 1 Slave 2 Slave 3 ... Load balancer www.fromdual.com 6
  • 7. Vorteile / Nachteile● Einfaches „standard“ Set-up● Master ist ein SpoF! (Single Point of Failure)● Bei Master-Ausfall → Slave neuer Master? ● → Viel Arbeit und heikel!● Bedingt für virtualisierte System / Cloud geeignet (I/O und Netzwerk-Durchsatz). www.fromdual.com 7
  • 8. Master – Master Replikation Applikation VIP M1 M2 Slave 1 Slave 2 Slave 3 Slave Backup Load balancer www.fromdual.com 8
  • 9. Vorteile / Nachteile● Vorsicht beim Schreiben auf beide Master!● Für „ausbalanciertes“ System: min. 2 Slaves● Man erhält so NICHT mehr I/O-Durchsatz!● Daten-INkonsistenzen möglich da Async● Bedingt für virtualisierte System / Cloud geeignet (I/O und Netzwerk-Durchsatz). www.fromdual.com 9
  • 10. Aktiv/passiv fail-over mit DRBD App App App VIP M M “Poor mans SAN” DRBD Slave1 Slave2 Slave3 Load balancing (LB) www.fromdual.com 10
  • 11. Activ/passiv fail-over mit DRBD App App App VIP M M DRBD Slave1 Slave2 Slave3 Load balancing (LB) www.fromdual.com 11
  • 12. Vorteile / Nachteile● Sync Replikation● Keine INkonsistenzen mehr möglich● I/O-Durchsatz ggf. geringer● Slaves failovern „automatisch“ (und richtig)● Bedingt für virtualisierte System / Cloud geeignet (wenn Device durchgereicht wird). www.fromdual.com 12
  • 13. Aktiv/passiv fail-over mit SAN App App App VIP M M SAN Slave1 Slave2 Slave3 Load balancing (LB) www.fromdual.com 13
  • 14. Aktiv/passiv fail-over mit SAN App App App VIP M M SPOF! !!! SAN Slave1 Slave2 Slave3 Load balancing (LB) www.fromdual.com 14
  • 15. Vorteile / Nachteile● I/O sollte nicht mehr das Problem sein.● SAN ist ein SpoF!● Voraussichtlich teurer, wenn SAN nicht schon vorhanden.● SANs sind nicht ganz einfach zu handeln!● Bedingt für virtualisierte System / Cloud geeignet (wenn SAN-Device durchgereicht wird). www.fromdual.com 15
  • 16. MySQL Cluster Application Application Application Application Application NDB-API NDB-API Load balancer SQL Node 1 SQL Node 2 SQL Node 3 ...Mgm Node 1Mgm Node 2 Data Node 1 Data Node 2 Sw. Sw. Data Node 3 Data Node 4 www.fromdual.com 16
  • 17. Vorteile / Nachteile● Sehr grosser Durchsatz (möglich)● Skaliert● I/O kein Problem● Keine „general purpose“ Datenbank● Schlechtere Latency● (noch) Performance Probleme mit Joins● Einen weiteren Floh zu hüten...● Min. 3 phys. Server (co-located)● NICHT für Virtualisierung/Cloud geeignet. www.fromdual.com 17
  • 18. Rant auf Virtualisierung/Cloud● Virtualisierung = „Konsolidieren von idelnden Instanzen“ → OK!● Problem: Netzwerk- und I/O Durchsatz (IOPS + TPS) ● Insbesondere Replikation! ● SAN?● Störungen von aussen: ● MySQL Cluster (RT)● MySQL oft im High Performance Umfeld!● Cloud = Hinzufügen von Ressourcen „on Demand“?● Virtualisierung = Klumpenrisiko! www.fromdual.com 18
  • 19. Fragen und Antworten ? Sonst: Slides: www.fromdual.com oder oli.sennhauser@fromdual.com www.fromdual.com 19