MySQL: Warum einen Cluster aufbauen wenn ich auch Replizieren kann?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 49 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/51777 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Point cloudMySQLOracle <Marke>MySQLSet (mathematics)Computer animation
00:53
Oracle <Marke>RankingIBMMono-FrameworkMySQLUnicodeData modelRouter (computing)Gastropod shellACCESS <Programm>RoutingRepetitionScripting languageSQLDistanceMySQLWeb serviceDatabaseFunktionalitätProxy serverTwitterGooglePlug-in (computing)Component-based software engineeringDatabaseRouter (computing)Stack (abstract data type)Field extensionGastropod shellRankingPhysical quantityVaporInstanz <Informatik>Buffer overflowORACLSFRAMEWORK <Programm>BlogHigh availabilityServer (computing)System administratorERNA <Programm>HöheScaling (geometry)ALT <Programm>WAMP <Programmpaket>SupremumHIT <Programm>LINUXData dictionaryFacebookAbsolute valueInternetRALLY <Programm>Communications protocolSocial classValue-added networkComputer animation
10:44
Scripting languageSQLMySQLGastropod shellRouter (computing)Plug-in (computing)MongoDBFunctional (mathematics)IndexREASTransport Layer SecurityMultiplicationHash functionOracle <Marke>Source codeComponent-based software engineeringRoute of administrationMySQLIndexSet (mathematics)FunktionalitätAbstract machineAtomic numberServer (computing)Reading (process)LengthSource codeAlgorithmWordPressGastropod shellBackupKompressionFactorizationCluster analysisVaporHard disk driveComputer fileInternetInformationSet (mathematics)BefehlsprozessorUpdateDatabase transactionVersion <Informatik>Systems <München>LogarithmTwitterCompact CassetteWeb serviceFacebookMoment (mathematics)MS-DOSBindung <Stochastik>CloningBound stateGoogleVollständige HalbordnungRALLY <Programm>Finite impulse responseTime zoneStatement (computer science)Film editingVideo trackingGenerating functionEnterprise architectureLimitierungsverfahrenThomas Bayes
20:36
Router (computing)MySQLGastropod shellOperational amplifierEASY <Programm>BackupmakeOracle <Marke>Complexity <Algorithm>Server (computing)Component-based software engineeringConfiguration spaceGreatest elementMultiplicationSingle-precision floating-point formatMySQLRouter (computing)Point (geometry)Scripting languageGastropod shellServer (computing)Systems <München>Instanz <Informatik>Statement (computer science)Set (mathematics)BackupCore dumpSource codeUnity <Benutzeroberfläche>PasswordInformationAbstract machineComponent-based software engineeringCASA <Programm>CalculationPublic key certificateCrash (computing)SoliDTime zoneLarge eddy simulationRoundingMetadataTransmitterSocial classVelocityMoment (mathematics)Professional network serviceStrich <Typographie>Computer animation
30:27
Router (computing)MySQLConfiguration spaceGastropod shellOracle <Marke>Particle detectorData recoveryACCESS <Programm>Crash (computing)Database transactionGreatest elementMySQLGastropod shellSystems <München>Source codeRAW-FormatComponent-based software engineeringMoment (mathematics)Router (computing)Online chatServer (computing)UpdateHigh availabilityJames <Programm>ClefCache (computing)Table (information)LimitierungsverfahrenCrash (computing)Content management systemAtomic numberCASHESage <Programm>Eigenvalues and eigenvectorsDemosceneComputer hardwareALT <Programm>ReliefSet (mathematics)SOKRATES <Bibliotheksinformationssystem>CloningProfessional network serviceRollbewegungArray data structureDecision theoryPhysical quantityNoten <Programm>Virtual memoryComputer animation
40:18
Oracle <Marke>Set (mathematics)Disk read-and-write headServer (computing)Systems <München>Moment (mathematics)Version <Informatik>Router (computing)Database transactionDemosceneDefault (computer science)MetadataGastropod shellMySQLPasswordInformationLogarithmReading (process)Structural loadUpdateBlogSwitch <Kommunikationstechnik>Social classWiener filterRoute of administrationHIT <Programm>Block (periodic table)Data modelLINUXBootingScripting languageConstructor (object-oriented programming)Local ringCluster ServerMobile appComputer animationLecture/Conference
50:08
Set (mathematics)UpdatePartition (number theory)Sun <Marke>JDBCMySQLService (economics)Gastropod shellKonnektorStructural loadOnline chatSystems <München>High availabilityInformationMySQLUpdateData recoveryVelocityQuery languageGreatest elementServer (computing)Router (computing)Propositional formulaWeb serviceSupremumDatabaseLogarithmMoment (mathematics)Abstract machineLevel (video gaming)FunktionalitätSocial classDivision (mathematics)InferenceHöheComponent-based software engineeringRoute of administrationDNSSECContext awarenessDefault (computer science)Computer hardwareComputer animation
59:54
Point cloudJSONXMLUML
Transcript: German(auto-generated)
00:06
Mein Name ist Karsten, Karsten Thalheimer. Der eine oder andere kennt mich vielleicht auch schon von den frühen Froskons. Ich war eigentlich immer der, der am Stand gewesen ist oder halt einen Vortrag gehalten hat. Heute geht es um MySQL Cluster. Ich hatte einen ähnlichen Vortrag vor einigen Jahren schon mal gehalten.
00:25
Vielleicht hat den ein oder anderen schon gesehen. Da hat sich mittlerweile eine ganze Menge getan und genau darum reden wir. Wir werden vor allen Dingen so ein bisschen unterscheiden. Die MySQL Replikation ist immer noch mehr oder weniger verwendet. Wo sind da die Unterschiede? Also wann mache ich das eine, wann mache ich das andere?
00:43
Das wäre so ein bisschen mein Ziel für den Vortrag, dass ihr so ein bisschen wisst, naja, also wann mache ich das eine, wann mache ich das andere? Und ich fange meine Vorträge ja immer so ein bisschen off topic an. Das ist dieses Mal nicht anders, wobei ich dazu nehmen muss. Ich habe in so rund zwei Stunden noch mal einen Vortrag, da werde ich dann noch mal präsentieren.
01:02
Sorry, also vielleicht beim nächsten Vortrag werde ich den auch joinen. Dann einfach in dieser Zeit vielleicht noch mal einen Kaffee holen oder so. Ja, ich bin so ein bisschen interessiert in alten Filmen. Ich gucke mir so ganz gerne ältere Filme, so Alfred Hitchcock und so aus den 50er, 60er Jahren. Und einer der Filme, den ich ganz interessant finde, ist ein Film, der heißt Ein Goldfisch an der Leine.
01:23
Vielleicht kennt ihr den einen oder anderen mit Rockatzen. Es geht hier um einen sehr verkäufreichen Verkäufer von Angelzubehör. Und ja, im Rahmen von so einer Marketing-Werbekampagne, wir kennen das ja alle, soll er dann tatsächlich an so einer Angel-Challenge mit teilnehmen.
01:42
Das hat mit der Tochter des Eigentümers zu tun, das ist die Frau, die man hier auf dem Bildschirm sieht. Und die kommt dann eben auf die Idee, das wäre doch super, wenn Roger Willoughby, so heißt der Angler, tatsächlich dann diese Angel-Challenge gewinnen würde. Und dabei stellt sich dann tatsächlich heraus, dass er zwar ein Buchautor ist und dass er super viel über Angeln weiß
02:01
und dass er aber tatsächlich Angeln gar nicht kann und Angeln gar nicht mag. Er war da sehr, sehr erfolgreich gewesen in seinem Anglervertrieb, weil er halt einfach immer auf die Kunden gehört hat und hat das Wissen eigentlich von Kunde A zu Kunde B dann weitergegeben. Aber eigentlich mag er keine Fische und kann auch nicht angeln. Das Ganze ist natürlich eine Liebesgeschichte.
02:21
Am Ende werden die dann heiraten und er gewinnt per Zufall tatsächlich dann auch diesen Angel-Challenge. Aber nichtsdestotrotz, das ist so diese Geschichte von dem Film. Warum erzähle ich das hier? Warum bringe ich das hier auf? Weil, naja, mal ganz ehrlich, ich hatte gestern einige Gespräche gehabt und ich gehe mal davon aus, dass viele von euch sehr viel Meermaisgölze aber administrieren wie ich.
02:41
Also bei mir ist das ganz genau einer, mein eigener. Und ich ansonsten bin da in einer ganz ähnlichen Situation. Ich höre halt auf das, was Kunden machen, was ihr mir so sagt, was ihr mir an Feedback gebt. Ich bin natürlich schon sehr fokussiert auf das Thema, ich lese viele Blogs und so weiter und so fort. Aber diese praktische Erfahrung, die viele von euch haben, die habe ich höchstwahrscheinlich nicht.
03:00
Ich mache das schon viele, viele Jahre. Deswegen hat sich das Bild trotzdem nicht geändert. Und das wollte ich an dieser Stelle einfach mitgeben. Also ich möchte nicht hier als der super Advisor, als der super erfahrener Administrator auftreten, weil tatsächlich gesagt bin ich das nicht. Ich höre mir halt einfach an, was ihr macht. Ich versuche mir dann ein Bild daraus zu machen. Ich lese wie gesagt viele Artikel.
03:21
Aber wenn es wirklich um das reine Doing geht, ich weiß gestern hatte ich einen Kunden, der hat gesagt, er macht so 300, 400 Meisgölzsysteme gut ab von meiner Seite aus. Das mache ich an dieser Stelle nicht. Deswegen so ein bisschen die Einführung hier von dem Merchant Willoughby, Goldfisch an der Leine. By the way, wenn auch der ein oder andere vielleicht in älteren Filmen interessiert ist, würde ich sehr empfehlen.
03:42
Gab es neulich auch auf Netflix. Ich weiß nicht, wie die Filme da hinkommen und wie die weggehen, aber vielleicht einfach mal schauen. So, die erste Folie, es ist wirklich nur die erste Folie, so ein bisschen Marketing MySQL. Und dann werden wir schon relativ schnell in die Details gehen. Gestern hatte ich eine Frage bekommen, MySQL tut sich da eigentlich noch irgendwas?
04:01
Ja, es ist ja so, wir sind seit 10 Jahren etwa bei Oracle angeklädert. Wir wurden von unseren Microsystems übernommen. Und da ist immer so ein bisschen dieser Zwiespalt. Es gibt die Oracle Datenbanks, es gibt die MySQL Datenbank, Oracle hat noch viele andere Datenbanken. Und ja, da ist wahrscheinlich die Frage so ein bisschen begründet. Das tut natürlich schon so ein bisschen weh, weil eigentlich tut sich da sehr, sehr viel, sogar sehr, sehr viel mehr als zusammen oder zu MySQL Zeiten.
04:26
Und ich werde da auch ein bisschen jetzt darauf eingehen. Aber wenn mich eigentlich jemand fragt, tut sich bei MySQL noch was, dann beobachtet er dieses Thema eigentlich tendenziell eher nicht. Ich fange einfach mal mit dem ersten offensichtlichen an. Wir sind MySQL of the Year geworden, letztes Jahr von DB Engines gerankt.
04:42
Diese DB Engines Seite, die ihr jetzt auch sehen sollt, ist eine relativ populäre. Da wird halt einfach geguckt, ja, wie viel Google hits, wie viel Bing hits, wie viel Stellen, LinkedIn, Sync, Twitter und so weiter und so fort. Da gibt es ein gewisses Rating. Und dieses Rating zeigt so ein bisschen die Relevanz und zeigt auch so ein bisschen die Tendenzen, wo es hingeht.
05:00
Dieses Ranking wird monatlich neu bestimmt. Jetzt, ich nehme mal vorne weg, in diesem Monat hatten wir ein paar Minuspunkte. Das ist nicht unüblich. Das Ganze ist saisonal bedingt. Typischerweise kommen ja die ganzen Produktlaunches von MySQL so eher im Herbst, weniger im Frühjahr. Das heißt, unser Tumbling-Ranking wird dann definitiv auch wieder hochgehen. Was man hier aber sieht, dass MySQL tatsächlich sehr, sehr häufig eingesetzt wird,
05:21
sehr, sehr häufig auch angefragt wird. Die Oracle ist tatsächlich hier noch ein paar Punkte vor uns, wobei wir natürlich intern auch dran arbeiten, auch unsere Kollegen hier von Oracle hier zu überheben. Ihr könnt ja mal so ein bisschen für euch überlegen. Ich glaube, dieses Ranking trifft es ganz gut. Also, wenn ich einfach mal die ersten fünf nehme, Oracle, MySQL, Microsoft, Postgres, Mongo,
05:40
dann sind das tatsächlich die Datenbanken, die man bei vielen Kunden auch sieht. Und ich würde sogar sagen, mit großem Abstand. Da gibt es ganz, ganz, ganz viel mehr. Es gibt auch spezialisierte Datenbanken und ich will das auch gar nicht kleinreden an dieser Stelle. Es gibt einen Anwendungsfall für alles. Aber tatsächlich sind das, ich sag mal so, die vier, fünf großen General Purpose-Datenbanken und da ist MySQL definitiv mit dabei.
06:02
Was vielleicht an dieser Stelle noch ein bisschen interessanter ist, sind die Rankings oder sind die Service auf Stack Overflow. Bei Stack Overflow wird jährlich einmal, so im Januar, Februar, März, gefragt, ja, was für eine Datenbanktechnologie, was für ein Linux, was für eine Entwicklung, was für ein Framework und so weiter und so fort. Und da wird auch gefragt, welche Datenbank verwendet ihr.
06:21
Und tatsächlich schneidet MySQL das sehr, sehr gut ab. Sowohl absolut als auch relativ gesehen. Vielleicht diese Studie einfach mal durchlesen, ist im Internet verfügbar. Und interessanterweise auch hier nimmt tatsächlich die Relevanz von MySQL sogar über die Jahre gesehen noch zu. Also MySQL wird sehr, sehr häufig verwendet. Und das führt letztlich dazu, dass MySQL,
06:41
das ist auch diese Folie, habt ihr bestimmt von mir oder von anderen schon mal gesehen, von sehr, sehr großen Firmen wie Facebook, Twitter, Booking, GitHub verwendet wird. Ich lasse das jetzt mal so ein bisschen beiseite. Was diese Tage eigentlich sehr viel wichtiger wird, ist, ja, wo ist die MySQL-Verfügbarkeit bei den verschiedenen Cloud-Vendoren? Und tatsächlich, egal ob das jetzt in Amazon, ob das in Google,
07:00
ob das in Azure, ob das in Oracle, in IBM, in der Deutsche Telekom, in eins und eins ist. Also MySQL-Offering findet man an dieser Stelle da eigentlich immer. Und MySQL ist tatsächlich eine sehr, sehr häufig verwendete Datenbank. Einfach mal vielleicht, wenn das interessiert, so ein bisschen im Umfeld, im Google-Umfeld gucken.
07:20
Vor zwei Jahren, ziemlich genau vor zwei Jahren im April, haben wir das MySQL-8-Produkt released. Wir werden jetzt von Basis dieser Folie immer mehr in die Details gehen. Vielleicht hier nochmal so ein bisschen zur Erinnerung. Die vier, fünf großen Funktionalitäten, die sind schwarz hinterlegt. Das ist einmal das Data Dictionary, der Unicode Support, Common Table Expression, Windows Functions, Documents Store.
07:42
Für jedes einzelne Funktionalität gab es einen Background. Für die CTEs, Windows Function, die erweiterten SQL-Funktionalitäten hat das alles mit dem MySQL Analytics Cluster zu tun. Spät in diesem Jahr kommt Data Dictionary, weil letztlich nur eine Technologie, eine Infrastruktur, Komponente, die geändert wird, die uns sehr, sehr lange gedauert hat.
08:01
Die ersten Betas gab es schon 2013, 2014, um einfach ein sehr viel höheres Skalierungsmodell zu bringen. Und Documents Store, für die, die da interessiert sind, ich werde in dem nächsten Vortrag, wenn es um DevOps geht, da auch noch ein bisschen was dazu erzählen. Wir werden nicht sonderlich in die Tiefe gehen, aber Documents Store MySQL kann auch für sehr viele Mongo-Anwendungsfälle mit angebracht werden.
08:22
Was uns an dieser Stelle jetzt hier interessiert, ist vor allen Dingen, dass zwischen 2015 und 2018 gab es Erweiterungen, Group Replication Plugins und es gab InnoDB Cluster Erweiterungen. Hier vor allen Dingen die Router und die Shell. Und Router und Shell, das sind jetzt zwei Komponenten, die müssen wir uns vorab anschauen, um zu verstehen, was ein Replikasset ist und was sich mit der Replikation geändert hat.
08:42
Wir fangen mal an mit dem MySQL Router. Wie gesagt, der MySQL Router ist kein neues Produkt. Den gab es sogar schon sehr, sehr lange. Das ist früher MySQL Proxy. Der ist dann vom Namen her und auch von den Funktionalitäten her geändert worden auf MySQL Router. Ganz grundsätzlich ist es so, wenn man einen Cluster-Verbund hat, dann kann man den MySQL Router konfigurieren,
09:01
sodass der MySQL Router letztlich immer auf eine Instanz connecte, die verfügbar ist. Bei einem Cluster-Konstrukt, wenn ich drei Server habe, macht es an dieser Stelle vielleicht Sinn zu sagen, ich habe hier einen Server, die anderen zwei sind vielleicht nicht verfügbar und der Router soll natürlich nur auf den verfügbaren Server gehen. Das ist so ein bisschen die Intention von dem MySQL Router gewesen und der MySQL Router ist mittlerweile eine ganz, ganz wichtige Komponente für MySQL geworden.
09:24
Es ist ganz egal, ob das jetzt irgendwelche Microservices sind, ob das Replikation ist, ob das InnoDB Cluster ist und den werden wir uns tatsächlich auch noch ein bisschen mehr in der Tiefe dann anschauen. Die zweite Komponente, die mindestens genauso wichtig ist, ist die MySQL Shell.
09:43
Ich nehme mal vorne weg, die MySQL Shell, das ist so unser Ansatz, um zu sagen, man kann MySQL auch in DevOps-Enlightenment relativ einfach einsetzen. Die MySQL Shell originär wurde eigentlich entwickelt, um für diese ganzen Mongo-Anwendungsfälle, wenn ich also ein nicht SQL-Protokoll, ein NoSQL-Protokoll verwende,
10:01
mit MySQL arbeiten zu können. Wie gesagt, da geht es jetzt in diesem Vortrag nicht drum. Die MySQL Shell hat aber noch andere Komponenten und diese anderen Komponenten, das sind die für uns wichtigen an dieser Stelle. Man kann mit der MySQL Shell administrieren und operative Dinge sehr, sehr einfach automatisieren. Die MySQL Shell, das ist so unser Tool, mit dem wir eigentlich jetzt mittlerweile alles erschlagen,
10:21
egal ob das Cluster ist, ob das Replikation ist, ob das Import, ob das Export ist. Also wer heute noch MySQL Dampf macht, okay, es gibt für alles einen Anwendungsfall, dem lege ich dabei ganz, ganz, ganz nahe, sich mal mit der MySQL Shell zu beschäftigen, weil die MySQL Shell mal ganz vereinfacht gesagt, MySQL Dampf, egal ob das jetzt ein Import, ob das ein Export ist, multithreaded vornehmen kann
10:42
und dadurch unendlich viel mehr Performance bietet wie ein klassisches MySQL Dampf. Alles das kann man tatsächlich auf Basis der MySQL Shell machen. Die MySQL Shell und die MySQL Route, wie gesagt, so ein bisschen im Hinterkopf zu haben, die gibt es schon relativ lange, das ist keine neue Entwicklung. Die brauchen wir aber, um zu verstehen, wo es mit Replikation und Replikasets hingeht.
11:03
So, MySQL, ich hatte es schon gesagt, wurde so vor zwei, zweieinhalb Jahren released als Version 8.0, im April war das gewesen. Und eine der anderen großen Änderungen, die sind nicht groß publiziert worden, die sind nicht groß announced worden, war tatsächlich gewesen, dass wir ein Continuous Development Modell verfolgen.
11:23
Also mit jedem Update, typischerweise ist das so alle drei Monate, man sieht es auch hier in der Historie jetzt schon ganz gut, das ist Januar, April, Juli und Oktober, da kommen typischerweise Updates zu MySQL, da sind eine ganze Menge Security- und Bug-Fix-Updates, aber halt ganz oft auch neuere Funktionalitäten.
11:40
Ob das jetzt beabsichtigt ist oder nicht beabsichtigt ist, weiß ich ganz ehrlich gesagt nicht, aber ich würde mal sagen, es kommt ein Release raus, das hat so ein paar mehr Funktionalitäten und das nächste Release hat auch mehr Funktionalitäten, aber ist so ein bisschen ein kleineres Release, immer so ein wechselgrößeres, kleineres Release. Ich will die jetzt an dieser Stelle nicht alle durchnudeln, ich würde gerne anfangen im Juli 2019,
12:04
so mehr oder weniger vor einem Jahr gesehen, mit dem Release 8.0.17, da gab es eine Funktionalität des Clonings. Auf dieses Cloning werde ich auch gleich nochmal eingehen, auch das brauchen wir, um zu verstehen, wo es mit Replikation, wo es mit Clustering hingeht. Ja und dann gab es halt im Oktober das Hashed-Join-Release,
12:23
sage ich an dieser Stelle einfach mal, also man kann auf Basis von Joins, die nicht über den Index angebildet werden und auf Basis von diverser mathematischer Algorithmen sehr, sehr viel mehr Performance erzeugen, gibt es ganz, ganz viele Einträge dazu und dann im Enterprise-Backup gab es ein sogenanntes Page Tracking, was dazu geführt hat, dass gerade inkrementelle Backups um Faktor 100 etwas schneller sind,
12:45
lassen wir so ein bisschen außen vor. Das erste große an dieser Stelle ist InnoDB Replika Set, InnoDB Replika Set sind automatisierte Replikationsinfrastruktur. Da werden wir gleich sehr viel mehr im Detail drüber reden, aber auch hier ist keine ganz neue Funktionalität, ist an dieser Stelle schon ein paar Tage her.
13:02
Sorry, das ist natürlich nicht Januar 2019, das ist natürlich Januar 2020. Die nächste große Funktionalität, die ist unter Umständen für uns auch wichtig, das Binlog, eine Funktionalität, eingeführt worden Binlog Kompression. Ihr wisst vielleicht, dass die Binlogs sehr, sehr groß werden können. Wenn ich sage sehr, sehr groß,
13:22
dann werden die typischerweise so für zehn Tage vorgehalten und es ist nicht unüblich, da ein paar hundert Gigabytes von Binlogs zu haben. Das frisst mir über kurz oder lang natürlich meine Festplatte auf. Und von der Seite Binlog Kompression, wie der Name an dieser Stelle halt schon sagt, komprimiert die Binlogs, da kann man unendlich viel Plattenplatz sparen. Ich kenne Anwendungsfälle,
13:40
wo tatsächlich 80, 90 Prozent eingespart wurden auf Basis der Kompression. Aber der Downside an dieser Stelle ist natürlich wieder, es kostet eine ganze Menge CPU. Also mit ein, zwei CPU-Systemen, das oder ein, zwei Core- oder Thread-System, das kann unter Umständen mit MySQL jetzt ein bisschen eng werden. Im Juli kam dann tatsächlich die neue Dampffunktion,
14:02
sage ich mal, für die MySQL Shell, wo man Dampf tatsächlich auch automatisieren kann und vor allen Dingen Multithread automatisieren kann, was dazu führt, dass gerade der Restore sehr, sehr, sehr viel schneller funktioniert, wie das vielleicht noch klassisch gewesen ist. So, dann gibt es hier ein Akronym, Grataase. Das könnt ihr googeln, werdet ihr bestimmt nicht finden.
14:22
Das habe ich gestern erfunden. Das soll heißen Atomic Create Table as Select. Es gibt eine Funktionalität in MySQL Global Transaction Identifiers, die letztlich dazu geführt hat, dass man tatsächlich die verschiedenen Systeme untereinander unterscheiden kann. Wenn ich eine Replikation habe über mehrere Systeme, konnte ich sagen, das System A hängt zwei oder drei
14:44
Raws oder Änderungen einem anderen System hinterher. Diese Global Transaction Identifiers ging, leider muss man sagen, nicht mit allen SQL-Befehlungen. Dieses Create Table as Select, das war eines von denen, das war kein Atomic Statement. Weil es kein Atomic Statement war, konnte man tatsächlich nicht über GTIDs abfrühstücken.
15:02
Und das ist jetzt Geschichte. Das führt jetzt eigentlich dazu, dass man tatsächlich alle SQL-Befehle auf Basis GTIDs mit ausführen kann. Diese ganzen Limitierungen, die es früher gab, gibt es so eigentlich nicht mehr. Gut, dann hatte ich schon gesagt, ja, automatisches Node Provision oder Cloning.
15:21
Ich meine, die Idee ist relativ einfach. Ich habe ein Server A und ich kann jetzt über die MySQL Shell mit einem Befehl sehr, sehr einfach eine Kopie dieses Servers ziehen. Ich kann das im Betrieb machen. Das System kann weiterlaufen. Das Ganze ist Atomic. Das Ganze ist konsistent. Das heißt, ich habe ein System, der surft irgendwie meinen WordPress oder meine Applikation XYZ
15:41
und kann zeitgleich tatsächlich Clon von diesem System erstellen. Und auf Basis von diesem Clon kann ich dann später eine Replikation oder ein Cluster aufbauen. Das ist die Idee von Clon, ist wie gesagt auch keine neue Funktionalität mehr. Viele verwenden das auch tatsächlich, um ein Backup durchzuführen. Ich habe dann halt tatsächlich einen Backup von dem kompletten System. Das ist die Idee von dem Clon.
16:01
Wie gesagt, werden wir sehr, sehr häufig jetzt verwenden, folgend. Und muss man auch so ein bisschen im Hinterkopf haben, ist aber auch keine neue Funktionalität. So, ja. HA, Cluster. Es geht hier um Clustering. Und sind wir an dieser Stelle mal ganz ehrlich, so ein Cluster, das will eigentlich jeder haben. Wenn man jetzt einfach mal guckt,
16:21
Facebook, Twitter, Github, diese ganzen Services, die stehen im Internet zur Verfügung. Das heißt auch Zeitkleid, das typischerweise keinerlei Downtimes in irgendeiner Art und Weise gibt. Das heißt also, HA ist tatsächlich so ein Key-Requirement geworden, wie vieles andere an dieser Stelle halt eben auch. So, und was kann man jetzt machen? Was kann man tatsächlich verwenden,
16:42
um ein HA abzubilden? Da fangen wir einfach mal mit einer Technologie, die es schon relativ lange gibt, mit der Replikation. So, Replikation, sinngemäß ganz einfach. Auf der letzten Seite habe ich mein Master und Slave. Sorry, ich habe hier noch die alte Nomenklatur verwendet. Master und Slave gibt es eigentlich nicht mehr. Das heißt heute
17:01
Source und Replika. Das hat politische Hintergründe. Ihr habt auch mitbekommen, Amerika, Black Lives Matters. Von der Seite hat man die Namensdeklaratur hier an dieser Stelle geändert. Sorry, ich habe es einfach nicht gesehen. Aber ich habe in der linken Stelle, also was früher mein Master gewesen ist, heißt heute Source. Und was früher der Slave gewesen ist,
17:21
heißt heute das Replika. Gut, ich habe links meine Source, das heißt alles von meiner Applikation wird in diese Source reingeschrieben. Und wird dann tatsächlich als Kopie in den Binary Log, daher kommen diese großen Dateien des Binary Logs eben mit vorgehalten. Das heißt, das Binary Log hat sinngemäß
17:40
nur die Änderungen, die auf die Datenbahn gepliziert werden. Und diese Änderungen des Binary Logs, die können tatsächlich dann über die Replikation auf ein Zweitsystem mit übernommen werden. Typischerweise steht eine Kopie des Binary Logs auf meinem Replika Slave, auf meinem Slave Server zur Verfügung. Und dieses Relay Log ist sinngemäß nichts
18:00
anderes wie eine Kopie von diesem Binary Log. Und wird auf Basis dieses Relay Logs dann tatsächlich über mehrere Appliers auf meinen Server appliziert. Sodass ich mit einem gewissen Zeitverzug, da könnte eine Latenz dazwischen sein zwischen der Source und dem Replika.
18:20
Das kann durchaus Ostküste, Westküste, New York, Frankfurt oder sowas. Replikation ist latenz tolerant. Das heißt, macht an dieser Stelle nichts aus. Heißt aber, dass der Replika Server, dass der Slave Server an dieser Stelle meistens wahrscheinlich nicht so ganz 100% akkurat ist dem Original
18:41
System. Das muss man sich an dieser Stelle so ein bisschen im Hinterkopf behalten. Aber mal ganz grundsätzlich die aller, aller, aller meisten Parteien oder die aller, aller, aller meisten Records, die auf meinem Master System zur Verfügung stehen, stehen tatsächlich auf meinem Replika System auch zur Verfügung. Da haben wir hier so ein kleines Sinnbild. Also ich habe auf meinem
19:02
Source System habe ich eine Transaktion, die einkommt, die wird exekutiert, die wird im Binary Log vorgehalten, die wird gegenüber der Storage Engine committed. In dem Moment, wo sie committed wird, steht sie auch für andere Applikationen zur Verfügung. Man sieht aber hier schon ziemlich deutlich, dass wenn auf dem Replika 1 und Replika 2 System die
19:21
Informationen ankommen, es wahrscheinlich zu einem Zeitverzug geht. In dem Moment, wo ich einen Read machen würde, auf allen drei System, gäbe es zu dieser Zeit, wo genau diese Änderung, diese Transaktion eingeflossen ist, wahrscheinlich keinen konsistenten Output. Das will man ganz oft nicht. Auf der anderen Seite ist Latency Tolerant ein großer Vorteil
19:42
und funktioniert wie gesagt schon sehr, sehr lange. Das funktioniert typischerweise eigentlich ultramassiv. Das Aufsetzen von so einer Replikation, ich gehe mal davon aus, jeder, der mit Maisgöl gearbeitet hat, hat es schon mal gemacht. Das ist ein manueller Shop. Da muss man so zwei, drei Sachen machen. Man muss einen Benutzer anlegen. Ganz wichtig an dieser Stelle ist, aber
20:01
man muss vor allen Dingen erstmal eine Kopie der Original Daten auf das Replikasystem bringen. Ob man das jetzt mit einem Backup macht, ob man das mit einem Snapshot macht oder sonst irgendwie, lasse ich erstmal da hingestellt, aber ganz wichtig ist, ich brauche erstmal einen Anfangspunkt, damit ich von den Daten des Binaries anfangen kann, diese Daten dann abzuändern.
20:20
So haben wir das in der Vergangenheit gemacht. Wie gesagt, das lief ultra stabil und das hat eigentlich schon so die erste HA-Lösung eben mit aufgebracht. Also wenn ich so ein Serversystem A, B, C hatte, mein Source-System war mein A, mein Replikas waren B und C. Und in dem Moment, wo mein Source-System A dann tatsächlich kaputt gegangen ist, dann habe ich einen von den anderen
20:42
zwei Replikasystem, von den zwei Slave-Systemen verwendet und habe dann tatsächlich da einen neuen Master, eine neue Source rausgebaut und habe meinen anderen Slave tatsächlich auf diesen Slave B, auf den ehemaligen Slave-Server B connected und habe dann an diesen Daten mit weitergemacht. Wie gesagt,
21:02
so weit ist es absolut nichts Neues. Das hat jeder schon mal gemacht. Jetzt muss man dazu sagen, da gab es sehr, sehr viel Einfallsreichtum. Da wurde sehr, sehr viel konfiguriert, da wurde sehr, sehr viel gescriptet. Das hat letztlich dazu geführt, dass das zwar sehr, sehr flexibel gewesen ist, dass wir uns dann aber irgendwann sehr, sehr schwer getan haben, da Backfixes dafür zu betreiben, die Dokumentation
21:21
anzupassen. Und irgendwann sind wir einfach da ein bisschen aus dem Ruder gelaufen und das war nicht mehr händelbar. Ich sag mal, es gab nicht die H-Lösung, sondern jeder hatte seine H-Lösung. Also Master, Masterkonstrukte, Masterringkonstrukte und so weiter und so fort. Das kann man auch alles noch machen. Versteht mich nicht falsch an dieser Stelle, nur irgendwann
21:41
wird das aus unserer Sicht irgendwie unseportbar. Und jetzt hat man tatsächlich diese erste große Änderung vorgenommen. Das war Anfang des Jahres und man hat gesagt, okay, wir vereinheitlichen jetzt die sogenannte Replika, der Replikationssystem in den sogenannten Replika-Sets. Das Ganze basiert auf einer asynchronen
22:00
Replikation, so wie wir das früher auch gemacht haben. Und jetzt nehmen wir diese anderen zwei Komponenten, die wir bis Januar dieses Jahres tatsächlich nur im Cluster-Umfeld hatten, die nehmen wir jetzt her und die können eben jetzt auch für die Replikation verwendet werden. Das heißt, in dem Bild hier, ich habe zwei Applikationsserber und ich habe unten eine Replikation mit
22:21
einer Source und mit einer Replikation. Und wenn ich jetzt auf diese Replikation zugreifen will, möchte automatisiert auf meinen Source-Rechner kommen, dann kann ich eben jetzt auch den Router verwenden. Vielleicht kennt der eine oder andere das schon von dem MinoDB Cluster, der macht das an dieser Stelle ganz ehrlich. Das ist genau dasselbe Router und der kann eben jetzt
22:41
auch die Replikation hängen. Und was eben auch noch dazu kam, ich kann so eine Replikation jetzt auf Basis der MySQL Shell aufsetzen. Das heißt, ich kann die Replikation weitestgehend automatisieren. Dieses ganze Nutzer anlegen, die Daten rüber ziehen, das ganze Securing, das Einspielen von Zertifikaten, alles das, kann mir tatsächlich meine MySQL
23:01
Shell jetzt automatisiert mitmachen. Und natürlich das Beispiel Clone, ich kann sehr, sehr einfach Systeme dazu fügen, ich kann sehr, sehr einfach Systeme löschen, eben immer jetzt auf Basis der MySQL Shell. Ich kann das auch über klassische Replikation immer noch tun, hat sich nicht geändert, sind dieselben Technologien, ist nur jetzt über die MySQL Shell eben sehr, sehr einfach
23:22
automatisiert. Wenn man sich das jetzt einfach mal vorher nachher anschaut, also vorher muss ich halt immer erstmal ein Backup machen, ja, ein Dump oder ein Backup, oder ich hab irgendwie einen Datei-Snapshot, hab die Systeme runtergeführt, kann man wie gesagt immer noch machen. Einfacher an dieser Stelle ist jetzt einfach zu sagen, wir nehmen den Unity Clone, was wie gesagt Bestandteil von den Replika
23:41
Sets ist. Dieses ganze Anlegen von Benutzern und Anlegen von Passwörtern kann man immer noch automatisiert machen, kann man jetzt aber auch über die MySQL Shell sehr, sehr einfach konfigurieren. Dieses ganze Load Balancing, ich habe meinen Source, also zuallererst mal möchte ich ja tatsächlich, dass automatisch auf meinen alten Master jetzt halt Source geschrieben wird. Das macht jetzt automatisch
24:01
mein Router. Und in dem Moment, wo ich die Replikation jetzt ändere, wo ich also tatsächlich die Source ja degradiere auf ein Replika und in anderen Replika promoviere Promoter auf Basis eines neuen Source-Rechners, dann kann das der Router jetzt automatisiert verstehen. Und diese ganze Router-Konfiguration, wer den schon mal
24:21
verwendet hat, das ist ein Befehl. Also diese Router-Konfiguration wird typischerweise gebootstrapped von dem Replika-System oder auch von dem InnoDB Cluster-System. Es ist also wirklich denkbar einfach. Und der Router ist komplett stateless, der nimmt die Technologie dynamisch her. Der Router pollt für diese Information und die Replika Sets und auch InnoDB Cluster pusht auch diese
24:41
Information, sodass es typischerweise sehr, sehr einfach ist, ein Switchover, ein Failover zu generieren. Alles wird, wie gesagt, jetzt über die Shell konfiguriert. Also man muss nichts mehr irgendwie mit manuellen User-Settings und mit Pointmaster2 und Automatik. Kann man alles noch machen, ist aber eben nicht mehr notwendig. Und gerade dann, wenn ich
25:01
sehr, sehr viele Systeme habe, die ich jetzt auch dynamisch habe, die MySQL Shell kann ja sehr, sehr einfach in entsprechendes Skripte mit eingebunden werden, kann man das weitestgehend alles sehr, sehr, sehr einfach automatisieren. Also wer einfach mal eine Replikation, eine größere Replikation, früher aufgesetzt hat, ich kann das in der Replikation, in Abhängigkeit der Netzwerkgeschwindigkeit, wie schnell ich die Daten hin und her kopieren kann,
25:22
innerhalb von ein paar Minuten machen. Das hat unter Umständen allein das Einspielen von Dumps hat vielleicht früher schon irgendwie mal eine Stunde gedauert. Diese Zeiten sind tatsächlich alle vorbei. MySQL InnoDB Replika Sets ist genau dasselbe, was wir früher Replikation genannt haben. Es ist nur automatisiert und mit dem Replika Sets verwenden wir eben jetzt auch sowohl
25:41
den Router als auch die MySQL Shell. Die Requirements an dieser Stelle. Also Replika Sets funktionieren tatsächlich nur mit MySQL 8. Sie funktionieren nicht mit Release 5.7. GTI, Global Transaction Identify sind mandatory. Sowohl für den Cluster als auch für die Replika Set. Die Replika Sets machen Stand heute keinen automatischen
26:01
Failover. Es ist ein manueller Failover. Wir schauen das uns an dieser Stelle gleich an, aber es ist nicht automatisiert. Der Router entscheidet nicht, wer ist mein Primary, wer ist mein Source Server und wer ist mein Replika Server. Das muss ich nach wie vor tun auf Basis der Replikation. Ich kann das jetzt auch über die MySQL Shell. Wir werden es gleich sehen.
26:21
Sehr, sehr einfach hin und her pointen. Der Router übernimmt automatisch diese Replikation, aber es ist keine automatische Failover-Lösung. Alle Secondary Members replizieren immer von Primary. Also wie gesagt, wie das früher auch gewesen ist, mit meinen Source und meinen Replika Servers und Replikation
26:41
und Replikation Sets sind eben latentstolerant. Und das muss man immer im Hinterkopf behalten. Also die Netzwerkeschwindigkeit zwischen den zwei oder beliebig vielen Servern ist an dieser Stelle relativ unwichtig. Es kann aber im Umkehrschluss dazu führen, dass meine Replika-Systeme dem Source-System hinterher
27:01
hängen. Das sind typischerweise nur ein paar Records. Typischerweise ist es ein Bereich von paar Millisekunden, wenn man das gut aufgesetzt hat. Aber tatsächlich ist es die Idee und tatsächlich ist es auch so gewollt. So ein Replika Set, also das sind jetzt nur die Folien. Das andere machen wir an dieser Stelle dann gleich live. Wie baue ich das auf? Also ich habe zwei MySQL-Systeme. Auf dem einen System läuft
27:20
MySQL 8 mit einem großen Datenset. Und auf dem zweiten System läuft erstmal noch nichts. Was ich als allererstes an dieser Stelle mache, ich gehe in die MySQL Shell, ich führe diesen Befehl db-configure-replika-set instance aus. Der führt alle Schritte in der MyINI und in der Auto-MySQL-D durch, sodass dieses System verwendet werden
27:41
kann. Das heißt, der setzt Global Transaction Identifiers auf und wenn es nicht sowieso schon eingeschaltet war, der konfiguriert mir, dass das binary log enabled ist. Der konfiguriert mir die ganzen Security-Berechtigungen. Also der macht an dieser Stelle alles, der nimmt alles erstmal vor, damit die Systeme replizieren können. So, der zweite Schritt an dieser Stelle, das kann
28:01
unter Umständen auch beinhalten, dass ein Restart gemacht wird. Er fragt vorher, ob dieser Restart wirklich gemacht werden soll, aber das kann unter Umständen auch heißen, dass ein Restart gemacht wird. So, der zweite Schritt an dieser Stelle, create-replika-server, ist, dass ich tatsächlich die Source-Quelle meines replica-sets den sogenannten primary-server definiere.
28:22
Ich konekte mich auf diesen Server, wie gesagt ist alles in der MySQL Shell hier, auf Server 1 3306. Create-replika-set. Das heißt, zu diesem Zeitpunkt wird ein sogenanntes Meta-Schema- Datensystem angelegt. Dieses Meta-Schema-Datensystem beinhaltet die Replikations- konfigurationsdateien. Ich könnte den Status
28:40
checken von meinem Source, von meinem primary-server und könnte dann Server 2 und Server 3 mit dazu nehmen. Und technisch ist es so einfach. Also add-instance, ja, in diesem Beispiel ist es dann Server 2 und add-instance Server 3. Je nachdem, wie viel Daten ich da vorgehalten habe auf dem System, kann das noch einen Blick dauern. Wenn es, ich sag mal, jetzt 100
29:01
Gigabyte-Daten sind, werden tatsächlich von meinem originär, von meinem alten Master, jetzt Source-System die Daten gesinkt auf mein zweites System. Wie gesagt, wie lange es halt dauert, diese 100 Gigabyte-Daten zu übertragen. Das 2-System wird an dieser Stelle, Server 2 und Server 3 wird nochmal gerestartet und bildet sich dann dynamisch
29:21
in die Replikation an. So einfach ist es mittlerweile. Also es sind wirklich nur 4 oder 5 Befehle. Es ist im Regelfall rock solid und das passiert auf Basis der alten Replikation. Wer sich besser damit fühlt zu sagen, also hier show slave status oder master status oder reset master oder was auch immer, das geht alles immer noch.
29:42
Ja, also es ist nicht nur automatisiert, nur die Idee ist es halt tatsächlich so einfach wie möglich zu machen. Und ja, ich kann eben sehr, sehr einfach sagen, auf Basis der Replikation Server A ist mein primary Server oder in diesem Beispiel ist es dann Server 3. Ich kann das auf Basis der Replikation selbst so vorführen, dass die Replikation geändert
30:02
wird und der Router das an dieser Stelle dann automatisch mit kann. Ganz einfach. So, diese Router-Integration funktioniert typischerweise dann wie gesagt als Bootstrap. Also ich ziehe mir diese Metadaten, die ich mit diesem Create Replicaset angelegt habe auf einem Master System, sehr einfach dann rüber und der Router routet entsprechend auf die
30:23
Instanz. Mit set-primary-instance kann ich auf Basis der Replikation definieren, was ist jetzt mein primary Server, was ist mein Source, was ist mein Master. Der Router passt sich automatisch an. Sagen wir mal, ich habe fünf Systeme, typischerweise habe ich dann ja eine Source und ich habe vier Replika.
30:40
Sagen wir mal, die Source ist kaputt gegangen. Network disconnect, Platten crash, ganz egal was. Kann ich auch ganz einfach sagen, force-primary-instance, was heißt, dass mein MySQL Shell automatisch entscheidet, was ist denn tatsächlich der neueste Replikation? Wer hat die meisten Daten? Wer hat die neuesten Daten? Und das ist tatsächlich dann mein neuer, so was, das ist mein neuer Master. Und wie gesagt, der Router
31:02
passt sich an dieser Stelle dann eben automatisch mit an. Das ist genau die Idee von den Replicaset, ist wie gesagt noch relativ neu mit MySQL 8, ist eine ganz wichtige Komponente, weil wir eben versuchen, die Replikation so ein bisschen zu vereinheitlichen. Aber an dieser Stelle nochmal ganz wichtig und das ist tatsächlich jetzt dann auch
31:20
der Switchover zu dem ImmunoDB Cluster. Also es funktioniert eben nicht automatisch. Also in dem Moment, wo der Server M, Master, die sogenannte Source, wo der runterfällt, dann ist der runtergefallen. Der Router kann sich halt dann eben nicht mehr auf diesen Server verbinden. Ich habe eine Outage. Was ich machen muss an dieser Stelle ist, ich muss die Replikation
31:42
ändern, entweder mit set-primary oder mit force-primary. Das ist eine händische Sache. Natürlich kann ich das auch scripten. Gar keine Frage. Und erst wenn ich tatsächlich dann wieder eine neue Primary-Server habe, erst dann geht meine Applikation, erst dann kann ich meine Applikation letztlich wieder betreiben. Und genau das ist der Punkt.
32:00
Genau das ist der Unterschied zwischen der Replikation und dem ImmunoDB Cluster. Die Replikation ist nicht automatisch. Ich kann auf Basis von zwei, drei, fünf beliebig vielen System ein Failover initiieren, aber ich, der Mensch muss ihn initiieren. Und genau das ist der Unterschied, der jetzt mit dem ImmunoDB Cluster anders ist.
32:20
Ich werde auf die Fragen dann in 20 Minuten etwa dann eingehen. ImmunoDB Cluster. Fangen wir mal an. Das heißt auch Replikation. MySQL-Gruppreplikation. Jetzt was ist das? Es ist ganz genau genommen keine Replikation, auch wenn es so heißt. Es ist ein eigenes
32:41
Protokoll, was wir hier verwenden, GCS Group Communication System, was auf Basis von Paxos, wir verwenden hier eine sogenannte Mencius-Variante, was sinngemäß heißt, auf Basis von drei Servern ist jeder Server zu den anderen zwei Servern verbunden. Das ist also einfach ein Broadcast-Protokoll, kein Roadtrip-Protokoll. Das ist diese Mencius-Variante. So. Und auf Basis von
33:00
diesen drei Systemen habe ich jetzt ein eigenes Protokoll initiiert, das GCS Group Communication System. Und dieses Protokoll, dieses Tool, ermöglicht mir jetzt sicherzustellen, dass ich auf allen Systemen den gleichen Cache habe. Ich sage jetzt einfach mal für einfach, das ist das Binary-Log. So kann man sich das relativ einfach übertragen. Und dieses Binary-Log ist auf
33:20
allen Systemen hundertprozentig identisch. Das ist die Idee von der Gruppreplikation. Wenn jetzt tatsächlich einer von diesen drei Systemen warum auch immer ein Problem hat, dann können die anderen zwei Systeme, die den gleichen Status haben, bestimmen, dass der dritte Server aus dem Cluster-Konstrukt rausgeschmissen wird. Oder, ja,
33:40
dass er eben rausgeschmissen wird. Und wenn der alte, auch da gibt es Primary und Secondary, auch wenn der alte einen Primary hat, dann entscheiden die zwei, also pass mal auf, den alten Primary, den werfen wir jetzt raus. Und wir zwei Secondaries einigen uns jetzt darauf, dass du der neue Primary Server bist. Das heißt, dieser ganze Failover, der funktioniert bei der Gruppreplikation
34:01
automatisiert. Und die Entscheidungsmetrix, welcher Server jetzt tatsächlich mein neuer Primary Server ist, das treffen die zwei Systeme, die denselben Status haben. Typischerweise ist die kleinste UUID, man kann das auch ganz einfach konfigurieren mit sogenannten Member Weight. Aber mal grundsätzlich, wenn drei Systeme, wenn ein System nicht den richtigen
34:21
Status hat, dann bestimmen die anderen zwei Systeme, dieser dritte Server, den kicken wir jetzt einfach raus. Wir können dann auch noch genau definieren, was mit diesem dritten Server passieren soll, dass der wieder automatisch zu dem Cluster-Konstrukt dazugenommen wird. Kann man das machen. Aber mal grundsätzlich zwei Systeme können den dritten Server übertragen. Deswegen bietet es sich auch an, eine ungerade Anzahl von Server
34:41
zu haben. Weil wenn ich zwei oder vier Systeme habe, gibt es halt die Möglichkeit, ja, bei vier Systemen, dass es ja Equal gibt, dass ich einen Split-Brain habe. Und das wollen wir auf alle Fälle an dieser Stelle verhindern. Das ist die Gruppreplikation. Und in Verbindung, hier schließt sich dann wieder der Kreis zu den Replikassets,
35:01
in Verbindung mit der MySQL Shell und mit dem MySQL Router sprechen wir von dem sogenannten InnoDB Cluster. Das ist der InnoDB Cluster. Das andere war das InnoDB Replikasset. Grundsätzlich der Aufbau. Ich habe mindestens drei Server. Das ist ein großer Unterschied zu den Replikassets. Ich kann ja mit zwei Systemen replizieren. Ich brauche auf Basis
35:21
der Entscheidungsmetrix, dass die Mehrheit der Systeme entscheidet, ob ein Cluster funktional ist oder nicht. Aber hier immer einen dritten Server. Und deswegen also drei Server. Auch hier wieder, ich setze das Ganze mit der MySQL Shell auf. Das Ganze ist eine Sache von zwei, drei Minuten. Ich werde es gleich in der Live-Demo auch präsentieren. Und kann dann ähnlich wie ich das bei der
35:41
Replikasset auch gesagt habe, über die Applikation, über den Router konfigurieren, wo soll es denn hin geroutet werden. Also ich habe meine drei Systeme. In diesem Beispiel ist mein Primary Server im Moment der ganz linke Server. Der Router pointet tatsächlich auf Primary. Der macht Redes and Rides. Der Router könnte die anderen zwei Systeme als Read-Only-System
36:01
auch ansprechen, würde die auch entsprechend Loadbalancen. Wäre keine Riesensache an dieser Stelle. Jetzt gehen wir mal davon aus, es gibt ein Problem. Also es gibt einen Crash. Das heißt, dieser Server fällt an dieser Stelle weg. Was dazu führen würde, dass die anderen zwei Secondary Systeme sich jetzt entscheiden, dass einer von denen die Primary Rolle übernimmt.
36:20
Der Router würde auf den Primary Server zeigen. Der andere Server wäre nach wie vor noch der Secondary und vielleicht ist es ja sogar so, dass dieser alte Primary, der hatte nur ein Netzwerk oder sowas oder hatte irgendwie Jam Update oder keine Ahnung. Also er war halt irgendwie nur vorübergehend nicht verfügbar. Kann durchaus sein, dass der diese Gruppe auch automatisch wieder joint, aber
36:40
er ist halt kein Primary Server mehr, sondern ist dann einfach nur noch ein Secondary Member Server. Das ist die Idee von dem InnoDB Cluster. Das kann man wie gesagt alles weitestgehend automatisieren. So, jetzt schauen wir uns auch hier natürlich die Requirements an. Da fällt zunächst erst mal auf, wir unterstützen hier auch ältere Releases. Also Release 5.7 läuft tatsächlich auch mit der Co-Publication.
37:01
Das ist keine neue Technologie. Das gibt es schon einige Jahre. Dementsprechend kann man das mit 5.7 machen. Allerdings um Latest und Greatest, also wenn es um die Technologie des Clonens zum Beispiel geht, geht typischerweise alles nur in MySQL 8. Ich würde wirklich jedem empfehlen, das nur mit MySQL 8 zu machen und nicht mehr mit dem Release 5.7. By the way, das Release 5.7 ist
37:21
im Oktober des nächsten Jahres fünf Jahre verfügbar. Das heißt, es fällt vom Support-Modell zurück auf den sogenannten Extended Support, was grundsätzlich erst mal noch gar nichts heißt. Wir werden immer noch Patches, Updates und alles dafür liefern. Allerdings in drei Jahren ist tatsächlich mit dem Release 5.7 Schluss. Also es ist jetzt eigentlich so eine ganz gute Zeit, sich über MySQL 8 Gedanken zu machen.
37:41
InnoDB Cluster wird tatsächlich nur von InnoDB unterstützt. Das sagt ja auch der Name schon irgendwie. Und Stand heute ist es wirklich noch so, ein Primary Key ist mandatory. Kein Primary Key, kein InnoDB Cluster. Diese Limitierung wird fallen. Stand heute ist sie aber noch nicht gefallen. Und wenn ihr Tabellen habt, und da kommt man ganz, ganz, ganz schnell in diese Falle mit Wordpress, mit TypoTry, mit Content Management
38:02
System, dass da Tabellen sind, die kein Primary Key haben, dann geht der InnoDB Cluster nicht. Punkt. Also ich brauche ein Primary Key, mandatory. Und ich brauche auch die Global Transaction Identifiers. Und hier schließt sich jetzt so ein bisschen der Kreis. Wie gesagt, früher war tatsächlich gewesen, Create Table as Select war kein Atomic Statement.
38:21
Dementsprechend konnte man das nicht mit den GTIDs verwenden. Das ist vorbei. Das ist Geschichte. Seit Juli kann ich das tun. Ein ganz häufiger Anwendungsfall ist Cloudera. Cloudera Admin Manager oder Cloudera Manager. Der Cloudera Manager läuft typischerweise auf MySQL. Das ist eine hochkritische Komponente. Kann man jetzt mit InnoDB Cluster auch sehr,
38:40
sehr einfach verwenden, weil wie gesagt, seit Juli diesen Jahres gibt es eben dieses Create Table as Select Statement als Atomic Statement. Dementsprechend gibt es jetzt soweit. Ich weiß keine SQL Statements mehr, die nicht in GTID ausgeführt werden. Und ich mache das sogenannte Raw Locking im Binary Lock. Und ganz, ganz wichtig, das ist der Unterschied zu der Replikation.
39:02
Die Netzwerkverbindungen zwischen den Clustermembers, die müssen super sein. Also perfekt trifft es eigentlich eher. In dem Moment, wo die Hickups haben, wo da Latenzen drin sind, dann ist auch mein Cluster langsam. Und unter Umständen fliegt mir auch mein Cluster auseinander. Das Netzwerk muss einfach super sein. Ende. Es gab einen Vortrag, ich weiß nicht, wer den gesehen hat,
39:21
von Uber auf der Vostem dieses Jahres, wo sie gesagt haben, also unsere Netzwerkverbindungen sind nicht ideal. Solange die alle drei gleich schlecht sind, ist es kein Problem. Da würde ich mich nicht drauf verlassen, sage ich ganz ehrlich. Also wir gehen bei dem InnoDB Cluster davon aus, dass das Netzwerk einfach perfekt ist. Also sage ich jetzt einfach mal, Cluster
39:40
in Frankfurt, in New York und in San Francisco ist aus meiner Sicht eigentlich zum Scheitern verurteilt. Weil alles irgendwie in einem Rack ist, oder ich sage mal zumindest latenztechnisch gesehen sehr, sehr nahe, ist es kein Problem. Dann werde ich immer gefragt, was ist die Latenz? Was geht? Was geht nicht? Es gibt kein Hardware diesbezüglich. Ich sage dann immer so, alles im Bereich von ein paar Millisekunden ist eigentlich noch ganz okay.
40:01
Aber immer dann, wenn es zweistellig im Bereich von Millisekunden wird, würde ich den InnoDB Cluster so nicht mehr verwenden. Gut, jetzt bitte ich einfach mal in den Chat kurz zu schreiben. Ich würde gerne die Live-Demo machen. ihr das seht, was ich jetzt hier mache. Kleinen Augenblick.
40:21
Also könnt ihr die MySQL Shell... Die ist sichtbar. Die ist sichtbar, okay. Gut, kleinen Augenblick. Wir bauen das an dieser Stelle jetzt mal auf. Wir rufen die Applikation auf. Die Applikation heißt Marius Demo. Das ist eine kleine Java Applikation.
40:44
Die gleich irgendwo läuft. Hier läuft sie. Die brauche ich jetzt ganz kurz. Die will ich jetzt ganz kurz pinnen. So, also das ist jetzt mein InnoDB Cluster. Im Moment läuft da noch gar nichts. Da laufen drei Systeme. Ihr werdet jetzt gleich sehen. Wir fahren die hoch und runter. Wir bilden jetzt den Cluster.
41:02
Ich habe hier Cluster 1, Cluster 2 und Cluster 3. Wie gesagt, im Moment läuft da diesbezüglich noch gar nichts. Das Erste, was ich machen muss, ist, ich muss tatsächlich sagen, okay, ich möchte diesen Cluster 1 konfigurieren. Dazu starte ich auf meinem System,
41:21
die MySQL Shell. Das ist jetzt ein anderes System. Das ist vollkommen egal, ob das lokal oder remote ist. Und sage, okay, bitte konfigurieren wir den Cluster 1, sodass der InnoDB Cluster aware ist. Man sieht schon, das ist der Stand eben nicht. Aber bitte nehmen diese Änderungen vor. Und ja, bitte starte dieses System auch für mich automatisiert. Man sieht schon,
41:41
der Cluster 1 an dieser Stelle wird jetzt gestartet. Der ist kurze Zeit nicht verfügbar. Ich mache das jetzt auch für meinen Cluster 2. Und ich mache das jetzt auch für meinen Cluster 3. So. Das ist alles, was ich tun muss. Meine Cluster-Instanzen sind jetzt schon vorbereitet. Das war der erste Schritt.
42:02
So. Was ich jetzt machen muss, ist, ich muss den Cluster tatsächlich aufbauen. Dazu verbinde ich mich jetzt auf mein erstes System, Cluster 1. Das ist aber ganz egal, von welchem System ich das mache. Und bilde jetzt tatsächlich meinen Cluster mit dem Befehl dba-create-cluster.
42:21
Man sieht schon, da passiert was in dem Bild. Und man sieht schon, der Cluster geht jetzt automatisch in diese blaue Box. Alles, was in dieser blauen Box ist, ist tatsächlich jetzt Bestandteil des Clusters. Das war der erste Schritt. So. Der zweite Schritt, vielleicht hat auch der eine oder andere diese Demo schon mal gesehen, ist, ich nehme diesen zweiten Cluster jetzt mit dazu.
42:40
So. Und jetzt sieht man aber den Unterschied. Ich hoffe, dass ihr es lesen könnt. Er fragt mich jetzt sinngemäß, dieser Cluster hat einen anderen oder dieser Member hat einen anderen Status wie der erste Cluster. Was soll ich tun? Soll ich den Increment dazu nehmen? Soll ich einen Clone machen? Und typischerweise sage ich hier dann immer, ja, mach einen Clone. Was heißt, ich ziehe mir jetzt eine Kopie von meinem ersten System, der bereits in dem Cluster ist,
43:02
rüber. Man sieht schon, da passiert jetzt ein bisschen feiltechnisch was. Der Server wird zum Neustart oder zum Ende hin dann nochmal neu gestartet. Und wenn das System jetzt verfügbar ist, in einer Sekunde, wird das mein Cluster-Member werden. Wie gesagt, dauert einen kleinen Augenblick. Und diesen Schritt werde ich dann auch gleich für meinen
43:22
dritten Cluster machen. Und man sieht schon, das ist jetzt ein Cluster-Member. Der erste Server ist mein Primary Server, mein Read-Write Server. Der zweite Server ist tatsächlich nur Read-Only. Und das Gleiche muss ich jetzt dann auch für meinen dritten Server tun. Auch das dauert an dieser Stelle wieder einen kleinen Augenblick.
43:48
dauert immer noch einen kleinen Augenblick. Dauert immer noch einen kleinen Augenblick.
44:01
Jetzt ist er aber gleich dabei. Das war es an dieser Stelle schon gewesen. Mein Cluster ist aufgebaut. Was jetzt noch fehlt, ist mein Router. Mein Router, das ist diese schwarze Box, wo im Moment diese drei Fragezeichen zu sehen sind. Und was ich jetzt an dieser Stelle mache, ich connecte den Router einfach zu dem Cluster,
44:20
sage Bootstrap. Ich nehme jetzt hier so aber 3. Das ist ganz egal, ob das 1, 2 oder 3 ist. Was heißt, dass die Metadaten des Clusters auf den Router übertragen werden und der Router die Konstruktion oder das Bild von dem Cluster weiß. Das geht relativ schnell. Ich brauche dazu nur das Passwort. Und last not least, starte ich meinen MySQL-Router.
44:41
Und in dem Moment, wo ich den jetzt starte, achtet mal bitte auf die drei Fragezeichen, wird mein Router die drei Fragezeichen ersetzt und er pointet im Moment auf den Read-Write-Server, was der Server Nummer 1 ist. So, jetzt nehmen wir hier mal Last dazu. Ich nehme da grüne Last dazu. Ich nehme rote Last dazu. Was heißt, da passiert jetzt ein bisschen was auf
45:00
meinem System und ich nehme auch die rote Last noch mit dazu. Das heißt, ich füge da Systeme ein. Typischerweise werden jetzt auf den ersten Server eingesetzt oder werden auf den ersten Server eingefügt und typischerweise werden sie von Server 2 und Server 3 gelesen. Mein Cluster läuft. Die Applikation verbindet auf den Router
45:21
und der Router verbindet in diesem Beispiel jetzt auf den Server 1, weil das der Read-Write-Server ist. Ja, und jetzt kommt natürlich die große Frage. Ja, was wenn? Ja, was wenn zum Beispiel dieser Server 1 jetzt, ja, ausfällt? Und jetzt mache ich einfach mal die Hardcore-Variante und sage einfach mal,
45:42
so, ich bute den jetzt einfach mal. Man sieht schon, ups, der Server fällt raus. Die Applikation, ich weiß nicht, wie zeitnah ihr das jetzt seht, ist für 2 Sekunden geblockt. 2 Sekunden ist der Default-Timeout, kann nicht konfigurieren. Ihr seht aber auch, der Cluster-Konstrukt hat sich automatisch geändert. Mein neuer Master
46:01
Server oder mein neuer Primary-Server ist der Server Nummer 2. Der hat einfach die niedrigste UUID gehabt. Könnte ich jederzeit ändern. Meine Applikation hat tatsächlich aber nur genau genommen für eine Sekunde oder für 2 Sekunden ausgesetzt. Das ist die Idee von dem InnoDB-Cluster. Genau dieses automatische Switchover, genau dafür ist der InnoDB-
46:21
Cluster gebaut. Das ist die Stärke. Das war jetzt ein Reboot gewesen. Das System wird gleich wieder hochkommen. Ihr werdet gleich auch wieder sehen. Der nimmt dann wieder an dem Member-System teil. Es ist jetzt ziemlich offensichtlich, dass da Änderungen gewesen sind. Das heißt, er hat jetzt erstmal versucht, die Änderungen auf Basis Binary-Logs nachzuziehen. Dadurch, dass das weniger als
46:41
1.000 Änderungen gewesen sind, hat er tatsächlich nur das Binary-Log abgearbeitet. Wäre das mehr als 1.000 gewesen, das ist ein Wert, den könnt ihr konfigurieren, hätte er tatsächlich auch erst wieder einen Clone von dem System gemacht, hätte die Daten geklont und hätte dann automatisch wieder an dem Cluster-Konstrukt weitergemacht. Genau das ist die Idee von dem InnoDB-Cluster. Genau das ist
47:01
die Stärke. Und jetzt muss man einfach entscheiden, was will ich in meiner Produktion? Möchte ich diesen Automatismus? Dann ist der InnoDB-Cluster gut. Ich muss wissen, a, ich brauche mindestens drei Systeme. Mit zwei Systemen geht es nicht. Und ich muss wissen, die Netzwerkverbindung zwischen diesen zwei Systemen, die sollte richtig gut sein, weil sonst mein Cluster sehr langsam ist. Und in dem Moment,
47:21
wo ich sage, na ja, ich kann eben nur mit zwei Systemen arbeiten, ganz, ganz, ganz häufig reicht das eben aus, kann ich das mit dem Replikaset auch machen? Ich muss halt nur wissen, in dem Moment, wo mein Primary-Server des Replikasets runterfällt, muss ich als Mensch oder als Skript, wie er es halt konfiguriert, die Replikationskonstruktion ändern und
47:41
könnte dann über diese geänderte Replikationskonstruktion auch automatisiert mit dem Router weiterarbeiten. Gut. Das war die Demo. Wer möchte, kann nachher noch an meinen Stand kommen. Da bin ich. Da können wir das gerne auch nochmal vertiefen. Ich würde gerne jetzt nur die Präsentation weitermachen. Ich hänge ein wenig hinterher in der Zeit.
48:02
Ich mach das jetzt aber relativ schnell. Das, was ich euch eben gezeigt habe, das geht schon eine ganze Zeit lang. Nichtsdestotrotz, auch hier ist natürlich die Technologie weitergegangen. Die Version by default, und wir können ganz schwer Defaults ändern an dieser Stelle, weil wir müssen immer die Kompatibilität
48:21
zu den alten Systemen gewährleisten, heißt, sie ist eventual consistent. Also wir haben hier das Bild, ich habe meine Applikation. Meine Applikation schreibt meine Daten in den Server B. Und in dem Moment, wo jetzt ein Read erfolgt auf dem Server A, sieht man schon, na ja, in meinem Log waren die Daten zwar enthalten, aber sie
48:41
sind eben noch nicht appliziert worden auf die InnoDB Engine. Das heißt, die Information existiert nicht. Das heißt, obwohl ich hier den Record abgedatet habe auf 1, andersrum, obwohl ich den Record hier abgedatet habe auf 5, vorher war er 1, bekommt meine Applikation 1.
49:00
Das kann ein Problem sein, je nachdem, wie ihr die Applikation schreibt. Jetzt müsst ihr aber auch dazu wissen, mittlerweile kann man das InnoDB Cluster konfigurieren. Wir haben verschiedene Consistency Levels, mittlerweile haben wir 4 Stück, oder 5 Stück glaube ich sogar, und je nachdem, was ihr hier haben wollt, könnt ihr dieses Verhalten konfigurieren. Also, es gibt 2 oder 3 relativ einfache, es gibt
49:21
einmal synchronized before execution, was sinngemäß heißt, ihr habt hier wieder die Applikation, die eine Update auf den Server P schreibt, die Information existiert im Log, und jetzt wird tatsächlich der Reply des Server asked zur Applikation, wir wissen ja, dass diese Transaktion in den Logs ist, die wird so lange zurückgehalten,
49:41
bis sie gegenüber der InnoDB Engine appliziert wurde, was heißt, entgegen der 1, was wir vorher bekommen haben, bekommt der tatsächlich jetzt den richtigen Wert 5. Das ist erstmal super, jetzt muss man tatsächlich im Hinterkopf behalten, ja, der Server hält die Antwort der Applikation so lange zurück, bis das alles appliziert wurde, das heißt,
50:01
das System ist ein bisschen langsamer geworden. Und genau das ist der Punkt, will ich es schnell, oder will ich es konsistent, also ich muss das eine und ich muss das andere machen, und da muss man einfach schreiben, wenn diese before execution zu langsam ist für euch, warum auch immer, dann braucht ihr entweder schnelleres Netzwerk, schnelleres System, schneller, schneller, schneller. Es ist jetzt immer eine Frage der Geschwindigkeit
50:22
und der Konsistenz. So, dann gibt es noch den zweiten, den verschärften Fall an dieser Stelle, synchronized after execution, was sinngemäß heißt, ich habe hier wieder meine Applikation, die Information wird wieder auf B geändert und tatsächlich warten wir jetzt aber, bis alle Informationen des kompletten Servers appliziert wurden, das heißt,
50:42
je nachdem, wie der Aufbau des Systems ist, kann das noch ein bisschen länger dauern, aber mit after execution ist gewährleistet, dass die Systeme zu jedem Zeitpunkt denselben Statusquo haben. Das ist wahrscheinlich das, wo ihr sagt, ja, das will ich haben, aber ihr werdet es wahrscheinlich schon wissen, das ist halt noch ein Ticken langsamer, also das Ganze ist hier ein trade-off zwischen
51:01
speed und consistency. In dem Moment, wo ich mit meine Applikation sowieso immer nur auf Server B arbeite, ist das vollkommen irrelevant. In dem Moment, wo ihr sagt, ich möchte aber auch Server A und C mit ins Boot nehmen, genau dann braucht ihr diese consistency levels. Und es gibt eine consistency levels, wie gesagt,
51:21
ich habe gesagt, es gibt 4 oder 5 Stück, die möchte ich ganz besonders noch ans Herz legen, das ist nämlich nicht der Status, das ist nicht der Default, before and primary failover, also wenn ein System überfällt, dann sollen erst die Logs abgearbeitet werden und dann soll weitergearbeitet werden. Jetzt sagt ihr wahrscheinlich, natürlich, das muss ja so sein, ja, das sehe ich ganz
51:41
genau so, allerdings hatten wir halt mit dem Release 5.7 vor einigen Jahren ohne diese consistency levels angefangen. Wir können die jetzt nicht einfach ad hoc in dem Release 18, 19, 20 ändern. Das heißt, ich würde euch empfehlen, before and primary failover, das sollte die default consistency sein, das ist aber nicht der Default, weil wir tatsächlich eine gewisse History
52:01
haben in dem Produkt und das nicht einfach ändern können. Gut, eine Änderung. Andere Änderung, ich bin in 5 Minuten fertig, dann gehen wir auf die Fragen ein. Andere Änderung, automatischer cluster rejoins. Ihr hattet es gesehen, ich habe das System eben ge-rebooted und ich sage mal nach einer Minute, das System hat es sich gebooted, ihr habt vielleicht ein Yam Update oder irgendwie ein MySQL Update gemacht, dann
52:22
kommt das System wieder automatisch mit rein. Das kann man mittlerweile sehr granular konfigurieren. Ihr könnt sagen, okay, ihr möchtet, dass ein Server dann automatisch draußen bleibt. Ihr möchtet, dass es 3, 4, 5 Mal in 1, 2, 3, 4, 5 Minuten versucht wird, diesen Member wieder mit auf den Cluster raufzunehmen. Das kann man sehr, sehr granular mittlerweile
52:42
konfigurieren. Ganz wichtig, aber in dem Moment, wo so ein Cluster rausfällt, ein Member rausfällt, dann dürfen auf diesem System keine Transaktionen mehr ausgeführt werden. Das passiert in der Praxis unter Umständen vielleicht schon, weil zum Beispiel der Connector irgendwie die Verbindung nicht betrennt hat oder weil ihr das forciert habt oder weil ihr irgendwelche externe Hardware
53:02
verwendet. Und deswegen, das kann ein Problem werden, aber auch hier gibt es mittlerweile ganz viele Möglichkeiten, das zu konfigurieren. Zum Beispiel könnt ihr sagen, in dem Moment, wo so ein Member den Cluster verlässt, dann ist der bei default offline. Was heißt? Der macht gar nichts mehr. Also das einzige, was der noch annimmt, sind irgendwelche Admin oder Super Privilege
53:22
Accounts, damit eben das System gefixt werden kann. Aber transaktionstechnisch bedient er keine Applikation mehr. Also auch wenn zu diesem Zeitpunkt noch eine Applikation auf dem InnoDB Cluster-System hängt, der kriegt keine Antwort mehr, weil nur noch der Admin-User zu dieser Zeit dann irgendwas machen kann. Das klingt ein bisschen hart,
53:40
allerdings, wenn es wirklich um die Konsistenz von den Datenbanken geht, und da geht es eigentlich immer darum, da ist es eine Key-Funktionalität und auch das kann man sehr, sehr granular konfigurieren. So, ich komme zum Ende. Last but not least, auch eine Funktionalität, die Anfang des Jahres eingebaut wurde. Ich habe jetzt mehrere Router. Ja, was ist denn,
54:01
wenn jetzt tatsächlich so ein Router nicht mehr konfiguriert? Wie komme ich denn von meinem Applikationssystem auf den Router drauf, wenn der nicht auf der lokalen Maschine läuft? Auch hier gibt es mittlerweile mehrere Möglichkeiten. Ich könnte zum Beispiel über ein Roundrobin-Verfahren in den Konnektoren definieren. Ja, also wenn halt Router 1 nicht verfügbar ist, dann gehe ich auf Router 2 oder Router 3.
54:21
Ich könnte allerdings auch DNS-SAV, das ist mit den allermeisten Routern mittlerweile konfiguriert und vor allen Dingen in Container, in Docker-Environments mit Kubernetes und OpenShift, ist das so mehr oder weniger der Status quo, wo ich tatsächlich den DNS-Service mit einem Service belegen kann und diesen Service-Status kann ich über die Konnektoren abfragen.
54:41
Das heißt also, diese MySQL-Router werden aktiv von, in diesem Beispiel ist es jetzt hier Konsul, andere SRV-Systeme gehen natürlich auch, gemonitort und geben den Status dann an die Konnektoren und dann weiter, wenn tatsächlich meine MySQL-Router-Systeme entsprechend konfiguriert werden. Ist eine Konstruktion, funktioniert sehr, sehr gut, vor allen
55:01
Dingen, wie gesagt, in Kubernetes-Environments, in OpenShift-Environments. Ich habe es weniger in, ja, nicht Kubernetes-Environments bis jetzt gesehen. Wir unterstützen ja noch nicht alle Konnektoren, die wir unterstützen. Ja, JDBC, ODBC, Python, NodeJS, C++, net. Wir sehen hier, wie gesagt, andere sind an dieser Stelle noch nicht alle unterstützt.
55:21
Das war so die Einführung in den InnoDB-Cluster gewesen. Hab vielleicht so ein bisschen im Hinterkopf, wann verwende ich Replikation und wann verwende ich InnoDB-Cluster. Replikation, Minimum zwei Server, InnoDB-Cluster, Minimum drei Server. Replikation, ich brauche kein Supernetzwerk. Das kann, ja, da können Latenzen dazwischen sein.
55:40
Das ist latenzunabhängig, gerade wenn es um Disaster Recovery Ansätze geht. Unter Umständen ein Riesenvorteil. InnoDB-Cluster ist einfach auf ein Supernetzwerk angewiesen. Natürlich hat InnoDB-Cluster ein bisschen eine höhere Komplexität. Allerdings kann man das über die MySQL Shell sehr, sehr einfach abfrühstücken. Es ist tatsächlich sehr, sehr einfach alles umzusetzen.
56:00
Und, ja, nehmt die entsprechende Abwägung vor. In meiner Funktion sehe ich ganz, ganz häufig, dass viele Kunden halt sagen, also drei Systeme, auch wenn das virtuell ist, auch wenn das Environments sind, das ist ein Overkill. Mir reicht die einfache Verfügbarkeit mit Replikation, auch wenn ich unter Umständen vielleicht ein paar Records verliere im Fehloberfall. Es gibt da keine pauschale
56:22
Antwort. Das ist eine der Gründe, warum wir auch die Replikation, die InnoDB- Replikase jetzt eingeführt haben, weil es einfach sehr, sehr wichtig geworden oder immer noch sehr, sehr wichtig ist, auch wenn es den InnoDB-Cluster gibt. Ich bedanke mich für Ihre Aufmerksamkeit. Wenn ihr das Thema vertiefen wollt, könnt ihr gerne zu mir an den Stand kommen. Ich habe allerdings in der Stunde schon
56:41
wieder den nächsten Vortrag. Da werden wir so ein paar Dinge auch nochmal besprechen. Ein paar Dinge werden sich überlappen. Von der Seite vielleicht einfach am Nachmittag dann nochmal vorbeischauen. Ich bin allerdings durch jetzt mit dem Vortrag und würde jetzt tatsächlich mal die Fragen, wenn es denn Fragen gibt, bearbeiten
57:00
wollen. Ja, im Moment sehe ich keine Fragen. Jetzt muss ich mal fragen. Moderatus, hast du irgendwelche Fragen bekommen? Nein, hier ist nichts angekommen. Nein, hier ist nichts angekommen. Okay. Also, wenn es noch Fragen gibt, einfach in den Chat reinschreiben.
57:22
Ich glaube, ich habe noch drei Minuten. Bleiben wir das zu lange noch in dem Chat drin? Oder musst du zumachen schon? Die drei Minuten gehen noch. Also, dann bleiben wir einfach bis zum Ende drin und wenn es Fragen gibt, entweder in den Chat schreiben oder wie gesagt, nachher dann kann ein Cluster-System durch Replikation
57:40
ergänzt werden. Sehr fantastisch gute Frage. Stand heute geht es nicht. Also, ich kann keine zwei Cluster-Systeme zum Beispiel über eine Replikation verbinden. Was ich machen kann, stand heute, ich habe einen Cluster und ich kann ein einzelnes System, also die Anzahl der Systeme ist hier das Wichtige, mit einer Replikation verbinden. Das heißt, ich habe, sag mal, in Frankfurt habe ich drei Systeme
58:01
und ich sag mal, in Hamburg habe ich ein einzelnes System. Die kann ich über Replikation verbinden. Aber wenn man mal eins und eins zusammenzählt, dann ist auch klar, dass diese InnoDB-Replikasets sehr bald, das ist halt die Idee, die wir dahinter haben, auch für Cluster angewendet werden kann. Das heißt, ich habe dann tatsächlich drei Cluster in Frankfurt, drei Cluster in Hamburg, drei Cluster
58:22
in Berlin und die werden über diese Replikasets genauso dann angesprochen werden, wie ich das mit Einzelsystemen mache. Dann die nächste Frage. Gibt es wesentliche Unterschiede, Vorteile, Nachteile zu Galera? Also, die darunter liegende Technologie Paxos ist zunächst erstmal identisch. Das heißt, das System funktioniert sehr, sehr, sehr, sehr ähnlich.
58:41
Galera hat keine Mencius-Variante. Die machen das ein bisschen anders. Was jetzt schneller und was langsamer ist, da gibt es ganz unterschiedliche Aussagen. Auf unseren Folien sind wir schneller, auf Galeras Folien ist Galera schneller, ist an dieser Stelle vielleicht klar. Ich meine, der große Vorteil ist, InnoDB-Cluster ist built-in. Also, ihr braucht keine Extra-Komponenten. Ihr könnt dieses Package so runterladen.
59:01
Das ist in allen MySQL-Systemen enthalten. Ihr habt die Standard-Konfiguration, ihr habt das Standard-Locking von MySQL. Es ist halt alles ganz smooth integriert. Ich kann mir vorstellen, ich habe Galera jetzt schon länger nicht mehr betrachtet, dass Galera ein bisschen agiler unterwegs ist, wenn es um neuere Funktionalitäten geht. Super agil können wir da nicht agieren, weil wir müssen gewährleisten,
59:21
dass die ganzen älteren Systeme eben auch noch geclustert werden können. Aber ich würde mal sagen, der große Unterschied ist tatsächlich an dieser Stelle, dass aus InnoDB-Cluster sich das alles in MySQL integriert ist, was bei Galera nicht der Fall ist. Das ist mehr oder weniger ein Parallelsystem. Auf der anderen Seite kann ich mir vorstellen, dass Galera die eine oder andere Funktion
59:42
schon implementiert hat, die wir vielleicht erst auf der Roadmap haben. Aber grundsätzlich ist es sehr, sehr, sehr vergleichbar. Die unterliegende Theorie ist genau dieselbe. Sie basiert eben auch auf Paxos.