Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Grundsätze verteilter Datenbanken

537 views

Published on

MySQL Multi-Master does not exist. Either it's a ring or it's a distributed database.

Published in: Internet
  • Hi there! Get Your Professional Job-Winning Resume Here - Check our website! http://bit.ly/resumpro
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Grundsätze verteilter Datenbanken

  1. 1. Grundsätze verteilter Datenbanken Die wunderbare Welt von Isotopp Donnerstag, 15. März 2012 Grundsätze verteilter Datenbanken Wonka>  Die  http://www.toppoint.de  z.B.  wird  vermutlich  nie  was  haben,  was  in nennenswerte Last­Regionen kommt, aber ich will ­ akademisches Interesse und so ­ schon  wissen,  wie  man  das  da  am  besten  täte.  Was  mich  auch  für  die  Toppoint interessiert: irgendeine Sorte Redundant Array of Inexpensive Databases :) Lalufu> MySQL mit Replication? Alternativ mit DRBD? Isotopp> Mit DRBD. Nicht mit Replikation. Wonka> Lalufu: Hm, Master­Master­Replication geht ja nur mit Zweien. Wenn man nun  mehr  als  das  haben  will,  kann  man  zwar  Ringe  bauen,  aber  nur  einfach verkettete. Isotopp> Wonka: Argh! Master­Master geht nicht mit Replikation. Nie. Wonka> huh? Isotopp> Thread 1 schreibt auf Master 1: insert into t (id, d) values (NULL, 'eins); Zeitgleich schreibt thread 2 auf master 2: insert into t (id, d) values (NULL, 'zwei'); Isotopp> Was steht in der Datenbank master1, was steht in der Datenbank master 2?  Wenn  man  mal  annimmt,  dass  MySQL  auto_increment_increment  und auto_increment_offset korrekt gesetzt sind? Wonka> Isotopp: ok, Problem. Trotzdem gibts reichlich HOWTOs dazu. Isotopp> Wonka: Das ist noch kein Problem. Du kriegst (1, 'eins') und (2, 'zwei'). So weit funktioniert das. kv_> Bei UPDATE sieht's anders aus. Isotopp> Jetzt macht aber Thread 1 auf Master 1 ein UPDATE. Und zwar update t set d = 'een' where id =1; Isotopp> Und Thread 2 macht auf Master 2 ein UPDATE, Und zwar update t set d = 'one' where id = 1; Isotopp> Was steht auf Master 1 und was steht auf Master 2? Isotopp>  Der  Punkt  ist,  daß  es  keine  global  fuer  die  Domain  des  ganzen  Ringes gültige  Serialisierung  von  Ereignissen  gibt,  es  also  keine  globale  Festlegung  der
  2. 2. Reihenfolge  von  Ereignissen  gibt.  Sondern  jeder  lokale  Knoten  hat  seine  eigene Reihenfolge  von  Ereignissen.  Im  Klartext  heißt  das,  daß  auf  Master  1  die Reihenfolge  der  Events  een,  one  sein  kann,  auf  Master  2  aber  one,  een  oder umgekehrt. Lalufu>  Genaugenommen  ist  das  Problem,  daß  Leute  sowas  gerne  hätten,  aber MySQL das nicht liefern kann. Isotopp>  Lalufu:  Nein,  die  Situation  ist  weitaus  komplizierter.  Laß  mich  zu  Ende erklären. Wonka>  http://www.howtoforge.com/mysql_master_master_replication  "This tutorial  describes  how  to  set  up  MySQL  master­master  replication.  We  need  to replicate  MySQL  servers  to  achieve  high­availability  (HA).  In  my  case  I  need  two masters that are synchronized with each other so that if one of them drops down, other could take over and no data is lost. Similarly when the first one goes up again, it will still be used as slave for the live one." Wonka> Also haben die's nicht verstanden... Isotopp> richtig. Genauer: Sie glauben, sie können gewinnen. Aber das Universum kann man nicht bescheißen. Isotopp> Wonka: Du willst also eine solche Serialisierung erzwingen.In sql erzwingt man eine bestimmte Reihenfolge von Ereignissen, indem man für die Domain, in der man arbeitet eine Sperre (englisch: lock) setzt. Man braucht also ein Locking, das in der ganzen Domain gilt. Isotopp> Die Domain ist nun aber nicht mehr eine Kiste, dafür hat Dein SQL Server ja  Locks,sondern  der  Ring.  Und  MySQL  Replikation  hat  spezifisch  kein  Locking Protokoll. Es gibt solche Protokolle, 2PC, 3PC, Paxos und noch ein paar mehr. 2PC ist das schnellste, in dem Sinne, daß es minimale Umlaufanzahlen/Lockzeiten hat. Paxos ist im Sinne der Ausfallsicherheit/Recoverability das Sicherste. Ohne ein solches Locking Protokoll kannst Du nirgendwo konkurrente wWites sicher durchführen,  weil  Du  eben  keine  für  die  Domain  gültige  Serialisierung  von Ereignissen erzwingen kannst. Jedes Setup mit mehr als einem Writer ohne ein distributed locking protocol ist also kaputt. Lesen wir also die Anleitung zu mmm, MySQL Multi Master. Steht drin: schreiben nur in einem Knoten. Also: ein Ring, kein Multi­Master ­ der Name ist Betrug. Gucken  wir  irgendwo  sonst,  total  egal  wo:  ENTWEDER  Synchronisation  durch Locking ODER nur ein Master ODER kaputt. Das ist die Wahl. Die ganze Wahl. Es gibt keine weiteren Möglichkeiten. kv_> Wonka: Und wenn man die Leute fragt, warum die Master­Master oder circular replication  aufsetzen,  kommt  immer  die  falsche  Antwort:  "Ausfallsicherheit"  oder "Lastverteilung". Für Ausfallsicherheit nimmt man ein Shared Storage und baut sich eine  failover­Lösung  auf  OS­Ebene  drüber  ­  also  NetApp  oder  DRBD.  Und  für Lastverteilung beim Lesen nimmt man one­way Replication. Schreibverteilung kann MySQL nicht. Da fängt man dann an, auf Anwendungsebene Sharding­Architekturen zu bauen.
  3. 3. Isotopp> Exakt. Isotopp> Lalufu: So, jetzt zu MySQL und liefern. Isotopp> Lalufu: MySQL liefert ein Produkt mit mehreren Knoten und 2PC. Es heißt MySQL Cluster. Es verwendet nicht MYSQL Replikation um das zu tun. Isotopp> Und zu HA: MySQL 5.1, 5.5 und 5.6 haben verschiedene Inkremente von MySQL  SemiSynchronous  Replication  (SSR).  Damit  hat  man  EINEN  Master,  aber Slaves, die das Commit auf dem Master VERZOEGERN (den Master also langsamer machen), bis wenigstens ein Slave existiert, der denselben Stand hat wie der Master. Das kombiniert die Nachteile von 2PC (warten) mit den Nachteilen von Replikation, die da sind: In MySQL Replikation ist der Slave ja abhängig von der MySQL binlog position, die verwaltet jeder Knoten aber selber. Und das heißt, man kann den Slave 3, der an Master 1 hängt, nicht einfach an Slave 2 hängen, von dem wir wissen, daß er Dank SSR auf demselben Stand wie Master 1 ist. Das ist so, weil der Stand von Master 1 in binlog position (mname, mpos) ausgedrückt wird, derselbe Stand auf slave 2 aber (s2name, s2pos) ausgedrückt wird. Und es gibt keinen Übersetzungsmechanismus (man kann einen bauen, das tut dann unterschiedlich  weh,  je  nachdem  wie  korrekt  man  das  im  Falle  eines  Desasters haben will. Und wir reden über HA, man will es also korrekt haben). In  MySQL  5.6  gibt  es  dann  die  Global  Transaction  ID  (GTID)  und  einen Übersetzungsmechanismus (transparent, automatisch) von GTID in lokale Position. Mit SSR und GTID zusammen kann man dann in 5.6 auch endlich Replikation als HA Mechanismus verwenden und könnte einen Ring mit genau einem aktiven Master als HA­System  stabil  verwenden.  Das  heißt,  man  hat  immer  noch  Waits  wegen  der Synchronisation in SSR, aber keine Probleme mit dem Failover mehr. Wonka> MySQL Cluster ist aber nicht FOSS, oder? Isotopp> Wonka: MYSQL Cluster war früher FOSS. Was es jetzt ist, habe ich nicht nachgesehen, weil mich Cluster aus anderen Gründen nicht interessiert. Es  ist  strukturell  nicht  möglich,  normale  Anwendungen,  die  gegen  vanilla  MySQL performen, gegen Cluster laufen zu lassen und Performance zu erwarten. Cluster­ Software ist immer speziell gegen Cluster geschrieben. Aktueller Cluster ist inzwischen VIEL BESSER darin als der Cluster, den ich gekannt habe, aber es bleibt schwierig. Du suchst einfache Lösungen fuer distrubuted databases. So etwas existiert nicht. So etwas KANN nicht existieren ohne daß du an c drehst. Du willst also mit Q (aus Star Trek: The Next Generation) reden, oder Dir eine von Grace Hoppers Mikrosekunden um den Hals hängen. Lalufu>  Wuerden  Sie  diesem  Mann  Ihre  Replikation  anvertrauen? http://images5.fanpop.com/image/photos/25400000/Discord­dance­random­ 25482674­500­378.gif Geschrieben von Kristian Köhntopp in MySQL um 08:59 | Kommentare (14) | Trackbacks (0)
  4. 4. Trackbacks Trackback­URL für diesen Eintrag Keine Trackbacks Kommentare Ansicht der Kommentare: (Linear | Verschachtelt) Cluster ist nach wie vor Open Source, der wesentliche Unterschied zum "regulären" MySQL war das es unter MySQL AB und Sun Clustersupport nur zusammen mit kommerziellen Lizenzen zu kaufen gab während beim "regulären" MySQL auch die GPL­Packages supported wurden Wie Oracle das mittlerweile hält weiß ich allerdings auch nicht, es war zumindest mal im Gespräch Community­Binaries überhaupt nicht mehr zu supporten ... #1 hartmut am 15.03.2012 09:56 ACK. Mir brennt es auch schon eine Weile unter den Nägeln. #1.1 Ulf Wendel am 28.03.2012 19:56 Diese Diskussion spiegelt meine Diskussionen der letzten Monate wieder, denn das Thema landet immer wieder auf meinem Tisch. Und es greift sehr schoen die ganzen falschen Denkansaetze zum Clustering von Datenbanken auf. Danke. #2 Ralf Koch am 15.03.2012 10:08 Wie sieht denn die Sache mit Mysql Galera oder MySQL Tungsten aus ? Die werden hier gar nicht erwähnt ... #3 ekle (Link) am 15.03.2012 11:15 Cool 2 cool things learned or relearned(can't remember ;P) master­master and Grace Hopper http://www.net.t­labs.tu­berlin.de/~britta/Frauen/hopper.shtml #4 Sigi am 15.03.2012 11:18 Ich würde Master Master als Failover deutlich differenzierter sehen als hier dargestellt. Shared Storages haben ­ wenn ich nicht bereit bin, Beträge im oberen fünstelligen Bereich auszugeben ­ massive Performanzprobleme, wenn es degraded ist. Außerdem muß ich mir gleich zwei davon hinstellen, sonst habe ich wieder einen SPOF. Weiterhin gehen bei einem Komplettcrash auch InnoDBs mal kaputt und sind nur mit großer Mühe zu reparieren. Trotz Battery Backed RAID Controller habe ich im Power­Down­Fall schon komplett gefreckte Datenbanken gesehen. Geographisch verteiltes Storage mit 2PC kann man sich auch nur leisten, wenn man Bank oder Schwerindustrie ist. Also doch FS­Replikation? Lieber nicht! Dann lieber Master Master MySQL, hier reichen ein paar MBit für den Link zwischen den beiden getrennten Standorten, ich habe zwei vollständig lauffähige Instanzen meiner Datenbank und kann im Fehlerfall in kürzester Zeit schwenken. Idealerweise sind beim Standby­Master durch entsprechend künstlich erzeugte Read­Queries sogar schon ein paar Caches warmgelaufen und ich starte nicht einen Server jungfräulich auf einem Filesystem­Replikat.
  5. 5. #5 Sebastian (Link) am 15.03.2012 11:55 Verwende DRBD. Informiere Dich, wer Hastexo ist. Wir haben das längere Zeit überaus erfolgreich eingesetzt und ich habe das in meiner Zeit als MySQL Consultant auch bei diversen Kunden deployed. DRBD ist zuverlässig, schnell und unkompliziert, und im Standard Linux Kernel Deiner Distribution enthalten. #5.1 Kristian Köhntopp (Link) am 15.03.2012 12:48 Der DRDB selbst ist vielleicht schnell. Das herunterfahren (Wartungsarbeiten) eines Master­mysqlds durch pacemaker/heartbeat allerdings braucht seine Zeit, der Start leider auch. Ein Blackhole um das zu beschelunigen käme schon wegen der Auto­Increment­ Spalten nicht in Frage, fällt aber ferner flach weil replikationslagkritische Queries noch vom Master bedient werden müssten. Für Anregungen zur Lösung wäre ich sehr dankbar. :) Diesbezüglich auch ein dankeschön für den Hinweis auf Hastexo. #5.1.1 nugger am 15.03.2012 15:33 DRDB hilft einem genau dann nichts, wenn der Server im falschen Moment crashed. Wenn die Datenfiles durch einen Crash kaputt sind und die Reparatur länger als ein paar Minuten dauert, habe ich schon eine komplette Infrastruktur mit $Tool auf den Standby­Master geschwenkt. Wenn die Datenfiles durch einen Crash so kaputt sind, daß sie sich nicht mehr reparieren lassen, was ich auch schon gesehen habe, ist man mit einer reinen File­Replikation in einer extrem schlechte Situation. #5.1.2 Sebastian (Link) am 15.03.2012 15:56 Das haben sogar die Jungs von Hastexo erkannt: http://www.slideshare.net/hastexo/mysql­high­availability­sprint­launch­the­ pacemaker/38 #5.1.2.1 Sebastian (Link) am 16.03.2012 06:12 Informieren: Check! Installieren: Check! Testen: Check! Live­Betrieb: EPIC­FAIL! DRBD taugt in der Praxis nichts. Habe jetzt keine lust das aufzuführen, aber wer sich gerne eine blutige Nase holen möchte kann es ja gerne ausprobieren. #5.1.3 Parsimonius (Link) am 17.03.2012 07:10 Für Shared Storage braucht man keine 5stelligen Beträge ausgegeben. Man nehme Server, Betriebsystem deiner Wahl ( ich würde solaris nehmen) und baut soviele platte ein wie geht respektive nötig ist. Für Redundanz einen Zweiten. Das jeweilige SCSI­Targetframework nutzen und quasi die FC­Karte umdrehen wenns echtes SAN sein soll oder eben iSCSI, iSER, SRP oder FCoE respektive FCoIB nutzen. Der Server liefert dann auch genug Leistung für Dataservices wie Dedup,
  6. 6. Encryption, watweissich. Fähigkeiten natürlich abhängig vom eingesetzten OS und Filesystem. #5.2 Joerg M. (Link) am 18.03.2012 08:54 Mir fällt eine winzige Angewohnheit auf: "Cluster­Software ist immer speziell gegen Cluster geschrieben." Gegen. Der Normalmensch sagt "für". Mich freut sowas ja. #6 slowtiger (Link) am 15.03.2012 16:52 Also speziell bei Cluster muß es 'gegen' heißen. Bei 'für' könnte jemand auf die Idee kommen, daß Cluster irgendwie kooperativ ist. :­) #6.1 Kristian Köhntopp (Link) am 15.03.2012 18:38 Kommentar schreiben Name E­Mail Homepage Antwort zu Kommentar Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden. Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.  Hier die Zeichenfolge der Spamschutz­Grafik eintragen:  BBCode­Formatierung erlaubt   Daten merken?    

×