Es gibt keine Slides. Ich mache so ein bisschen das Interaktiv, ein bisschen was erzählen, was malen. Ich habe mal ein paar Gedächtnisstützen gemacht.

Was wir machen werden, ist natürlich, wir reden über Galera. Aber das, wir haben im Großen und Ganzen, warum Galera eigentlich jetzt für Maisgall die Lösung ist, wenn es um Hochverfügbarkeit geht. Und dann war es so ein Spaß, irgendwie mal ganz nett mit so einer Live-Aufführung zu machen.

Quasi mit LXC. Ich werde mir das zu LXC erzählen, aber genau genommen ist es ja nicht LXC an sich, sondern es sind quasi die Candle-Features, also Namespaces, CQs. Wir wollen damit extrem gut Betriebssysteme oder Applikationen metodisieren können. Also das mal kurz zeigen, wie ich damit quasi über Snapshots einen kleinen Cluster aufbaue. Und das Konfigurieren mache ich danach über Ansible.

Und ich glaube, spätestens bei Ansible schauen sie dann nochmal die Konfigurationsdatei ein bisschen an. Dann sehen sie noch ein bisschen, wie so eine Konfigurationsdatei aussieht. Aber jetzt ist so die Idee eigentlich, dass wir uns erstmal so ein großes Bild machen. Genau das hier oben bin ich, links oben. Ich mache Datenmanken, viel Containerzeug, ab und zu auch ein bisschen OpenStack und so.

Ich habe auch eine Webseite. Und das Schöne ist, das ist die richtige Webseite, um die es geht. Das ist meine hier. Und ich werde ein paar Sachen ansprechen. Da sind jetzt ein paar Block-Einträge drinnen zu Benchmarks mit Galera oder wie man Docker-Containern-Interface reinhaut.

Weil die haben es ja alle gar nicht. Das könnt ihr euch da noch irgendwie reinholen. Und so. Ich fange gleich an zu malen. Wenn man sich mit Hochverfügbarkeit beschäftigt, geht es da quasi so zwei Kategorien von Hochverfügbarkeit.

Das eine ist eben Hochverfügbarkeit des Services. Also ist der Service erreichbar. Und das andere ist eben Hochverfügbarkeit der Daten. Und klassischerweise hat man bei MySQL immer auf Replikationen zurückgreifen. Also die klassische Replikation ist sehr simpel. Wollte ich mal gucken, ob ich das hier schon hinter dem Stift...

Wo ist das hier? Ja, es klappt. Die Grundidee ist eigentlich, nennt sich auch asynchronous. Hier ist ein Master, der schreibt Datenänderungen in so einen Bill-Log rein.

Und ein Slave holt sich die Daten, schreibt sie in seinen Relay-Log rein und appliziert sie dann. Das ist die klassische Asynchronreplikation.

Das ist im Sinne von Datensicherheit, also Hochverfügbarkeit der Daten äußerst ungünstig. Weil im Prinzip das Schreiben der Daten des Jungtes von dem Lesen... Also der Master, der schreibt seine Daten in den Bill-Log. Das Bill-Log könnt ihr auch benutzen für so einen Point-in-Time-Recovery.

Wenn ihr Backup zieht, dann könnt ihr ja beim Backup quasi die Position im Bill-Log mit wegschreiben. Jetzt in den letzten Versionen von MariaDB und MySQL auf die Global Transaction ID. Das ist das selbe Prinzip. Es sagt aber nicht darüber aus, ob die Daten hier auch angekommen sind. Weil ich natürlich jetzt eine AA-Lösung aufbauen will.

Und ich möchte so gerne sichergehen, dass die Daten auch synchron sind. Es ist nicht gewährleistet, dass wenn hier der Knoten ausfällt, ich auch wirklich alle Daten habe. Zudem ist das eine Lösung, wo der Slave, also Master-Slave ist die Vernennung. Man darf nur Lesen drauf zugreifen. Das ist das, was Karriere auch besser machen wird.

Das ist eine Multi-Master-Lösung. Es ist ja egal, auf welchen Knoten man schreibt. Und das heißt natürlich auch, wenn ich dann so eine Lösung verfügbar machen will. Also ich habe jetzt bei der klassischen Replikation, bei der asynchronous Replikation das Problem, ich weiß nicht, ob alle Daten beim Slave sind.

Dann habe ich das Problem, wenn ich so einen Service verfügbar machen will, muss ich gucken, wie ich die Applikation umleite. Und bei AA-Lösungen, wo man so ein Rollenverständnis hat. Also wir haben hier eine Rolleneimer. Hier darf ich drauf lesen und schreiben. Hier darf ich nur lesen. Lohnen Sie sich so WIP-Lösungen. Besser ein Pacemaker, was ihr wollt.

Dann hat man eben eine WIP für die Applikation. Und wenn der ausfällt, muss ich eben rüber schwenken. Ist ein bisschen schwierig, weil wenn ich rüber schwenke, also die Pacemaker, die Resource Agents machen das nicht so schön, fand ich. Weil wenn ich rüber schwenke bei so einer Lösung, was mache ich? Dann lese ich sofort. Wenn ich sofort lese, habe ich wirklich alle Daten.

Ich bin nicht noch am Applizieren der Daten. Schwenke ich gerade rüber, weil meine Replikation, und jetzt ist meine Replikation gerade abgebrochen oder ist sie schon vor zwei Tagen abgebrochen und ich schwenke rüber auf einen alten Stand. Das sind alles Sachen, die man eigentlich abfangen muss. Wo man sich auch überlegen muss, wie man das lösen will. Das Schöne ist dabei, also das ist eine klassische Lösung.

Es gibt mehrere Replikationsmechanismen mittlerweile. Es gibt das sogenannte Semisync. Semisync ist quasi asynchron als Verarsche. Ist einfach so, weil bei der Asynchronreplikation, die funktioniert so, dass hier auf dem Node ein Commit ist fertig.

Die Daten sind in dem Rechner. Und dann wird quasi darauf gewartet, ob ein Slave in seinem Relay lockt. Das war das hier unten. Also wenn hier unten die Daten sind, heißt das nicht, dass sie im Server sind. Die werden ab dort erst appliziert. Semisync sagt dann nichts weiter als,

