grundsätze verteilter datenbanken
TRANSCRIPT
Grundsätze verteilterDatenbanken
Die wunderbare Welt von Isotopp
Donnerstag, 15. März 2012Grundsätze verteilter DatenbankenWonka> Die http://www.toppoint.de z.B. wird vermutlich nie was haben, was innennenswerte LastRegionen kommt, aber ich will akademisches Interesse und so schon wissen, wie man das da am besten täte. Was mich auch für die Toppointinteressiert: irgendeine Sorte Redundant Array of Inexpensive Databases :)
Lalufu> MySQL mit Replication? Alternativ mit DRBD?
Isotopp> Mit DRBD. Nicht mit Replikation.
Wonka> Lalufu: Hm, MasterMasterReplication geht ja nur mit Zweien. Wenn mannun mehr als das haben will, kann man zwar Ringe bauen, aber nur einfachverkettete.
Isotopp> Wonka: Argh! MasterMaster 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 master2? Wenn man mal annimmt, dass MySQL auto_increment_increment undauto_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'). Soweit funktioniert das.
kv_> Bei UPDATE sieht's anders aus.
Isotopp> Jetzt macht aber Thread 1 auf Master 1 ein UPDATE. Und zwar update tset 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 Ringesgültige Serialisierung von Ereignissen gibt, es also keine globale Festlegung der
Reihenfolge von Ereignissen gibt. Sondern jeder lokale Knoten hat seine eigeneReihenfolge von Ereignissen. Im Klartext heißt das, daß auf Master 1 dieReihenfolge der Events een, one sein kann, auf Master 2 aber one, een oderumgekehrt.
Lalufu> Genaugenommen ist das Problem, daß Leute sowas gerne hätten, aberMySQL das nicht liefern kann.
Isotopp> Lalufu: Nein, die Situation ist weitaus komplizierter. Laß mich zu Endeerklären.
Wonka> http://www.howtoforge.com/mysql_master_master_replication "Thistutorial describes how to set up MySQL mastermaster replication. We need toreplicate MySQL servers to achieve highavailability (HA). In my case I need twomasters 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 Universumkann man nicht bescheißen.
Isotopp> Wonka: Du willst also eine solche Serialisierung erzwingen.In sql erzwingtman eine bestimmte Reihenfolge von Ereignissen, indem man für die Domain, in derman arbeitet eine Sperre (englisch: lock) setzt. Man braucht also ein Locking, das inder ganzen Domain gilt.
Isotopp> Die Domain ist nun aber nicht mehr eine Kiste, dafür hat Dein SQL Serverja Locks,sondern der Ring. Und MySQL Replikation hat spezifisch kein LockingProtokoll. Es gibt solche Protokolle, 2PC, 3PC, Paxos und noch ein paar mehr. 2PCist 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 sicherdurchführen, weil Du eben keine für die Domain gültige Serialisierung vonEreignissen erzwingen kannst.
Jedes Setup mit mehr als einem Writer ohne ein distributed locking protocol ist alsokaputt.
Lesen wir also die Anleitung zu mmm, MySQL Multi Master. Steht drin: schreiben nurin einem Knoten. Also: ein Ring, kein MultiMaster der Name ist Betrug.
Gucken wir irgendwo sonst, total egal wo: ENTWEDER Synchronisation durchLocking 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 MasterMaster oder circularreplication aufsetzen, kommt immer die falsche Antwort: "Ausfallsicherheit" oder"Lastverteilung". Für Ausfallsicherheit nimmt man ein Shared Storage und baut sicheine failoverLösung auf OSEbene drüber also NetApp oder DRBD. Und fürLastverteilung beim Lesen nimmt man oneway Replication. Schreibverteilung kannMySQL nicht. Da fängt man dann an, auf Anwendungsebene ShardingArchitekturenzu bauen.
Isotopp> Exakt.
Isotopp> Lalufu: So, jetzt zu MySQL und liefern.Isotopp> Lalufu: MySQL liefert ein Produkt mit mehreren Knoten und 2PC. Es heißtMySQL 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 vonMySQL SemiSynchronous Replication (SSR). Damit hat man EINEN Master, aberSlaves, die das Commit auf dem Master VERZOEGERN (den Master also langsamermachen), 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, dieverwaltet jeder Knoten aber selber. Und das heißt, man kann den Slave 3, der anMaster 1 hängt, nicht einfach an Slave 2 hängen, von dem wir wissen, daß er DankSSR auf demselben Stand wie Master 1 ist. Das ist so, weil der Stand von Master 1in 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 dannunterschiedlich weh, je nachdem wie korrekt man das im Falle eines Desastershaben 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 HAMechanismus verwenden und könnte einen Ring mit genau einem aktiven Master alsHASystem stabil verwenden. Das heißt, man hat immer noch Waits wegen derSynchronisation 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 nichtnachgesehen, weil mich Cluster aus anderen Gründen nicht interessiert.
Es ist strukturell nicht möglich, normale Anwendungen, die gegen vanilla MySQLperformen, gegen Cluster laufen zu lassen und Performance zu erwarten. ClusterSoftware ist immer speziell gegen Cluster geschrieben.
Aktueller Cluster ist inzwischen VIEL BESSER darin als der Cluster, den ich gekannthabe, 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 vonGrace Hoppers Mikrosekunden um den Hals hängen.
Lalufu> Wuerden Sie diesem Mann Ihre Replikation anvertrauen?http://images5.fanpop.com/image/photos/25400000/Discorddancerandom25482674500378.gifGeschrieben von Kristian Köhntopp in MySQL um 08:59 | Kommentare (14) | Trackbacks (0)
TrackbacksTrackbackURL für diesen Eintrag
Keine Trackbacks
KommentareAnsicht 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 mitkommerziellen Lizenzen zu kaufen gab während beim "regulären" MySQL auch dieGPLPackages supported wurden
Wie Oracle das mittlerweile hält weiß ich allerdings auch nicht, es war zumindest malim Gespräch CommunityBinaries ü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 dasThema landet immer wieder auf meinem Tisch. Und es greift sehr schoen die ganzenfalschen Denkansaetze zum Clustering von Datenbanken auf. Danke.#2 Ralf Koch am 15.03.2012 10:08
Wie sieht denn die Sache mitMysql 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)
mastermaster and Grace Hopper
http://www.net.tlabs.tuberlin.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ünstelligenBereich auszugeben massive Performanzprobleme, wenn es degraded ist.Außerdem muß ich mir gleich zwei davon hinstellen, sonst habe ich wieder einenSPOF. Weiterhin gehen bei einem Komplettcrash auch InnoDBs mal kaputt und sindnur mit großer Mühe zu reparieren. Trotz Battery Backed RAID Controller habe ich imPowerDownFall schon komplett gefreckte Datenbanken gesehen.
Geographisch verteiltes Storage mit 2PC kann man sich auch nur leisten, wenn manBank oder Schwerindustrie ist. Also doch FSReplikation? Lieber nicht!
Dann lieber Master Master MySQL, hier reichen ein paar MBit für den Link zwischenden beiden getrennten Standorten, ich habe zwei vollständig lauffähige Instanzenmeiner Datenbank und kann im Fehlerfall in kürzester Zeit schwenken. Idealerweisesind beim StandbyMaster durch entsprechend künstlich erzeugte ReadQueries sogarschon ein paar Caches warmgelaufen und ich starte nicht einen Server jungfräulichauf einem FilesystemReplikat.
#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 Mastermysqlds durch pacemaker/heartbeat allerdings braucht seine Zeit,
der Start leider auch.
Ein Blackhole um das zu beschelunigen käme schon wegen der AutoIncrement
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 StandbyMaster 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
FileReplikation 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/mysqlhighavailabilitysprintlaunchthe
pacemaker/38
#5.1.2.1 Sebastian (Link) am 16.03.2012 06:12
Informieren: Check!
Installieren: Check!
Testen: Check!
LiveBetrieb: EPICFAIL!
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 SCSITargetframework nutzen und quasi die FCKarte 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,
Encryption, watweissich. Fähigkeiten natürlich abhängig vom eingesetzten OS undFilesystem.#5.2 Joerg M. (Link) am 18.03.2012 08:54
Mir fällt eine winzige Angewohnheit auf:"ClusterSoftware 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 Ideekommen, daß Cluster irgendwie kooperativ ist. :)#6.1 Kristian Köhntopp (Link) am 15.03.2012 18:38
Kommentar schreibenName
EMail
Homepage
Antwort zu
Kommentar
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kannein Wort unterstrichen werden.
Um maschinelle und automatische Übertragung von Spamkommentarenzu verhindern, bitte die Zeichenfolge im dargestellten Bild in derEingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegebenwurde, kann der Kommentar angenommen werden. Bitte beachten Sie,dass Ihr Browser Cookies unterstützen muss, um dieses Verfahrenanzuwenden.
Hier die Zeichenfolge der SpamschutzGrafik eintragen:
BBCodeFormatierung erlaubt Daten merken?