dass einen der Knoten die Daten hat. Es gibt auch ein Timeout, bin ich das? Kann gut sein. Das klingt plausibel. Der Wahrheitsbegriff ist aber ein bisschen komplizierter.

Wenn ich in ein Timeout reinkomme, dann switcher zurück zum Asynchron. Wer wirklich meint, semisynchrone Replikation nutzen zu müssen, um Datensicherheit zu gewährleisten, ist da auch auf dem Holzdampfer. Und da wiederholen sich auch die Probleme. Ab 5.7 gibt es eine lossless Replikation. Das funktioniert dann anders. Das heißt, dass mein Commit erst dann gemacht wird,

wenn ich das auf dem Slave habe. Aber es ist die 5.7. Das Schöne bei diesen Lösungen ist natürlich, die skalieren sehr schön. Und wenn ich eine WIP-Lösung habe und mich darauf einlasse zu sagen, ich kann Daten verlieren, dann ist ein Switch von so einer WIP, ich switche immer einen laufenden Knoten in einen,

die Daten sind heiß, die Daten sind heiß, hot. Das heißt, wenn ich jetzt hier meine WIP hätte und ich gehe hier rüber, muss ich nicht Angst haben, ob mein Knoten hochkommt, was mich direkt zu DRBD führt. Ich bin kein Fan von DRBD, aber DRBD ist ja so ein bisschen...

Steuerung Z ist rückgängig, ne? Ja. Wie gesagt, das ist für mich alles Neuland. Ich wähle auch wahrscheinlich bald hier CDU. Ja, geboren bin ich ja hier, ne?

Vielleicht habe ich dann selber gegeben nur Obama dann, ne? Bei Saarlösung oder DVD-Lösung ist ja quasi so, dass einer läuft, der andere nicht. Und das Problem, worauf man hier achten muss, ist, da man quasi den Shared Storage

als gemeinsame Datenhalter hat, hat man alle Schreibvorgänge wirklich zu persistieren. Also sei es so ein Sync Binlog, dass quasi die Binlog-Einträge immer schön geF-Synced werden, oder dass die Transaktion auch mit einem F-Sync beendet wird.

Das erhöht natürlich unheimlich mein I.O., so was reduziert. I.O. bei Datenbanken ist immer sehr unangenehm. Und nicht nur, dass damit die Performance sinkt. Selbst DRBD hat eine Replication Rate, wo ich jetzt wieder feststellen durfte, dass sie auch limitiert ist. Was passiert, wenn wir jetzt einen Failover haben? Also erst mal, wenn ihr einen Master und einen Remove macht,

ich meine, das wird auch repliziert. So ein DRBD-Device repliziert alles Mögliche, nicht nur die Daten, sondern auch meine Video Logs, alles drum dran. Wenn der jetzt runterfällt und der andere fährt hoch, dann wissen wir nicht wirklich, ob unsere Recovery klappt. Wir müssen erst ein Fallsystem mounten, wir müssen noch hochfahren.

Das Hochfahren geht mittlerweile schneller. Und dann müssen die Daten auch erst mal heiß werden. Auch dafür gibt es mittlerweile Flex, um ehrlich zu sein. Aber das ist so eine Lösung. Ich habe zwei Knoten, zwei Notes, ich kann nur einen nutzen. Und im Fall eines Failovers kann ich mir nicht sicher sein. Das ist eine Lösung für Sysadmins, nicht für DBAs. Weil mit DRBD kann ich alles hoch verfügbar machen,

wovon ich keine Ahnung habe. Das ist eigentlich eine sehr schöne Lösung. Es hat Vorteile. Also es kommt immer drauf an, hat man DBAs, die das können oder nicht. So, was ist wenn denn nun sowas? Also auch hier für die Lösung hätten wir so eine WIP. Was ist jetzt das Schöne an Galera? Ich glaube, F1 war das.

Zirk, zirk, haha. Also, mit Galera. Galera ist eigentlich eine Replikationslösung für InnoDB. InnoDB ist eh die Fault, deswegen ist es in Ordnung. Das Schöne an Galeras erst mal, ich muss mir keine Gedanken machen, in welchen Knoten ich schreibe, sei ich mir irgendeine Performance rausholen. Dann sollte man Hotspots vermeiden.

Für meine Hochverfügbarkeitslösung, also für den Service, wird es sehr einfach. Also Pacemak ist eine nette Lösung. Hier kann ich aber quasi, weil es egal ist, auf welchen Knoten ich schreibe, sowas in die Notbremse davorhauen. Man kann es mögen oder nicht.

Die Idee dahinter ist, wenn ich nicht wissen muss, ob ich quasi jetzt den Slave hochfahren kann oder nicht, ob er hinten dran hängt oder sonst wie, dann kann ich auch eine einfache Lösung nehmen, die einfach guckt, ist der Knoten da, kann ich darauf zugreifen, ja oder nein. Ist er nicht da, gehe ich woanders hin. Die Daten sind, weil sie eben synchron sind, entfallen unheimlich viele Probleme.

Das Schöne ist, was Galera auch noch liefert, also so nette Features, die man sonst noch von InnoDB Cluster kennt. Ich werde nichts zu InnoDB Cluster erzählen. Verdient zwar Geld damit, aber ganz ehrlich gesagt, das finde ich ziemlich an die Wand gefahren.

Ich mache keinen Bock, sowas zu debacken. Ich kapiere es eh nicht. Wer mich dafür einkauft, verliert Geld. Aber ich mache auch InnoDB Cluster. Ich finde es echt Zeitverschwendung. Aber wir sind im Kapitalismus. So schöne Features, was InnoDB Cluster kann,

nennt sich Rolling Restart, bedeutet, ich kann zur Laufzeit hingehen und kann die Knoten neu starten, kann neue Konfigurationen rausrollen. Vielleicht will ich neue RAM-Riegel reinhauen. Dann heißt das in dem Fall, dass ich hingehen kann und jeden Knoten nacheinander restarten. Der Service bleibt oben. Wenn ich oben drüber so einen Notblenden habe,

kann ich natürlich netterweise vorher den aus dem Notblenden herausnehmen, den langsam trocken machen. Das heißt, ich habe eine schöne hohe Verfügbarkeit. Woran man sich gewöhnen muss, auch eine Sache von DRBD. Wenn man mit Clustern arbeitet, ihr müsst quasi von den Knoten weggehen. Das Netz ist jetzt das Entscheidende.

Wenn so bei einer Lösung das Netz wegbricht, sind sie alle im Split-Brain. Das bedeutet, der Lehrer hat eine eigene HA-Lösung, eine Quorum-Lösung. Und solange quasi ein Knoten sich verabschiedet, und zwar, ne, solange sich ein Knoten verabschiedet, also so ein Meeting-Protokoll, kann man sich das vorstellen, und sagt Tschüss, ich gehe jetzt weg, ist alles in Ordnung.

Wenn ein Knoten, ohne Tschüss zu sagen, sich verabschiedet, dann wird man kalkuliert, wer ist denn jetzt, also ist noch alles in Ordnung, bin ich quasi noch im Quorum, bin ich in der Mehrheit, oder bin ich es nicht? Solange ich im Quorum bin, kann ich weiterarbeiten. Wenn nicht, fahre ich mich selber runter. Also, so eine eigene Lösung. Ist eigentlich auch ganz süß.

Aber das heißt natürlich, wenn ich meinen Netzwerkausfall habe, ist der Cluster unten. Das ist ein Nachteil zur as-und-grund-replikation. Denen ist das total wurscht, was mit dem Netz ist, weil die machen das für sich. Enslaved kann sich immer wieder reconnecten. Gut, da gibt es auch Limits, aber im Großen und Ganzen ist das nicht das Problem für die. Wenn man aber jetzt schaut, dass das Netz immer wichtiger ist,

muss man quasi auch überlegen, wo es die Performance-Engpässe gibt. Also, wir haben ein paar Sachen. Jede neue Transaktion, die geschrieben wird, wird quasi im Netz engagiert, dass sie auch über Synchron appliziert werden kann.

Ein großer Vorteil davon, von der Synchronität, ich gehe mal eins zurück, ist, warum ich das für Cloud-Umgebung mag. Wir haben ja vorhin bei DABD gehabt, dieses Synken. Wir müssen quasi jede Transaktion irgendwie in die Festplatte reinbrennen. Wenn ich nun eine Lösung habe, wo ich alle Daten synchron habe,

dann brauche ich das nicht mehr. Denn ob es der Knoten mir wegraucht, ist mir sowas wie ein Pille-Palle. Ich verliere keine Daten. Das heißt natürlich gerade in solchen wunderschönen Cloud-Umgebungen, wo man sich auf historisch beim besten Willen nicht verlassen sollte. Das ist so, finde ich, meine Erfahrung.

Das ist eine sehr nette Lösung, zudem Galera noch zwei nette Features anbietet. Das heißt, wenn ich neun Knoten dazunehme, das nenne ich SST, also State Snapshot Transfer, holt sich der neue Knoten automatisch alle Daten. Das heißt, das ist relativ simpel. Was ich ignoriert habe bei diesem Rolling Restart,

jeder Knoten hat einen lokalen Cache. Das heißt, wenn der Cache dann quasi gereicht hat für den Restart, werden nur die Deltas übertragen. Wenn man sich mal zur Terabyte-Datenbanken vorstellt, dann ist das natürlich ganz nett, wenn man nicht einen Full Sync macht.

Sachen, auf die man auf jeden Fall achten sollte, muss sich vorstellen, dass das eine Spot, also die Transaktionen, die geschrieben werden in ODB, das ist eine Voraussetzung, und es wird benutzt, das Interface for Row-Based Replication. Das heißt, die Rows, die geschrieben werden, haben dieses Row-Based-Format, kriegen noch einen Bummery Key dazu.

Das wird für die sogenannte Certification benutzt. Würde ich nicht überinterpretieren. Denk bei Certification immer nur an Bummery Key Check. Dann seid ihr auf der richtigen Seite, ist da nicht so irritierend. Und jetzt bin ich blind geworden, oder? Mal gucken, wie das funktioniert.

Aber ihr kriegt die ganzen Probleme. Also, Probleme bei Row-Based Replication gibt es einige. Das eine ist, eure Applikation braucht... Wer macht Row-Based Replication? Und... Herr Köhntopf, Sie machen... Also, ich dachte, Sie werden gewechselt.

Bummery Keys sind sau wichtig. Also, wenn ihr Row-Based Replication benutzt, und ihr kommt auf die dumme Idee, auf Tabellen viel zu schreiben, die ja noch groß sind, ohne Bummery Key, geht die Performance runter. Der Witz ist, dass Row-Based Replication, es gibt ein paar Optimierungen, aber, geht hin,

hat seinen Bummery Key und weiß genau, dort muss der neue Datensatz hin. Wenn der fehlt, wie jeder Eintrag hatten, ein Before- und After-Image, kam eigentlich vom NDB Cluster, aber wurscht. Dann nützt er in seinem Before-Image, also quasi, wie der Row davor aussah, macht einen Full-Table-Scan. Stellt euch mal vor, ihr habt auf dem Stage eine große Tabelle,

ihr müsst einen Full-Table-Scan machen, um zu gucken, passt die Row jetzt hier hin, um die neue hinzuschreiben. Das heißt, ihr müsst ein Bummery Key machen. In MariaDB, jetzt kann ich Werbung machen, ist ein Feature-Request von mir jetzt reingekommen, ab der 10.1, da geht es ein Fleck dafür, dass man das entforcen kann, dass nur Tabellen erstellt werden mit Bummery Key. Ist einer der Vorteile von MariaDB,

aber per Kohle hat er andere Vorteile. Aber nicht jetzt. Darauf müsst ihr achten, weil sonst geht die Performance absolut runter. Andere Sachen sind, das ist eine synchrone Lösung. Synchrone Lösung heißt, es gibt keinen Lack. Also wenn ihr auf die Idee kommt, zu sagen, ich mache noch einen weiteren Knoten rein,

der vor mir aus langsamer ist, weil mehr hilft mehr, habt euch quasi ins Knie geschossen, denn der langsamste Knoten gibt die Geschwindigkeit vor, weil es synchron ist, kennt Galera etwas, das nennt sich Flow Control. Heißt quasi hier, ich habe zu viel, stopp mal. Es gibt eine Statusvariable, die könnt ihr auch noch checken.

Das heißt, der Langsamste führt, das heißt, der Langsame sagt immer, wie schnell der ganze Cluster ist. Und es gibt gewisse Statements, ich habe es letzte Woche im Agentum anschauen dürfen, wir nutzen das. Zwei mutige. Ich werde dich wirklich dissen, nein. Doch.

Das Schöne, was Galera sehr schön hinkriegt ist, es holt sehr viel Performance raus. Man kriegt damit quasi asynchronous Performance raus. Der Witz ist folgender, die ganzen Rows, die Änderungen werden nacheinander weggeschrieben. Was dann Galera macht, es appliziert, nicht committed. Es kann das jüngte Rows parallel applizieren,

also gerade schon dahinschieben, wo es committed werden soll, um dann schnell hinein zu committen. Ich habe mal so Tests gemacht, das kann man auf der Homepage sehen. Damit kommt man an Geschwindigkeiten wie bei asynchronous Replikation. Es sei aber nutzt von MariaDB 10 die parallele Replikation. Also wenn ihr die nicht hättet,

kommt sie quasi in asynchronous Replikation heran. Mit dem großen Vorteil, die Daten sind synchron und nicht irgendwo im Relay Log, mit dem großen Vorteil, ihr könnt einfach switchen. Aber es gibt einige Statements, da geht das nicht. DDLs. Sobald ein Create Table macht, das wird alles serialisiert. Heißt, wenn eure Applikation

unheimlich viel serialisiert, wird das nacheinander im Netz ausgeführt und das bricht die Performance runter. Und bei Magento, was sie ganz gerne machen, gibt es irgendwelche Indextabellen und die machen immer Alter, Enable, Disable, Key und dann löschen, nie.

Sie truncate nie Tabelle. Und das saugt. Also wenn man Magento eins zu eins übernimmt und da ist Last drauf, wird es wahrscheinlich nicht funktionieren. Da hat es jetzt funktioniert. Da gibt es auch andere Sachen, die man sich anschauen muss. Aber auf sowas müsst ihr achten. Also es gibt zwar, es nennt sich Total Order Isolation, es gibt auch zwei andere Möglichkeiten, sowas durchzuführen.

Aber im Großen und Ganzen merkt euch, wenn eure Applikation viele DDLs hat, müsst ihr ein Auge drauf werfen. Ja. Da bin ich eigentlich, glaube ich, mit dem Galera fertig. Das andere wurde gesagt. Man kann sehr schön einen Proxy davor hauen. Was Galera auch noch liefert, ist eigentlich sehr schön.

Die haben versucht, mit GLB so einen eigenen Load Balancer zu schreiben, der ist relativ uninteressant. Aber sie haben mit lib-glb die Möglichkeit geschaffen, eine Applikation über ein Pre-Loading quasi auch eine Proxy-Möglichkeit zu liefern. Ja gerne. Wenn es nicht zu Puppet vs. Ansible ist,

also, okay, ich hole natürlich jetzt aus. Ist daran schuld. Ich gehöre zu Leuten, die H-Proxy nehmen und

ja, es utiliziert nicht mehr als eine Hura, als einen Chor, aber es ist verdammt schnell. Und man kann das gut kombinieren. Du kannst auch LVS nehmen. Du kannst eigentlich zwei Sachen kombinieren. Nimm, was du willst. E-Pille-Palle. Für H-Proxy gibst du dir die meiste Erfahrung einfach, wenn du oben schaust. Wenn du aber irgendwas

anderes gut kannst, nimm das. Was Galera hat, nennt sich VS-Rap-Notify-Command. Nur darauf würde ich mich verlassen. Denn alle Lösungen machen Check. Machen die nochmal. Das heißt, da gibt es eine Latenz. Und jede Änderung im Galera-Cluster wird protokolliert. Und du kannst dafür ein

Programm starten. Ist normalerweise 0 gesetzt. Das nennt sich VS-Rap-Notify-Command. Und das heißt, du kannst es dafür nutzen, wenn einer rauskommt. Dass er sich selbst, von mir aus die IP blockt oder sich rausnimmt. Oder zum H-Proxy-Connection aufbaut. Ab 1.5 soll das glaube ich gehen. Und sich rausnimmt.

Denn was ich natürlich jetzt vermieden habe, weil es eine Verkaufsveranstaltung ist, ist, je nachdem was für ein SST-Skript ich habe, ist der Doner blockiert oder nicht. Das in Kombination. Also VS-Rap-Notify-Command für eine schneller Reaktion. Und dann die klassischen Checks. Warum man sich nicht nur

auf den VS-Rap-Notify-Command alleine verlassen sollte, ist, ich habe schon mal gesehen, dass ein Galera-Cluster als ein Knoten, wenn er freest, freest er. Warum auch immer. Ja, gerne. Noch was zu Galera. Wir holen das ein paar Mal. Das sind auch die Konflikt-Datei.

Wenn ich will, hat schon. Zu spät. Puh.

Wie mache ich das? Wie will der Kunde das bezahlen? Kommt auf die Größe an. Für einen Full-Backup reicht ein schonmals Gelddump. Die Sache ist natürlich, wenn du die Build-Up-Position merkst, dann fließt es

mal ganz kurz, weil du machst einen Flashtable. GDL. Extra-Backup geht genauso. Du kannst noch darauf Rücksicht nehmen. Die Sache ist ja, wenn du einen Backup hast, das sehr viel Last erzeugt. Da sind wir wieder bei diesen... Ich klick mal noch mal dieses tolle Bild an.

Ich fange an, das zu lieben. Stell dir mal vor, du hast ein Backup-System. Es macht viel I.O. Ohne jetzt, ob das jetzt online ist. Das ist eigentlich total Pillepelle. Wenn jetzt sehr recht ein großer Last ist und er kommt nicht mehr nach mit dem Traffic, dann reduziert er ja Flow-Control, muss alles synchron sein, den ganzen Cluster.

Da kannst du mit WS-Rep, D-Sync, On, kannst du quasi einen Backup-Knoten nehmen. Eine gute Idee, aber wenn du sowas hast, setz den auf D-Sync, das heißt, er nimmt nicht mehr teil an diesem Flow-Control. Heißt natürlich dann auch, du kannst da ruhig ein bisschen mehr Last drauf machen, je nachdem, wie groß deine Systeme sind. Und du kannst es quasi selbst skripten oder du kannst mit GLB,

der GLB-D, auch als Möglichkeit Backup-Skripte zu starten. Kannst du es automatisieren, dann macht er das für dich. Dann kannst du quasi auf den Knoten Backup-Skripte starten. Der bringt einen D-Sync-Modus, macht D-Sync an, D-Sync aus und sorgt dann dafür. Kommt auf den Traffic an.

Wenn du jetzt relativ kleine Lösungen hast, will ich jetzt keinen Bein erbrechen und eine teure Lösung. Also nicht teuer im Sinne von arbeitsaufwendig überlegen. Das ist jetzt ein anderes Bild. Es gibt nämlich so einen Chain dafür. Was er macht, ist ja

in der Zukunft ist es ein anderes. Du meinst das wahrscheinlich, wenn ich das auf D-Sync setze. D-Sync heißt ja erst mal nur, er nimmt er weiter teil an der Kommunikation, er hat auch einen eigenen Cache, also einen anderen als den G-Cache, nur er sagt diesmal nicht, hört auf, ich komme nicht nach. Das ist das Einzige, was diese Option macht. Die Daten sind alle da.

Habe ich das gar nicht überlegt, lustigerweise. Er holt es ja so oder so nach. Das ist gar nicht die Sache. Er hört ja nicht auf zu applizieren. Ihr dürft euch D-Sync nicht vorstellen, er macht nichts mehr. D-Sync macht nichts weiter zu sagen,

ich sage nicht stopp. Das ist eine sehr blöde Variable in der Beziehung. nein, nein, nein, ja, doch, hast recht, hast recht, hast recht. Weiß ich jetzt keine genaue Antwort.

Bis jetzt habe ich jetzt nicht wirklich Gedanken drüber gemacht. Ob das jetzt so lange, ob man das sieht. Interessant, ne, muss ich mal nachschauen. Ja, muss ich mal checken. Kann ich jetzt nichts, also ich könnte irgendwas erzählen, das könnte nett klingen, aber es müsste deswegen nicht stimmen. Schaue ich lieber. Ist eine Idee für einen Blog-Eintrag.

Das sage ich ganz nett. Noch welche? Also ich muss immer die Slides wechseln, dass Fragen kommen. Was ich jetzt hier mache, ich wollte ja quasi, also ein Anliegen von mir ist, dass ihr ein bisschen Galera mögt natürlich.

Und dass ich ein Deployment sehe, was so halbwegs schön ist. Also ich habe, mein grosses Problem ist, dass es sehr viele How-To's gibt, die so ein Galera-Deployment machen, womit man mit diesen G-Com-Variaten rumspielen muss. Meine Erfahrung bei so Konfigurationsmanagement ist im Großen und Ganzen, man will gerne nicht in Konfig-Dateien

mehrmals rumspielen. Also es wäre schön, wenn alle Konfig-Dateien gleich sind. Und das geht auch mit Galera, auch wenn viele How-To's das nicht so machen. Und als Technik, die ich darüber natürlich auch ein bisschen propagieren will, um das hier vorzufinden, nehme ich LXC. In meinem Fall sind, LXC ist schwierig, weil der Begriff LXC, aber wir haben ja noch Logos.

Warte mal, das ist jetzt, hier ist LXC, das heißt, ich kann mit F1 das da rüber schieben. So. Und dann kann ich das größer machen. Hier, ich meine, jetzt lacht er, aber in 5 Jahren kann ich das total gut am Ende.

Ja, dann wäre ich echt heruntergekommen. Was ich habe, ist dieses LXC, das ist das, was ihr quasi Auto für Box bei Ubuntu findet. Im Großen und Ganzen,

Docker hat ja früher als Execution-Greifer LXC gehabt, das heißt, die haben auch LXC benutzt. Haben jetzt hier einen lib-Container. lib-virt hat auch ein LXC-Interface und Systemd nicht LXC, Namespace. Und Systemd nutzt auch Namespaces, meistens für Endspawn. Die Grundidee ist,

es ist eine Möglichkeit, Betriebssysteme oder Applikationen zu virtualisieren, und zwar mit den Fähigkeiten, die der LXC schon mitbringt. Es ist kein OpenVZ, kein V-Server, wo man das patchen muss, sondern der LXC an sich bringt schon eine Menge Features mit. Unter anderem, kann ich auch gleich etwas vorführen,

sogenannte Namespaces. Also, jeder Prozess ist in seinen Namespaces. Das kann man lesen, ne? Ja, hier habt ihr mehrere Namespaces. Das heißt, ihr könnt

eigentlich jeden Prozess nehmen, könnt ihn starten. Das ist einfach, es natürlich im eigenen Hostname zu geben, das ist junkt ist, das ist quasi nur, sobald er in den eigenen Namespace reinschreibt, also den Befehl gibt, macht er eine Kopie von dem Objekt, macht daraus ein eigenes Objekt. Und man kann so schöne Sachen machen, wie ich starte einen Prozess, und

der hat so ein eigenes Interface. Also, ihr könnt eigentlich eine Bash haben mit einem eigenes Interface. Und müsst ihr euch jetzt vorstellen, wie funktioniert so ein komischer Container? Ein Container ist eigentlich auch nicht so weit, als, ich mache einen Change slash Pivot Route, irgendwo rein, starte meinen Init dort. Diesen Init, deswegen ist es kein reiner Change Route,

schmeiße ich noch in Namespaces rein, eigener Pit Namespace, dass er quasi keine Signale schicken kann, eigener Mount Namespace, dass ich quasi innerhalb dieser Umgebung eigene Mounts machen kann, die nicht vom Rest gesehen werden, sie auch nicht überlagern. User habe ich jetzt hier nicht drin, User habe ich noch besser, das heißt, dieser Container fährt gar nicht mit Route-Rechten.

Und was weiß ich, ob es da noch so alles geht. Das heißt, im Prinzip ist das eine sehr einfache und billige Lösung, weil sie eigentlich gar nichts kostet. Und ob ich jetzt ein S-Bin-Init starte, also ein vollständiges Betriebssystem, oder ein Prozess, im Sinne von MySQL oder Engine X ist Pille-Palle. Also Docker hat quasi stark gemacht,

nur eine Applikation zu starten. Im Prinzip ist das nichts weiter als ich tausche schon mein S-Bin-Init gegen eine Applikation aus. Das ist jetzt nicht so wirklich die Welt. Und das heißt natürlich auch, der ganze Overhead ist viel geringer. Wenn ich so etwas wie KVM oder so etwas nehme, dann emuliere ich ja quasi Hardware, um eine Datenbank zu starten. Das ist eigentlich schon ein bisschen daneben.

Das heißt, man kriegt hier eine viel höhere Dichte hin. Und es ist auch im Großen und Ganzen viel schneller. Also alle Tools, die wir hier hatten, nutzen diese kernel namespaces. Das heißt, ihr kommt als Admins eh nicht drum herum. Ihr habt es ja schon die ganze Zeit. Ihr habt auch so etwas wie C Groups. Jeder

Prozess ist in deiner...oh, das ist natürlich blöd, weil ich habe hier System D auf Ubuntu laufen. Aber trotzdem wurscht. Hä? Wahrscheinlich bin ich irgendwo reingehauen.

So. Ah, nee. Jaja, die Gewohnheit. Ihr habt so was wie Memory Accounting, das ist gar nicht mal so wichtig, sondern ihr habt die Möglichkeit, Ressourcen zu bestimmen. Das heißt, ihr habt euren Prozess. Change root. Startet dort.

Und dann könnt ihr noch hinkriegen und sagen, welcher CPU er laufen soll. Wie viel Speicher er haben darf. Wie viel Speicherzeit im Sinne von Gewicht er kriegt. Das könnt ihr alles auch ohne Container benutzen. Das ist Allgemeinwissen. Es gibt noch Curabilities in der neuesten Version, die gestern herauskommt von Docker 1.2. Können Sie jetzt auch Curabilities setzen?

Das ist schön. Das heißt, damit kriegt man extrem schnell Container zusammen, die deswegen auch sehr schnell starten. Also eine Sache, mit der ihr euch auf jeden Fall beschäftigen müsst. Ich weiß, ich soll euch... Ich könnte euch was zum Pit Namespace vorführen, dass ihr quasi als Root, das habe ich nämlich heute Morgen mal getestet, so ein G-Wim nicht abschießen könnt, obwohl ihr Root seid, weil ihr im eigenen

Pit Namespace seid. Und der Pit Namespace hört ja auch oft falsch. Heißt nicht, dass ich den anderen Prozess nicht sehen kann. Er sagt erst mal nur, ich kann ihm keine Signale schicken. Das ist ein kleiner Unterschied. Das Sehen hat was mit dem Prozesssystem zu tun. Oh, wir haben keine Zeit. Entschuldigung, ich habe so viel geredet. Glaubt's mir.

Mein Fehler, mal wieder. Im Prozess, warum sieht das hier quasi so aus? Müsst ihr euch vorstellen, ich habe schon ein paar laufen. Start. Ihr habt ja eben LXD Start. Der Start ist sehr schön. Also das ist quasi ab LXD Start, ab dem Init, die Init Prozess.

Ich habe volle Container. Start das System. Und davon habe ich mehrere. Das stört mich gar nicht. Was ich jetzt hier machen will, ist folgendes. Ich habe LXD und SRV LXC.

Das ist ein Butterfess und weil ich den Snapshot Mechanismus nutzen will. Was wir jetzt hier machen, ist wir machen LXD clone, minus P. SRV LXC minus O. Als Vorlage nehmen wir Maria DB 10. Da habe ich so ein bisschen nachgebaut, dieses Dockerzeug. Man weiß ja, kann man dieses Images

und Container bei Docker so schön getrennt hier ein bisschen mit Tricks machen. Und ich nenne das mal Frostgon. Ich mache mal Frost01. Minus S für Snapshot.

Und das Schöne ist, wie nicht anders zu erwarten, gehen natürlich so Snapshots extrem schnell. Jetzt habe ich drei neue Container. Jetzt mache ich hier 4i in Frost01

0.2 0.3 LX start minus P SRV. Normalerweise ist es nicht die Container unter Valib LXC, aber wie gesagt, ich habe es nach Butterfess verschoben und ich wollte danach auch die Sachen wieder löschen. Minus N

minus D im Hintergrund. Sind sie alle gestartet. LXC LS minus PSRV LXC minus F minus Running Grab Frost.

Jetzt habe ich die drei Container. Ich habe es noch nicht konfiguriert. Was ich jetzt hier habe, weil ich so ein Image-System nutze, die Pakete sind schon längst installiert. Was ich hier haben will, das sind hier diese netten IP-Adressen. Denn, jetzt kommen wir zum Ansible.

Weswegen nehme ich Ansible. Puppet ist toll, alles drum dran. Aber ich bin ganz oft, wenn ich mit OpenStack oder sowas arbeite, wenn ich beim Kunden bin, dann habe ich eine SSH-Infrastruktur. Und Ansible kann ich mir eine SSH-Infrastruktur extrem gut aus- einfach nur gut benutzen. Ich muss nicht irgendwie groß irgendwas signen. Ich kann quasi Grunge, ich habe weiter verwenden. Das ist mein Grund, warum ich das

ganz oft bei Kunden benutze, weil bevor ich mich da irgendwie noch ein M-Collective nehme, dann ist es meistens nicht da. Und Ansible bietet mir so eine Art von Orchestrierung quasi aus der Box. Nicht besser, nicht schlechter. Dazu will ich gar nicht sagen. Was interessant ist hier nur, wir machen mal, wir kopieren mal. Frost-Inny.

Ich habe ja quasi sowas wie mein Dictionary oder mein Inventory. Und was ich hier brauche, ist 223, 220, 87.

So. Machen wir es mal so. PS1 gleich. So. Das ist eigentlich auch nicht schön. Ja, doch, ist doch besser. Was ich jetzt mache, ich muss das leider, sorry,

ich bin ein Schwätzer. Weil du gefragt hast, ne? Die Grunde ist eigentlich relativ plump. Man kann Ansible kompliziert machen, mit Rolls, allem drum und dran. Aber das Schöne bei Ansible ist, wenn man das wie so ein Vollidiot macht, man hat ja quasi

kleine Anweisungen, was man machen muss. Und eine Anweisung ist hier zum Beispiel Let's Playbook MariaDB10 Jaml. Und für die Gruppe Tasks, ich hab quasi meine Edit-Datei, hab ich gerade drei Rechner reingeschrieben, die haben Label für die Skaläre gekriegt. Das heißt,

für die Skaläre wird das ausgeführt. Was hier eigentlich nichts weiter gemacht wird, ist, dass MariaDB-Repository wird reingehauen und ich installiere ein paar Pakete. Und danach möchte ich, dass es gestoppt ist. Warum? Welchen Cluster initial aufsetzt, ist ganz wichtig. Im Prinzip ist es so, der erste Knoten, der startet,

ist ein sogenannter Leader. Das heißt, ihr müsst euch das vorstellen wie so ein Roundtisch. Also man trifft sich zum Meeting und der erste sagt immer, ich eröffne quasi das Treffen. Wenn das erledigt wurde, mach ich es mal. Ansible Playbook –e

Froscon Playbook Galera mach ich das hier. Also ich möchte dann quasi die Konfiguration ausrollen. Was ich hier also brauche ist, ich gehe auf allen Knoten hin, die kriegen das selbe Konfigurationsdatei. Die Sache ist nur, wenn ich das jetzt so ausführen würde,

müsste eigentlich eine Fehlermeldung von sich geben, weil das Playbook will – also GCOM nennt sich Group Communication. Das heißt, ich muss mir eigentlich übergeben, wo sind meine Partner. So das müsste ich quasi für jede Umgebung das fest codieren. Und ich hab das Fax rausnehmen sollen.

Egal. Bevor ich hier Artikel, MySQL Frosch, oh, ist was anderes.

So. Also was ihr habt, ist eine Galera-Konfiguration. Ist relativ simpel. Ich überschreib quasi die MyConfig-Datei. Und ich sorg dafür, die haben so komische Ideen, ist ein Debian-Konfig. Die muss ich überall noch synchron machen.

Das ist nichts weiter als quasi Templates kopieren. Das Entscheidende ist das Template. Und zwar ist das Template so aufgebaut. Da kann man ein paar Sachen setzen. Also es gibt Defaults.

Hier seht ihr zum Beispiel, Flush AdPresictionCommit. Ich hasse bei mir bei Default auf zwei. Der eigentliche Default ist eins. Das würde heißen, jeder Commit muss geäffsyncht werden. Ich hab Galera laufen. Ich brauch das nicht. Ich kann quasi diesen Stress von dem O-System runternehmen. Warum er meckert, ist die G-Comm.

Also hier kommt dann Galera. Können wir auch schnell durchgehen. Das erste ist quasi der Provider. Da steht mandatory. Ich hab nur ein Konfig-Datei. Das ist fest eingetragen. Gut, ClusterName hab ich. Ich weiß nicht, wenn die Ben kennt. DeadCandance. Ich kann es aber auch überschreiben.

Das Entscheidende ist bei ClusterAdress. Das hab ich nirgends wo konfiguriert. Das ist die G-Comm Variable. Die muss ich eben angeben. Und weil sie nicht angegeben ist, sagt er hier, es ist nicht defined. Das heißt, was ich jetzt hier mach, ich geh nochmal hin und sag ihm G-Comm.

So. Kann man besser machen, aber ich find das ist eben so schön zu sehen. Was wir dann haben, da haben wir erstmal nur die Konfiguration verteilt. Und jetzt kommt der ganze Witz.

Wenn ich jetzt den Cluster starte und ich hab überall dieselbe Konfiguration. Ich weiß, ich hab schon mal versucht, Galere zu installieren. Hat mit diesem G-Comm rumgespielt. Wer von euch hat da G-Comm leer gesetzt zum Hochfahren? Warum erzähl ich das dann, wenn es jemand macht? Weil normalerweise geht man hin, der Witz war früher so, wenn man G-Comm leer macht, dann sieht er,

ich hab keinen Kommunikationspartner, also muss ich der Erste sein. Und starte damit die Kommunikation. Jetzt ist es eben so, dass man dem ersten Knoten da hochfährt, die Option WS-Rap-New-Cluster mitgeben kann. Das heißt, der weiß, egal was in Konfiguration steht, ich bin der Erste, der die Kommunikation startet. Das ist also der ganze

Trick. Das kann jetzt hier ruhig, ich hätte das wieder rausnehmen sollen, das ist mein Fakt, sorry. Das heißt, kann man alles schon überschreiben. Das war nämlich der Grund, warum ich hier bei einem das kann man auch auf der Kommandozeile geben, aber man kann auch in dieser Indie-Datei

Variablen definieren, denn darauf graue ich dann zurück. Wenn ich nämlich dann wieder in die Playbooks gehe, ich sollte das andere hier nehmen, gibt es eigentlich zwei Sachen, die ich aufrufe, kann man auch kapseln, aber die ich aufrufe zum Starten. Das eine ist der sogenannte

Initial Start. Und was der macht, das erste ist ein Sicherheitsding. Die sollten eh unten sein, das wird eine Fehlermeldung geben. Er sagt, wie sehr Liedert die Feind ist. Also, ich starte auf die ganze Gruppe, aber nur einen Knoten davon hat es definiert und dann fährt er den hoch mit diesem Argument.

Das brauche ich nicht mehr, die Konfiguration ist draußen.

Hab ich das falsch gemacht? Bin ich schon? Danke. Siehst du, das war die richtige Antwort.

Leerzeichen zu viel. Oh. Scheiß ihm was Neues einfallen lassen.

Technik. Was machst du heute Abend? Du machst es nicht mehr. Und das zweite ist der Rest.

Was der macht, nennt sich Serial One. Das Wichtigste, ich starte nach jeden Knoten einzeln, weil ich dann nicht zweimal ein SST machen kann. Und da check ich nur, wo der Lied angefallen ist, die man dann hochgefahren. Das selbe Prinzip nutze ich auch für einen Rolling Restart. Das heißt,

bei so einem Restart ist es total simpel. Der Witz ist ja von Galera, ich kann eine Konfigurationsänderung ausrollen. Ich mache nichts mit Händler, nichts mit Notify, weil das ist ein Galera Cluster, nicht so automatisieren. Aber wenn ich eine Konfig Änderung mache, dann kann man das aufrufen, was er macht, er geht einen Knoten nach dem nächsten durch

und restartet das und dann den Knoten einfach. Und das ist eigentlich total süß. Und das Schöne jetzt bei LXC ist, wir können das mal gleich checken, also LXC LS minus PSRV LXC Running

minus F. Das LXC Attach, das ist auch eines der schönen Sachen von Containern. Da läuft ein SSH, die drauf muss laufen, sonst hätte ich nicht an so viel arbeiten können. Aber wenn ich in Namespace reinspringen, das ist natürlich zum Atmustrieren der absolute Hammer.

Also ob es bei einem SSH-Team läuft oder nicht, ist mir wurscht. Wenn ich ein Problem mit dem Container habe, es gibt eine Zielgruppe, nennt sich auf Freeze, da kann ich aber die ganzen Prozesse an die Prozessgruppe schicken und dann bleibt er stehen. Und ich kann natürlich auch, auch wenn ich keine Credentials habe, weil ich ja nur in Namespace hineinspringe,

minus P SRV LXC minus N FROS 01 Jetzt bin ich in FROS 01 drin. Also ich bin jetzt quasi in dem Container. ha, da hat jemand kein Passwort für root. So was soll es geben.

Show Status So und hier haben wir einen Fehler. Hier müssen nämlich eigentlich drei stehen. Was heißt? Ach, natürlich. Da bin ich ja ganz froh, dass ich gerade auf den richtigen gehypt

wo der läuft. Jetzt muss ich erst den Rest starten. So, nicht klatschen drüben, sonst habe ich das Gefühl, ich bin zu langsam.

So. Klubbel. Was habe ich da falsch gemacht? Status. Wieso verbessert mich keiner, wenn ich es brauche?

Oh, das ist noch ein Facts Gathering. Okay, das ist auch eine der Folgen. Frag mich jetzt mal fragen, dass das Ding oben ist. Los, los, Fragen stellen.

Kommt, wir haben noch ein paar Sekunden. Soll ich mir welche überlegen? Könnt ihr auch zu Galera machen?

Okay, das ist in Ordnung. Nein, das habe ich euch vorhin erzählt. Das war diese Sicherheitscheck, wo ich aber ein Kill All schicke.

Also wo ich aber sichergehen will, dass der Knoten unten ist, warum auch immer. Deswegen ist das jetzt keine große Überraschung. Jetzt bin ich fertig. Klasse 1 ist 3. Das ist das Schöne bei Anseville.

Ab und zu nimmt man seine Shell-Logik, schmeißt sie rein und sagt, wenn es einen Fehler gibt, ist es okay. Ich bin nur sicher, dass es gemacht wird. Genau das habe ich hier gerade benutzt. Oh, der Erke hat das falsch gemacht. Nein. Dödel. Das gleiche ist auch auf Restart machen. Wie gesagt, das Schöne dabei ist,

warum ich das so gerne habe, ist, ich kann natürlich, wenn ich jetzt die ganzen Dateien drinne habe, in dieser Indie drinne, bei Anseville, kann ich auch alles andere machen. Ich kann den Status der Replikation, ich habe so ein Projekt, die tausend Umgebungen haben, und das habe ich in der Indie-Datei drinne, und wenn ich dann wissen will, ob die Slaves noch laufen, weil ich den Monitoren nicht glaube,

dann ist das ein Kommando. Und ohne, dass ich mit irgendeinem netten anderen Seite irgendwas absprechen muss, dass es in sein Puppet integriert, habe ich keine Lust drauf. Dafür bin ich zu kurz im Projekt, um das zu machen, habe ich hier meine Ruhe. Wie gesagt, das Schöne an LXC ist, natürlich ist es blöd, drei Container auf einem Host zu haben. Das ist jetzt hier nur zum Vorfüllen.

Aber wenn er quasi die Idee nimmt, eigentlich von Docker, die haben es ja mit einem AFS vorgemacht, dass man quasi mit so einem Unify-System oder sonst wie auf Snapshots arbeiten kann, hab es auf drei Knoten, dann kann man eigentlich relativ viele Kunden mit so einem mit relativ wenig Platzverbrauch. Weil ja quasi nur die Deltas

zusätzlich im Platzverbrauch geben. Punkt. So, Fragen. Danach ist erstmal der Köhntop, das dauert aber noch. Du bist der Einzige. Noch jemand.

Nochmal. Nochmal, nochmal, nochmal. Die Galeere-Klasse ist bei default

synchron und da ist nichts eingebaut, dass ich eine abschieße. Was du gerne machen kannst, beim Status gibt es ja quasi Flow Control Send und Flow Control Received. Das heißt, du kannst eigentlich pro Knoten nachschauen, wer ist denn der, der gerade Ärger macht. Weil du willst, kannst du echt eine Logik dahinter bauen. Das selbst abschießen. Wenn du meinst, dass das richtig ist. Natürlich sinnvoll, wenn du

ein Backup machst und du jedes Mal nach zwei Monaten merkst, das brauchst du ein Backup und du sagst, aber hier ist immer dein Backup-System abgeschossen, weil das irgendwie... Aber wie gesagt, das ist deine Entscheidung.

Verstehen musst du es trotzdem. Ja, super. Noch was? Also nochmal ganz kurz. Der Herr stellt immer die gemeinen Fragen.

Ich finde, ich nutze Galeere auch schon als reinen Replikationsersatz, weil es einfach unheimlich praktisch ist. Ich kriege eine asynchronous Geschwindigkeit hin. Und habe aber die Daten die ganze Zeit. Also ich muss mir keine blöden Gedanken machen, ob ich was verloren habe. Du kannst immer tricksen.

Man kann alles lösen. Du kannst Gewichte verteilen und du kannst das Quorum ignorieren. Das heißt, wenn du eine Pacemaker-Lösung hast, der dir vertraust, dann kannst du das auch wieder lösen. Das ist alles konfigurierbar, aber es ist ja nur eine Werbeveranstaltung und kein Ihr könnt es jetzt selber. Nee, natürlich nicht. Wo sind denn hier Leute, die wissen, was sie tun? Nein.

Sorry. Nee, sag doch. Von wem? Ach so. Schade. Hätte ich die Frage nicht beantworten können. Wir haben, bis jemand reinkommt, noch 10 Minuten.

Nee, es ist eine Mittagspause. Wir haben echt Zeit. Ich kann sagen, wir aufstehen und gehen. Das ist auch kein Problem. Doch, aber es ist okay. Na dann. Tschüss.