MySQL Best Practices - In 8 Schritten zur optimierten Datenbank!
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 | 94 | |
| 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/45631 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201946 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
DatabaseMySQLOpen sourceRelational databasePresentation of a groupORACLSSocial classDatabaseEnterprise architectureXMLUMLComputer animation
02:09
Open sourceInformationRelational databaseRankingIBMMySQLFlock (web browser)Oracle <Marke>PostgreSQLData modelMultiplicationACCESS <Programm>MicrosoftSQL Server 7.0MULI <Programmiersprache>Search engine (computing)Open sourceDB2SQLPostgreSQLDatabaseComputer animationLecture/Conference
03:34
SQLPostgreSQLRankingMySQLIBMICONACCESS <Programm>Flock (web browser)User interfaceGRADEOracle <Marke>Buffer overflowStack (abstract data type)Archaeological field surveyORACLSStatistikerDatabaseMySQLBuffer overflowStack (abstract data type)BenchmarkOperating systemComputer animationLecture/Conference
04:31
Archaeological field surveyBuffer overflowStack (abstract data type)MySQLMySQLInformationStatistikerRoundingVarianceInternetLecture/Conference
05:50
Open sourceRankingData modelMULI <Programmiersprache>PostgreSQLMultiplicationMySQLSQL Server 7.0IBMMicrosoftACCESS <Programm>Oracle <Marke>SSLArchaeological field surveyBuffer overflowStack (abstract data type)Data dictionaryUnicodeSQLGastropod shellRouter (computing)DatabaseMySQLRoundingComputer animation
06:51
SQLMySQLRouter (computing)Data dictionaryUnicodeData modelGastropod shellPlug-in (computing)Set (mathematics)MySQLFacebookSun <Marke>Lecture/ConferenceComputer animation
08:03
SQLData dictionaryUnicodeMySQLData modelRouter (computing)Gastropod shellUnicodeVersion <Informatik>MySQLSet (mathematics)DatabaseORACLSMicrosoftMoment (mathematics)LinieRoute of administrationComputer animationLecture/Conference
09:54
SQLREASPlug-in (computing)Query languageMongoDBMySQLMySQLFunktionalitätPhysical quantityGraph minorWEBSoftware developerBlogPlug-in (computing)Query languageComputer animation
10:54
SQLREASOracle <Marke>FunktionalitätSet (mathematics)BefehlsprozessorMySQLPasswordIP addressPoint cloudClefDerived set (mathematics)Server (computing)File formatWordPressDrupalLecture/Conference
13:37
EncryptionTransport Layer SecurityMySQLMultiplicationOracle <Marke>FunktionalitätMultiplicationBefehlsprozessorOrder of magnitudeHypercubeTransport Layer SecuritySQLWeb pageBackupInternetMySQLEncryptionPhysical quantityServer (computing)Constraint (mathematics)Computer animationLecture/Conference
16:48
MySQLMySQLRoundingDatabaseORACLSComputer animation
17:46
Set (mathematics)MySQLORACLSLecture/ConferenceComputer animation
18:50
Oracle <Marke>EUMELMySQLServer (computing)Decision theorySystems <München>Computer animationLecture/Conference
20:55
High availabilityQuery languageCarriagewayComputer hardwareQuery languageMySQLComputer animationLecture/Conference
22:04
CarriagewayBlogStatement (computer science)Query languageLecture/Conference
23:04
CarriagewayQuery languageVirtualizationPoint cloudMySQLIndexCarriagewayQuery languageMySQLVirtualizationHigh availabilityOperating systemMETAL <Programm>Computer animationLecture/Conference
24:35
LINUXVirtualizationPoint cloudMySQLOracle <Marke>FreeBSDLINUXLimit (category theory)Open sourceOperating systemORACLSLecture/ConferenceComputer animation
25:46
LINUXPoint cloudVirtualizationMySQLStructural loadBefehlsprozessorSingle-precision floating-point formatHauptspeicherVirtualizationCore dumpIndexDatabaseComputer animationLecture/Conference
26:37
Oracle <Marke>Empirical distribution functionSQLDatabaseOperating systemHauptspeicherLecture/Conference
28:57
TuningMySQLLINUXOperating systemTable (information)Computer animation
29:44
TuningMySQLOracle <Marke>ZugriffLimit (category theory)Route of administrationGrand Unified TheoryOperating systemLecture/ConferenceComputer animation
31:45
MySQLLINUXVersion <Informatik>Oracle <Marke>Service PackComputer animationLecture/Conference
32:56
MySQLLINUXVersion <Informatik>UnicodeComputer animation
33:45
MySQLLINUXOracle <Marke>Software bugRoute of administrationDefault (computer science)CentOSDemosceneSoftware repositoryLINUXMassLecture/Conference
35:43
Set (mathematics)MySQLConfiguration spaceComputer hardwareParameter (computer programming)SAP <Marke>Workstation <Musikinstrument>Set (mathematics)Computer animation
36:33
MySQLConfiguration spaceComputer hardwareComputer hardwareClefOperating systemVariable (mathematics)MAX <Programm>Point cloudLecture/Conference
37:22
Router (computing)Default (computer science)Instanz <Informatik>Route of administrationSystems <München>Router (computing)Proxy serverZugriffMassComputer animation
38:36
EmailServer (computing)MySQLOracle <Marke>HauptspeicherVariable (mathematics)Computer animationLecture/Conference
39:41
makeDefault (computer science)Computer data loggingCache (computing)MietserverReading (process)Hard disk driveFactorizationVariable (mathematics)AutomatonDefault (computer science)EckeOperating systemMySQLHauptspeicherPoint cloudRoute of administrationServer (computing)PlatteBeta functionComputer animation
43:33
MySQLOracle <Marke>ACIDDefault (computer science)Operating systemError messagePublic key certificateMainframe computerInformationIP addressCMSMySQLORACLSHauptspeicherDefault (computer science)MicrosoftDatabaseLogarithmUpdateLecture/ConferenceComputer animation
45:59
Server (computing)DNS <Internet>Oracle <Marke>Default (computer science)MySQLThread (computing)BefehlsprozessorCarriagewayConcurrency patternDNS <Internet>Thread (computing)BlogBefehlsprozessorLecture/ConferenceComputer animation
46:48
Default (computer science)MySQLThread (computing)CarriagewayBefehlsprozessorBefehlsprozessorTracing (software)MySQLFactorizationComputer animationLecture/Conference
47:42
Oracle <Marke>DisplaySQLGastropod shellMySQLAdaptive behaviorSystems <München>MySQLGastropod shellSet (mathematics)Client (computing)FunktionalitätJavaScriptComputer animationLecture/ConferenceSource code
48:50
MySQLVariable (mathematics)Oracle <Marke>Independence (probability theory)High availabilityRouter (computing)Structural loadStatement (computer science)Lecture/ConferenceComputer animation
50:20
Oracle <Marke>InformationServer (computing)Systems <München>Lecture/Conference
51:33
MySQLGastropod shellRouter (computing)BackupCarry (arithmetic)Systems <München>Statement (computer science)Server (computing)MySQLRouter (computing)Computer animation
53:10
MySQLRouter (computing)Gastropod shellOpen sourceUser interfaceSystems <München>Server (computing)Route of administrationMySQLGastropod shellClefLecture/ConferenceComputer animation
54:30
DisplayMySQLCodeGlass floatWorld Wide WebTelephone number mappingInterior (topology)Gastropod shellSQLDatabaseSQLZugriffFunktionalitätMySQLData storage deviceTable (information)Lecture/ConferenceXMLComputer animation
55:22
SQLACIDLimit (category theory)Oracle <Marke>JavaScriptEncryptionSystems <München>Table (information)MySQLAsset <Informatik>ZugriffSQLLecture/ConferenceJSONComputer animation
56:12
SQLJavaScriptACIDMySQLInformationACCESS <Programm>EncryptionClefMaster KeyPlug-in (computing)Master KeyClefPlug-in (computing)Mainframe computerData centerMIKE <Programm>MySQLServer (computing)Local ringAsset <Informatik>PlatteComputer fileTable (information)Computer animation
58:43
AuthenticationEncryptionLimit (category theory)MySQLSoftware repositoryDatabaseSoftware repositoryMietserverServer (computing)Data centerAsset <Informatik>Computer animation
59:46
AuthenticationEncryptionOracle <Marke>Lecture/Conference
01:00:37
openSUSEXMLComputer animation
Transcript: German(auto-generated)
00:07
Zunächst erstmal hallo, mein Name ist Carsten, Carsten Thalheimer, ich arbeite für die Oracle, ich bin für das Thema Meisterial zuständig, einige von euch kennen mich auch schon, es ist jetzt auch mal das erste Mal, dass ich auf der Frostcom präsentiere, schauen wir mal.
00:21
Ich beginne ja meine Präsentation immer mit so einer kleinen Geschichte und dieses Mal hat das zu tun bei mir mit einem Klassentreffen. Man kommt ja jetzt doch in das Alter, dass man sich dann auch von der Klasse hin und wieder mal trifft und zur fortgeschrittenen Stunde auf den Klassentreffen diskutiert man natürlich auch was machst du dann beruflich? Und ich habe eine Kollegin bzw. eine Schulkollegin, die nach Amerika gegangen ist
00:41
und die hat mich so gefragt und dann sage ich ja, ich arbeite für Oracle und dann hat sie gesagt, sie arbeitet wie gesagt auch in Redwood Shores, sagt sie oh Oracle, das kenne ich und hat mir also ich sage mal innerhalb von Sekunden die Passwörter, die ich normalerweise in einem Monat in der Oracle höre eingetrichtert, Autonomous und 19 und Enterprise Manager und so weiter und so fort
01:00
und dann ist immer der Punkt, wo ich sage ja, ich mache diese andere Datenbank in der Oracle und dann hat man also schon so eine gewisse Skepsis in dem Gesicht gesehen und wo ich dann gesagt habe, ja also ich mache MySQL, dann war das Gesicht eigentlich tendenziell eher so ein bisschen bemitleidenswert und wo ich dann gesagt habe und ich bin unter anderem für den afrikanischen Kontinent da,
01:23
also ich sage mal das Gespräch war nicht zu Ende, aber es war dann schon ziemlich eingeschränkt und das ist so die Welt, in der ich lebe. Also ich mache auch relativ viele Präsentationen innerhalb der Oracle und wenn man dann sagt MySQL, da ist immer erstmal so eine gewisse Skepsis da. Von der Seite alles, was ich jetzt so präsentiere,
01:41
vielleicht auch so ein bisschen um in diesem Aspekt zu sehen, ich muss das stellenweise auch bei der Firma Oracle verkaufen und dann kommen wir gleich drauf. Ich hatte dann mit Susan, so heißt die Dame, gesprochen, habe ich gesagt du, du weißt ja schon, dass da einiges sich geändert hat die letzten Jahre. Also wie gesagt, ich bin jetzt auch noch mal der Allerjüngste
02:00
und da gibt es diese Studie. Ich weiß nicht, ob die irgendeiner schon mal verwendet hatte hier auf dem Vortrag. Ist nicht von Oracle, ist von Gartner. Die kann man leider nicht einsehen, die ist sehr teuer diese Studie, hat irgendwie 400, 500 Dollar gekostet oder so. Aber auf alle Fälle haben die das damals untersucht, damals war 2015 und haben ihm gesagt, naja, also 2018, der Open Source Datenbankmarkt,
02:24
das wächst, das boomt, das blüht. Und ja, 70 Prozent oder was haben sie gesagt, werden wahrscheinlich dann im Open Source Markt sein. Eine mutige Ansage damals. Und wenn ich jetzt einen Realitätscheck mache und jetzt denke ich immer an meine Kollegin Susan, ja, ist das passiert, ist das nicht passiert? Und es gibt so zwei Folien, die ich, ich sag mal, aus Marketing
02:43
sich dann jetzt immer so präsentiere. Das einmal ist dieses DB Engines Ranking, die kennt der eine oder andere ganz bestimmt schon. Eine Firma in Österreich, nicht von dem Markus Wienernd, wo eben so gerankt wird. Also wie populär sind Datenbanken? Die haben dann da so einen magischen Score und diesen Score, den updaten die jeden Monat.
03:01
Das ist jetzt der Score von diesem Monat, vom August. Und ich mach's mal ganz kurz. Die Welt ist mehr oder weniger aufgeteilt in fünf Datenbanken. Ja, also Oracle, MySQL, Microsoft, Postgres und Mongo. Und ja, es gibt andere Datenbanken. DB2 und SAP HANA und Maria und was weiß ich alles gibt es. Realistisch betrachtet in diesem Rank,
03:21
ob der jetzt richtig ist oder falsch, lassen wir einfach mal dahingestellt, spielen sie erstmal keine Rolle. Mein Punkt an dieser Stelle ist, also MySQL, auch innerhalb der Oracle, uns geht's da schon ganz gut und wir sind nach wie vor sehr populär. Das hatte ich dann auch der Susan gesagt. Weiß nicht, das ist ja ein österreichischer Benchmark, dem trauen wir ja schon gar nicht.
03:42
Okay, aber es ist de facto so. Übrigens, immer wenn ich auf Referenzen, auf Statistiken oder sonst irgendwas verweise, die Folien werden ja irgendwie geteilt oder ansonsten mir einfach eine Mail schicken, kann man im Internet nachlesen. Das ist nix von Oracle oder sowas. Gut, dann gibt es eine zweite Untersuchung, die ist jetzt tatsächlich aus Amerika.
04:01
Stack Overflow kennt denke ich ja auch jeder. Und die fragen also so alle Jahre mal nach, wie viel Gehalt, welche Datenbanktechnologie, jeweils das Betriebssystem und so weiter und so fort. Und die fragen halt seit vier Jahren, glaube ich, jetzt auch nach Datenbanken. Und das ist ganz interessant. Auf dieser Folie stehen wir nämlich ganz fantastisch gut da. Und das ist, wie gesagt, nicht erst seit diesem Jahr.
04:21
Die letzten drei oder vier Benchmarks waren sogar ein Tick besser noch gewesen. Aber mal ganz grundsätzlich MySQL wird verwendet. MySQL ist da und MySQL wird verwendet. Und diese Studie, die wir eingangs gesehen haben von Gartner, die ist tatsächlich realistisch. Okay, ich komme nochmal auf das Gespräch mit Susan zurück und sie sagt ja, okay, MySQL.
04:41
Dann kommt jetzt ein anderes Thema, da werde ich nicht größer drauf eingehen, das Thema Afrika. Und dann ist so einer meiner Lieblingssprüche, wo ich sage, weißt du eigentlich, dass Afrika etwa 200 Millionen mehr Mobilfunkanwände hat wie Indien? Und ein Ami kann das ja grundsätzlich erst mal schwer glauben, aber es ist so. Also kann man relativ einfach nachlesen.
05:00
Und in vielerlei Hinsicht sind uns die afrikanischen Länder einfach voraus. Wenn man solche Dinge sieht wie MPSA, so Bezahlsysteme und so, aus europäischer Sicht sind wir da lange nicht, wir machen das anders. Nichtsdestotrotz, die machen auch viel mit Datenbanken, die machen sehr, sehr viel mit MySQL und das geht da genauso.
05:20
Ich glaube überzeugt habe ich sie nicht, aber Mai muss ich auch nicht, ist eine Schulkollegin, aber vielleicht mal so als grundsätzlicher Hintergrund. Wie gesagt, auch hier die Studie einfach im Internet dann nachsehen. Vielleicht noch mal eine Information zu diesen Statistiken. Also ich nehme die auch, nicht nur die, ich nehme noch viele andere eben auch. Man muss da sehr aufpassen.
05:41
Also wie gesagt, sowohl die erste als auch die zweite, ich weiß nicht ganz genau wie die sich zusammensetzen, da sind Varianzen drin. Also ich frage jetzt einfach mal ganz blöd dann auch in die Runde. Wenn ich so viel Grün sehe, also mal so reingefüllt, das ist ja ein absoluter Punkt, da müsste ja das Grüne gleich dem Roten sein, da gibt es noch viel mehr Datenbanken drunter. Das ist es aber nicht, das kann ich zum Beispiel nicht erklären.
06:02
Aber so what? So detailliert bin ich an dieser Stelle dann da auch nicht. Gut. Wir reden über MySQL und wir reden über Basis-Setups von MySQL, so wie ich sie machen würde. So wie ich sehe, wie es Kunden machen sollten. Und ich gehe dann so ein bisschen darauf ein, was sollte man da ändern.
06:21
Es gibt so eine Sache, das habe ich jetzt vorne dran geschoben, ich glaube das stand nicht im Ausschreibungstext drin, aber wir sind jetzt auch so oft gefragt worden, jetzt mache ich es einfach in der offiziellen Runde auch. Also seit letztem Jahr, seit April des letzten Jahres, ist MySQL 8 die letzte Datenbank, bzw. das letzte GR-Release. Also zwischen 5.7 und 8 gab es nichts. Wir hatten ganz viele Fragen wegen MySQL 7 gehabt.
06:43
Das gibt es nicht. Es gibt MySQL 5.7 und es gibt MySQL 8. Auch bei unserem Mitbewerb gibt es keinen MySQL 7. Also von der Seite, ich weiß nicht wo die Frage her kommt, da müsste man einfach im Detail nochmal gucken. So, MySQL 5.7, das war das vorhergehende Release, war mehr oder weniger statisch.
07:01
Also das waren die Funktionitäten, die hatten wir eingebaut, wo das Produkt GR ging. Dann kam dann irgendwann nochmal der EnoDB Cluster, auf den komme ich auch nachher nochmal zurück, da hat sich eine ganze Menge dann auch nochmal geändert. Als Plugin wurde das ausgeliefert, das kam 2017, 2016, 2017. Ja und wie gesagt im letzten Jahr kam dann eben MySQL 8.
07:21
Und es geht jetzt nicht explizit um MySQL 8, aber so ein paar Dinge sollte man wissen, was sich geändert hat. Also zu allererstem sollte man wissen, das ist auch eine Frage, die habe ich einfach dazu gefügt, weil ich bin sie zwei, drei Mal gefragt worden. Also lizenztechnisch hat sich in MySQL 8 nichts geändert. Also MySQL 5.7 und auch die vorhergehenden Release und auch die in der Sun und auch die in der MySQL waren immer unter der GPLv2.
07:41
Lizenztechnisch war da keine Änderung. Wir können es gerne am Stand irgendwie diskutieren, es war keine Änderung. Also wie gesagt, man kann das sehr, sehr einfach nachvollziehen. Und dann gab es, ich sage mal, so drei große Änderungen in MySQL 8, die sollte man einfach kennen. Diese erste Änderung ist das native data dictionary. Da geht es primär um das Thema der Skalierung.
08:01
MySQL wird ja von sehr großen Firmen eingesetzt, also Facebook und Booking und Tencent und viele andere eben auch. Die haben sehr, sehr große Datenbanken, die haben sehr, sehr viele Skalierungsrequests. Und da ist man an einen Punkt gekommen, auf dem werden wir nachher auch nochmal kommen, wo man gesagt hat, über diesen Punkt kann man nicht hinausgehen. Also alles, was so im Bereich von 200.000, 300.000 Tables ist,
08:20
das ist eine ganze Menge, gar keine Frage. Da wird es sehr, sehr schwer mit MySQL Version 5.7. Deswegen das data dictionary über diesen Punkt kann man jetzt relativ einfach hinweggehen, entweder auf Basis der Tables oder auf Basis der Connections. Wir kommen nachher nochmal drauf. Der zweite Punkt ist Unicode 9. Da hatte ich gestern auch eine Frage dazu gehabt und da hatte dann der Kollege
08:40
gesagt, naja, das ist ja keine große Sache. Also ich sage mal, als Anwender sich das zu ändern, ist das bestimmt keine große Sache. Aber wenn man sich mal überlegt, dass wir tatsächlich die Daten nativ in dem Format ablegen und was da drunter alles geändert wurde, also da sind mehrere Dutzend Entwickler dran gewesen, über viele, viele, viele Jahre. Das native data dictionary wurde in dem ersten Beta, in dem ersten
09:00
Alpha Release 2013, 2014 Release. So lange hat es gedauert. Das war ein riesen Aufwand für uns gewesen. Wir kommen dann auch nachher nochmal, wo die Vorteile sind. Es ist in erster Linie in der Performance zu sehen. Aber auch hier, das war eine sehr, sehr große Änderung. Viele sagen, kennen wir alter Hut, Postgres, Microsoft. Naja, also wir sind nicht Postgres, wir sind nicht Microsoft. Wir sind auch nicht Oracle Datenbanken. Wir sind
09:20
halt nur mal MySQL. Und für uns war es eben eine große Sache. Und da stecken sehr, sehr viele Entwicklungsressourcen drin. Und last not least, NoSQL Document Store. Auch da komme ich nachher nochmal kurz drauf zu sprechen. Es geht in erster Linie darum, dass ich auf MySQL zugreifen kann über Nicht-SQL-Formate. Das ist ein großes Thema. Viele, viele Datenbanken sind da sehr erfolgreich unterwegs.
09:40
Ich hatte eingangs erzählt Mongo. Mongo ist wieder mal die schnellstwachsendsten Datenbank im Moment. Die haben immer solche Verläufe. Ich weiß auch nicht, wo das herkommt. Aber wie gesagt, das ist einfach ein relevantes Thema. Da kommen wir dann auch nachher nochmal drauf zu sprechen. So, jetzt gab es eine große Änderung seit MySQL 8. Das sogenannte Continuous Delivery Model.
10:01
Wir haben die Entwicklungsstrukturen dahingehend geändert, dass wir mit neueren Miner-Releases Funktionalitäten nachziehen. Das war im MySQL 5.7 so nicht. Deswegen bei 5.7, das kam so raus. Es stimmte auch zwei, drei kleine Änderungen. Aber im Großen kamen da keine Funktionalitäten dazu. Und das hat sich jetzt geändert. Letztes Jahr, mit 8.11 sind wir rausgegangen. Dann kam das Release 8.12.
10:22
Das ist jetzt einfach mal so, wo ich gesagt habe, da bin ich drüber gestolpert, da war Kundeninteresse. Es gibt noch viel mehr. Das kann man alles nachlesen. MySQL-Server-Theme.com Das ist der Blog von den Entwicklern. Da steht es im Detail drin. Die erste große Änderung war dieses Instant Add Column. Das hat es nicht geschafft, würde ich mal sagen. Und dann haben sie es eben nachgezogen.
10:40
Dann Query the Rewrite Plugin. Das ist auch nichts Neues. Das konnte aber in älteren Releases immer nur Select machen. Kein Insert, kein Uptit, kein Delete. Da werden wir nachher dann auch nochmal darauf zu sprechen kommen. Das kann unter Umständen sehr, sehr wichtig werden für Sie. Dann das Release 13. Man sieht vielleicht dann schon zukünftig, also alle drei Monate kommt ein neues Release.
11:01
So Pi mal Daumen. Mal eine Woche später, mal eine Woche früher. Aber kann man relativ einfach nachlesen. Wenn man auf Oracle CPU Critical Patch Update Days guckt, kann man relativ genau sagen, so plus, minus ein paar Tage kommt das nächste MySQL raus. Die große Änderung in 13 waren zunächst erstmal SQL Functional Indexes. Das war eine Ableitung von Generated Columns. Das konnte man mit Release 57
11:22
auch. War ein kleiner Mehraufwand gewesen. Ist jetzt eine Funktionalität. Eine große Sache will ich nicht sagen. Aber Primary Keys ist eine wichtige Sache. Wir werden bei dem Cluster danach drauf zu sprechen kommen. Und ganz, ganz, ganz, ganz häufig kann der InnoDB Cluster nicht eingesetzt
11:40
werden, weil es keine Primary Key gibt. Also diese ganzen Diskussionen über Drupal und Wordpress und, und, und, und können wir gerne in diesem Teil machen. Bei Design sollte das Problem nicht auftreten und dann gibt es diese Extensions. Und diese Extensions werden im Regelfall geschrieben ohne Primary Keys und damit fällt der Cluster weg. Ist ein Problem. Kann man jetzt forsen, ohne Primary Key keine Table.
12:01
Es ist einfach zwangsbeatmet, sage ich mal. Gut, dann Mongo. Da kommen wir bei dem Thema des Documents. Da ist nachher nochmal drauf zu sprechen. Man kann Basen, man kann andere Formate relativ einfach implementieren. Kann man einfach importieren. Zeigt vielleicht auch so ein Stück weit, wo MySQL hin will. Man kann mit mehreren Adressen jetzt auf Binds arbeiten. Das ist vor allen Dingen für die wichtig, die in der Cloud
12:21
unterwegs sind. Man hat sehr oft mehrere Interfaces und man versucht tatsächlich dann eben nicht nur an eines. Das könnte man ja mit dem alten Release auch machen. Und nicht an alle. Das könnte man mit dem Release auch machen. Aber wenn ich vier Interfaces habe, möchte ich mich zum Beispiel nur an zwei Interfaces binden. Eine relativ wichtige Sache für die, die irgendein Cloud Anbieter unterwegs sind. Die werden das bestimmt mögen. Dann kam das Release
12:43
8.14 im Januar diesen Jahres. Die große Funktionalität war die sogenannten Consistent Reads gewesen. Consistent Reads für den NBB Cluster. Kommen wir nachher drauf zu sprechen. Da war auch wieder eine ganze Menge mehr drin. So mal rein aus der Praxis. Das wichtigste für mich war das Two Active Passwords.
13:02
Das Problem ist, ich habe ein Cluster oder ich habe eine Replikation. Und man soll Passwörter ja regelmäßig ändern. Wie will ich denn die Passwörter ändern ohne die Replikation oder den Server zu stoppen? Das geht nicht. Jetzt mit zwei Active Passwords definiere ich ein altes neues Passwort und kann die Passwörter im Betrieb ändern, ohne den Cluster oder die Replikation zu stoppen.
13:21
Ich kann das tatsächlich Continuous weiter betreiben. Wichtiges Sache. Dieses 8.14 Release war nur begrenzt populär gewesen bei uns. Weil da war ein Bug drin. Und zwar ein ganz blöder Bug. Also da haben wir wohl gepennt. Und zwar, wenn ich IPv6 eingeschaltet habe, ist der Cluster nicht mehr gegangen.
13:42
Und das war so signifikant, dass man gesagt hat, ok, wir sind ja immer noch im Januar 2019, da schieben wir mal ganz schnell ein anderes Release nach. Also kein IPv6, kein Problem, aber manche Kunden verwenden es halt nun mal und denen ist eben dann der Cluster runtergefallen. Das war nicht so schön gewesen. Von der Seite ok, es wurde nachgeschoben, deswegen gab es da keine Funktionalität, außer
14:01
dass dieser Bug behoben wurde. Gut, dann ging es weiter. Im April dieses Jahres erchecked Constraints. Der Markus Wienert hatte gestern in seinem SQL-Vortrag auch drüber referiert. Ja, ok. Ich sag mal, wir haben es jetzt auch 20 Jahre lang ohne gemacht, aber jetzt ist es halt eben da. Für mich an dieser Stelle ganz wichtig, wir kommen bei der Security noch mal drauf zu sprechen, Encryption of MySQL
14:21
Tablespace, also alles das, was MySQL selbst braucht, um sich selbst zu verwalten. Zum Beispiel die eigenen Benutzer können eben jetzt auch als Tablespace mitverschlüsselt werden. Support of TLS 1.3 ist noch nicht forciert in irgendwelchen Regularien, zumindest keine, die ich kenne. Nichtsdestotrotz, es gibt ja den Begriff des zu sicheres nicht, also von der Seite ist das eine gute Sache.
14:43
Nonplugging, CRP ist eine Funktionalität, die Facebook Contributed hat, die einen relativ großen Hype drum gemacht haben. Es geht einfach darum, wenn ich eine Webseite habe, die wird ja aus sehr vielen Queries zusammengebaut und ich möchte die eben jetzt nicht seriell, sondern in parallel abarbeiten, wenn möglich, das kann ich jetzt machen. Also Webseiten zur
15:01
Zusammenbauung geht mit so einem CRPI zum Beispiel deutlich schneller, in der Größenordnung 30-40%, ok, wer es braucht. Dann Release 17 vom Juli des letzten Jahres, auch eine große Funktionalität, ja, Wishing by Cloning. Ich habe ein System und ich kann dieses System jetzt einfach klonen. Da gibt es
15:21
noch nicht sehr viel im Internet drüber, so blogtechnisch oder auch Videos und so. Das ist eine riesen Sache. Darf ich mal fragen, wer betreibt MySQL? Und wer von denen, die MySQL betreiben, sichert die Daten mit Backup? Wahrscheinlich alle, behaupte ich mal.
15:41
Ok, das Problem mit dem Backup ist ja unter anderem, es ist relativ teuer, wenn es um die CPU geht und vor allen Dingen, wenn es um den Restoreprozess geht, das dauert relativ lange. Mit diesem Cloning, also mal ganz ehrlich, wir zählen mal eins und eins zusammen, ja, also ich streame die Daten irgendwo weg, mache da irgendwie einen Kompress drauf und wenn ich es brauche, mache ich einen Ankompress und mein Server ist da.
16:01
Also dieses Cloning wird mit Sicherheit ganz ganz ganz häufig zum Backup-Zwecken missbraucht werden und ganz ehrlich, das funktioniert relativ gut. Einfach mal ausprobieren, im Produkt ran. Eine andere große Sache, Multi-Value-Indexes, jetzt muss ich einschränken sagen, Multi-Value-Indexes für Chasen-Data. Das wird auch für andere Funktionalitäten nachgezogen, aber das brauchen wir primär für den
16:22
Document Store. Da sind wir heute. Es wird weitergehen, jetzt sind wir im Juli, das nächste Release wird dann im Oktober sein und das Release danach wird im Januar sein. Wir geben das, was wir da announceen oder das, was wir da bekannt geben möchten, nicht offiziell bekannt, aber wir können einfach am Stand darüber mal reden, ob es bestimmte Anforderungen gibt.
16:41
Das wird so weitergehen. Gut, dann mache ich an dieser Stelle jetzt auch einen Break mit MySQL 8 und komme zu meinem eigentlichen Vortrag. Es geht ja eigentlich um Best Practices. So, jetzt ganz viele von Ihnen betreiben MySQL schon, habe ich festgestellt. Von der Seite gehe ich davon aus, sie haben auch ein gewisses Wissen, gewissen Erfahrungsschatz. Schauen wir mal, ich werde öfters
17:00
jetzt mal was fragen in der Runde. Aber ganz grundsätzlich geht es also darum, ich habe MySQL, viele verändern da gar nichts und die betreibende Datenbank. Das kann man machen. Ganz klar. Und solange ich keine Probleme habe, ist das auch super. Nur, was in der Regel meistens irgendwann mal passiert,
17:20
ich habe ein Problem. Und dann ist wiederum so die Frage, okay, ist MySQL schuld oder keine Ahnung. Also viele von diesen Dingen, die eben passieren, kann man vorhersehen. Einfach anhand, wenn man mal in den Erfahrungsberichten liest, kann man ganz oft schon sagen, naja, das hättest du aber anders machen können. Wir machen das auch
17:41
von der Firma Oracle oder vom Community Team aus, sogenannte Health Checks. Wir kommen zu Kunden, gucken uns das dann an. Wenn sie da Interesse daran haben, einfach mal vorbeischauen. Na ja, und dann kommt jemand von Oracle oder ich und sagt, naja, also MySQL kann schon eine ganze, ganze Menge, aber sie verwenden es halt einfach falsch.
18:00
Genau darum soll es gehen, damit man diese großen Stolpersteine, die definitiv da sind, damit man die vorab filmt. Und ich bin jetzt auch nicht der 100%ige Tief-Techie oder ein Entwickler oder sonst irgendwas. Also ich versuche das relativ basis-technisch abzudecken. Wenn sie aber wirklich Interesse daran haben und sagen, naja, also das ist mir alles zu Lulli. Ich möchte wirklich wissen,
18:21
was geht. Wer kennt denn Dimitri Gravchuk? Vom Namen her, von der Vostem. Das ist der Leiter unseres Performance- und Skalierungsteams. Also der hat immer die Server, die jeder irgendwie gerne hätte, wo ich dann später mal lese im Internet, die gibt's. Die hat er im Regelfall zur Verfügung und dann guckt er,
18:40
was geht. Ein ganz, ganz, ganz fantastischer Kerl. Wer kennt noch so ein bisschen Solaris? Von früher, von so einem Microsystem? Ja, hasse. Dimstart. Er hat Dimstart entwickelt. Also daher kennt man ihn eigentlich. Gut, und wenn sie jetzt sagen, ja, ich bin da also wirklich interessiert dran. Der hat einen Vortrag auf der Vostem.
19:02
Das war angelegt für 45 Minuten. Nach 180 Minuten haben sie dann einen Heartbreak gemacht. Das ist die Folie dazu. Kann man sich angucken. Ich weiß nicht, wie relevant das für den alltäglichen Gebrauch ist, aber es zeigt eben, was man mit MySQL eben alles machen kann, wenn man dann die Server von ihm zur Verfügung hat, die ich nicht habe. Na gut, also das ist so dieser erste Vortrag.
19:21
Da habe ich auch ganz viele Bilder davon gestohlen, muss ich ganz ehrlich sagen. Und dann gibt's einen zweiten Vortrag. Ich gehe mal davon aus, den kennen nicht so viele. Das nennt sich Boring Technology von den Dan McKinley. Dan McKinley ist einer der Präsentatoren, wenn es um Wikimedia-Konferenzen geht. Die letzte war jetzt irgendwann in Amsterdam gewesen. Und ein ganz, ganz fantastischer
19:40
Präsentator. Und der betrachtet die Welt aus einer anderen Brille, die ich tatsächlich auch so irgendwie relativ oft aufhabe. Und der ganze Vortrag geht um einen Freund, den er hat, den Andy. Und Andy zieht immer dasselbe T-Shirt von der selben Marke an, jeden Tag. Und dann hat er ihn eben gefragt, Andy, warum machst du das? Und dann sagt er, naja,
20:02
also ich glaube, dass ein Mensch nur gewisse Innovation Credits pro Tag hat. Also er kann nur gewisse Anzahl von Entscheidungen richtig treffen. Und wenn er sich damit beschäftigen würde, was für ein T-Shirt er anzieht, wäre einer von diesen Credits schon weg. Und dementsprechend macht er das nicht. Klingt jetzt lustig und auf Basis von dieser Theorie baut er dann eben auf, dass er sagt, Leute, also das ist zwar cool, mit irgendwelchen
20:22
hochkomplexen Systemen zu arbeiten, aber wenn ihr es betreiben müsst, habt ihr ein Problem. Und genau darum geht es, kann man sich auch anschauen. Gibt es ein Video auch dazu. Ein super amüsanter Vortrag geht auch über anderthalb Stunden. Und da geht es eben darum, dass man sagt, verwendet existierende Technologien. Und im zweiten Schritt sagt er eben, Kiss, so einfach wie möglich.
20:42
Also das ist genau der Ansatz, den ich jetzt auch verfolgen werde. Ich versuche tatsächlich zu sagen, wie kann ich Meistergeld so einfach wie möglich für die möglichst vielen Anwendungsfälle abdecken. Das sind diese acht Schritte, die ich versuchen werde darzustellen. Wir fangen einfach mal damit an. Es gibt ja irgendwie diese
21:01
Erwartung, mit Hardware und Datenbanktuning, da erschlag ich alles. Unfug. Das wirkliche Problem, und denken Sie einfach mal an Ihre Anwendungsfälle, in den allermeisten Fällen ist das Query das Problem. Da kann ich Hardware technisch aufrüsten, was ich will. Eine schlechte Query ist eine schlechte Query, und die Antwort ist halt einfach langsam.
21:22
In meinem Vortrag geht es aber nicht um die Queries, sondern wir kümmern uns tatsächlich um das andere. Bevor ich groß weitermache, eine Sache, also so eine Query, ganz ehrlich, ich bin wie gesagt nicht der Entwickler vor dem Herrn, wo der Markus wieder immer gefragt hat, wer kennt das, wer kennt das, wer kennt das. Ja, vor 15 Jahren habe ich irgendwann mal einen Kurs dazu gemacht. In der Praxis
21:41
habe ich es halt nie gebraucht, schon gar nicht mit MySQL. Vieles war auch nicht verfügbar in MySQL. Aber ganz, ganz viel kann man wirklich relativ einfach lösen, wenn man einfach das Gehirn einschaltet. Ja, jetzt also mal ganz ehrlich, Klassiker, ich fahre zu einem Kunde, Telekommunikationsanbieter in Deutschland,
22:01
und er sagt, also bis 20 Verbindungen, 25 ist super, aber ab der 26 ist alles aus. Und da sage ich, Leute, ich bin mir nicht ganz sicher, ob das wirklich das Problem ist, weil so digital ist das einfach aus meiner Erfahrung nicht. Ja. Und dann bin ich also hingegangen und dann hat er mir seine
22:21
MyCNF gezeigt. Fantastisch. Also über vier, fünf Seiten, die Hälfte der Befehle habe ich noch nie gelesen, was da drin stand. Und dann habe ich ihn gefragt, was heißt das? Und er sagt, ja, das weiß ich auch nicht. Ich habe es von meinem Vorgänger geerbt. Schlechter Ansatz. Okay, dann haben wir gesagt, gut, wir lösen einfach mal alles raus, wir haben alles rausgelöscht, das Problem
22:41
war weg. Also ohne irgendwas zu machen, wäre es besser gelaufen. Gut, das war eine Sache von, ich sage mal, fünf Minuten. Es war eine relativ große Anfahrt für mich gewesen. Was machen wir anstatt dessen? Okay, gucken wir mal, was so querytechnisch abkommt. Ja, ist ja jetzt alles klar, die Performance ist super und brauchen wir jetzt alles nicht mehr. Slow Query Log, wir gucken einfach mal.
23:02
Und tatsächlich, ich sage mal für gefühlt 10, 20 Queries hat er nie einen Index verwendet. Da brauche ich wirklich kein Datenbank-Knowhow dafür. Also, wenn ich weiß, dass es Slow Query Log gibt, dass es Monitoring Tools gibt. Ich sage mal, die, die meistens kennen, verwenden Performance Schema oder das Schema oder ich verwende einfach die Workbench. Ja, da gibt es solche Dinge wie
23:21
Explain und Trace und Analyse. Ausprobieren. Und die Workbench hilft da wirklich weiter. Die Workbench ist auch ein kostenfreies Tool. Einfach mal gucken, was passiert. Also, diese ganz klassischen Show Variables, Show Status, damit erschlägt man ganz, ganz, ganz, ganz viele Probleme. Gut, darum geht es aber nicht in meinem Vortrag. Wir machen weiter mit
23:42
MySQL. So, jetzt fangen wir einfach mal mit ein paar Basics an. Also, ich möchte MySQL betreiben. Da gibt es also ganz, ganz viele, die sagen hey, nur bare metal. Ja, finde ich gut. Kann man machen. Hat Nachteile mittlerweile. Wenn es um das Thema Snapshotting von Betriebssystemen geht oder hin und her schieben.
24:01
Auch das Thema Hochverfügbarkeit kann man auf Basis von Virtualisierung relativ gut abbilden diese Tage. Also, kann man machen. Virtualisierung im Generellen, ja, KVN, VN, wäre jetzt mal ganz ehrlich. Wer betreibt denn MySQL nicht in einem von diesen Virtualisierungen, so der Container in Bayern? Also, wer betreibt wirklich MySQL bare metal? Wer macht's?
24:21
Na, okay. Drei, vier Stück. Okay. Also, wird zwar einen Grund haben, aber ganz ehrlich, ist rückläufig. Ja, also, die allermeisten Installationen, die ich sehe, sind tatsächlich virtuell. Und da spricht überhaupt nichts dagegen. Also, ich gehört tatsächlich zu denen, die sagen, also klar, ich hätte natürlich auch am liebsten alles für mich, aber das ist nicht die Realität. Sind wir mal ganz ehrlich. Ja, und wie gesagt, ich habe keine schlechten Erfahrungen
24:41
damit. Und auch dieses Thema Dockr und Kypanet, es gibt tausend Artikel, warum man es nicht machen sollte. Sind wir doch mal ganz ehrlich, das funktioniert relativ gut. Also, wie die es einsetzen, habe ich noch nichts Schlechtes gehört, aber ich lasse mich da gerne überraschen, wenn einer was weiß, einfach nachher mal vorbeikommen. Dann Betriebssystem, auch eine ganz tolle Diskussion.
25:02
Linux, klar. Letztes Jahr war einer von FreeBSD da, der sagt, FreeBSD, das ist es. Und dann gibt es auch immer welche, die sagen, Microsoft, das ist es. Ganz ehrlich, vollkommen egal. Wir sind jetzt hier auf einer Open Source Konferenz, das sage ich auch natürlich, hier machen sie Linux, aber ganz ehrlich, wir können auch in das andere
25:21
Betriebssystem nehmen. Wenn es um wirklich Höchstskalierung geht, hat Linux Vorteile, aber auch hier ganz, ganz, ganz viele gehen an diese Limits überhaupt nicht dran. Von der Seite ist es eigentlich egal, aber ich sage jetzt einfach mal, Linux ist okay. Und welches Linux Sie verwenden? SUS, Ubuntu, Debian, so what? Ich muss natürlich, ich werde ja auch gefilmt, also
25:41
Oracle Linux ist natürlich das Beste. Okay, gut. Dann CPUs. Ja, je mehr CPUs ich habe, wenn ich entsprechende Last habe, desto besser. Aber viel wichtiger ist es eigentlich, dass diese Single Strap Performance, dass die schnell ist. Also schnell getaktete CPUs, gerade für Single Queries, ist nach wie
26:02
vor noch ein Vorteil. Wenn dann irgendwann Parallel Query Execution, wenn das funktioniert, mag das alles da hinfällig sein, aber Stand heute ist das tatsächlich so. Wenn ich die Wahl habe, schnelle CPUs mit wenigen Cores, oder viele Cores mit weniger, mit wenigen Megahertz, dann würde ich tatsächlich eher die vielen Megahertz bevorzugen. Muss man einfach wissen. Ganz oft
26:21
hat man ja jetzt auch bei Cloud, bei Virtualisierung gar nicht mehr die Auswahl, aber sollte man einfach wissen. Ja, Arbeitsspeicher. Relativ einfach. Je mehr, desto besser. Gehen wir noch im Detail darauf ein, aber je mehr, desto besser. So einfach. Wenn die ganze Datenbank mit Index im Arbeitsspeicher ist, dann geht es auch nicht mehr schneller. Aber ganz ehrlich,
26:40
so Datenbanken haben mittlerweile auch ein paar hundert Gig oder ein paar Terra und so viel Arbeitsspeicher kriegen wir typischerweise nicht. Und deswegen ist die Aussage grundsätzlich schon richtig. Je mehr, desto besser. Disks. Ja, vor drei Jahren gab es einen Vortrag. XFS versus X4 versus was weiß ich. Klar, da gibt es Unterschiede.
27:00
Bin ich vollkommen bei allen. In der Realität ist es unrelevant. Für mich ist es mittlerweile unrelevant geworden. Was für ein Fallsystem ich verwende. Und ob das jetzt wirklich ein Single-SSD oder ob es ein Ray-10 ist, oder was weiß ich. Klar, gibt es theoretische Vorteile. Ich referenziehe hier auf den Chris Köhntub von booking.com, der gesagt hat,
27:22
Leute, das was eine SSD macht, nutzt ihr aus maskuelle Sicht eh nicht mehr aus. Und da muss ich sagen, da hat er recht. Und von der Seite, klar, je mehr, desto besser und je schneller, desto besser. Aber die Unterschiede in der Performance und vor allen Dingen in der Applikationsperformance, das ist ja eigentlich das, was zählt. Weiß ich nicht, ob das noch relevant ist. Aber wenn ich die Auswahl hätte, hey, also
27:42
SSDs oder irgendwelche NV-RAM-E, was weiß ich, Latest und Greatest, ich hätte sie gerne. Aber in der Praxis wird ihr feststellen, das nutzen wir einfach nicht mehr aus. Gut, ja, Netzwerk, da hängt es jetzt ein bisschen davon ab. Habe ich ein Standalone-System, ist mir das Netzwerk relativ egal. Also die Applikation sollte
28:02
gut angebunden sein. Bei Replikation hängt es dann davon ab, was ist Replizierung? Beim Cluster würde ich mal sagen, ich will das Beste. Also das werden wir später noch diskutieren, muss man mal schauen. Eine Sache, also wenn man es sich leicht machen will, dann würde ich immer mal SQL als Betriebs- oder mit dem Betriebssystem
28:20
ein Standalone betreiben. Wir werden sehen, vieles von dem Tuning, was wir nachher besprechen, in dem Moment, wo das eingekapselt und es läuft tatsächlich in sich alleine, habe ich ganz andere Möglichkeiten. In dem Moment, wo ich mir das mit der Applikation teilen muss, ich teile gerne, das ist nicht der Punkt. Nur, wenn dann was schief läuft, also die Applikation ist nie schuld, das ist immer maysql
28:40
und es ist auch immer maysql, was dann cached, das stimmt sogar, nur warum cached, zwar die Applikation, aber an dieser Stelle, wenn es geht, würde ich tatsächlich versuchen, maysql standalone auf einem Betriebssystem als dedicated service zu verwenden. Sagen wir jetzt einfach mal, wir verwenden Linux in, weiß ich nicht, VM-Ware
29:00
oder in KVM oder sonst irgendwas, an dieser Stelle ist es unrelevant, mit irgendeinem modernen Linux, 64-bit ist, sage ich einfach mal, state of the art, habe ich jetzt nicht groß erwähnt. So, was ändere ich an dem Betriebssystem ab? Also ganz ehrlich gesagt, ändere ich da eigentlich gar nichts ab. Also es gibt eine Parameter, den sollte man überprüfen,
29:20
ulimit, was ist ulimit? Wo sind die Linux-Leute? Die Prozesslimits, die Dateizugriffe, im Endeffekt die Dateizugriffe. Warum ist das wichtig? Ich habe 1000 Tabellen in maysql und ich habe 2 Benutzer.
29:41
In der Theorie, wieviel Files öffne ich? Mit 8, mit 7 ist es anders, mit 8. 2 Benutzer, 1000 Tabellen, können bis zu 2000 Zugriffe sein. Wo ist der Standard? Wo ist der Gefolgtwert bei Linux? Also zumindest mal bei Centos 7, bei 8 weiß ich es nicht.
30:01
1024. Das heißt also, wenn ich tatsächlich diese 2 Benutzer habe, die dann darauf zugreifen, würden die immer warten müssen, bis einer geschlossen ist. Wenn ich 100 Benutzer habe, und ich habe 100 Tabellen, habe ich theoretisch 10.000, also man sieht schon, das wird so ein Problem. Deswegen, also diesen Wert einfach anpassen, ist relativ einfach. In der Praxis würde
30:22
ich sogar empfehlen, einen Benutzer anzulegen für maysql, oder dem er dann läuft und diese Limit tatsächlich dann auf diesen Benutzer zu binden, aus Security-Sicht. Ist optional, kann man machen. Man kann das ganze Thema auch unendlich weiter treiben, also in der Dokumentation steht, dass wir hier einen alternativen Mellok empfehlen. Habe ich persönlich noch nie gemacht, kann man tun. Ob da wirklich signifikante Unterschiede sind,
30:42
ich weiß es nicht, aber Dimitri sagt ja. Wenn Dimitri ja sagt, sage ich natürlich auch ja. Ob die relevant sind, behaupte ich mal, weiß Dimitri auch nicht. Ich habe es noch nicht gesehen, von der Seite, da kann man sich, wenn man betriebssystemsicher unterwegs ist, gerne auslassen. Ja, und dann gibt es diese Tuning-Wissatz. Also die kennt bestimmt auch jeder.
31:01
Also die machen dann das Betriebssystem super und das maysql super. Ich stehe nicht auf die. Ich hatte das mal gemacht, ich habe in meinem vorigen Leben maysql angewendet, als Anwender, und da hatte ich das getan. Und das Resultat war dann irgendwie, dass ich 4 oder 5 Tage versucht habe, die Probleme zu lösen. Also, von denen kann ich wirklich nur
31:21
abraten. Ich sage nicht, man kann das tun. Alles, was wir jetzt hier machen, kann man auch in ein Programm packen. Ich kenne halt jetzt wirklich kein Programm, das das gut macht. Ich lasse mich wirklich raten, dass es da was Gutes gibt, aber die, die ich kenne, sind nicht so optimal. Sorry. Also von der Seite, ich würde definitiv davon abraten.
31:40
Und gerade also jetzt Unlimitsetzen oder sowas, das kriegt auch der normalen Anwender hin. Maysql, da muss man ein bisschen aufpassen. Also ich hatte ja schon gesagt, maysql 8 und wir releasen alle 3 Monate. Und ja, es gibt nicht nur ein maysql, es gibt dann auch noch Maria und es gibt ein Per Kona und die einen sagen, wir sind maysql, die anderen sagen,
32:00
wir sind es nicht. Also grundsätzlich erst mal egal, aber man sollte es halt einfach wissen. Also nicht überall da, wo maysql drauf steht, ist maysql drin. Also die Deutschen kennen ja die ganzen Slogan noch. Aber gut. Deswegen an dieser Stelle eben aufpassen. Weil ich sage es einmal bei Kona, auch die hängen einige Releases
32:20
hinter unserem Release hinterher. Also 8017. Also vieles von dem, was wir machen, geht da so nicht. Und wir machen das ja aus einem Grund. Also wir machen das ja nicht, weil wir denken, hey, das ist cool, sondern da sind ja ganz viele Bugfixes und Security und was weiß ich alles drin. Also es hat ja schon Grund, warum wir releasen. Das ist ein relativ teurer Prozess für uns. Das dauert und relativ viele Ressourcen gebunden. Und von der Seite würde ich es auch
32:41
tatsächlich nutzen. Und deswegen, ich gut, ich vertrete natürlich auch maysql, würde ich immer empfehlen. Also maysql. Und wenn ich rede maysql, dann rede ich wirklich von dem maysql von maysql.com. So, das ist der erste Punkt. Der zweite Punkt ist 5, 7 und 8. Also ich hatte ein paar Mal diese Diskussion gehabt. Na ja, das muss erst schön abgehangen sein. Das stimmt. Das sehe ich auch alles ein. Aber
33:00
auch hier wieder. Also viele, viele, viele Dinge, die wir mit maysql machen, die stehen in 8 zur Verfügung und in 5, 7 eben nicht. Gerade wenn es um den InnoDB Cluster geht, da sehe ich den eklatantesten Unterschied zwischen den zwei Releasen. Muss man einfach aufpassen. Aber es gibt einen Grund und den sollte man wirklich kennen. Also in dem Moment, wo, ich sage jetzt einfach mal, die Applikation
33:20
zertifiziert ist mit maysql 8, sind keine Probleme zu erwarten. Also ganz viele Kunden verwenden mit maysql 5, 7 UTF 8. Das ist so. Ja, ich behaupte einfach mal die allermeisten hier. So, jetzt hatte ich ja eingangs erwähnt, maysql 8 speichert die Daten nativ auf Basis von UTF 8 MW4 auf Unicode 9. Da gibt es
33:40
einen ganz signifikanten Performanceunterschied. Also das ist tatsächlich so, wenn Sie eine existierende 5, 7 UTF 8 mit maysql 8, werden Sie 20, 30 Prozent, ohne irgendwas zu machen, höhere throughput haben. Ist keine Magie, hat einfach mit diesem Fallsystem zu tun. Es gibt allerdings auch einen Nachteil. Und der Nachteil ist, der Default in maysql 5, 7 ist Latin
34:00
1. Wenn ich es auf Latin 1 umstelle, maysql 8, sind wir signifikant langsamer als 5, 7. Also von der Seite muss man die Entscheidung auch da ein Stückchen abhängig machen, was für ein Characterset, was für eine Collection ich da verwende. Also 5, 7, 8. Im Regelfall ist maysql 8 sehr, sehr gut. Es ist auch lang genug schon raus. Also ich kenne jetzt keine signifikanten Bugs.
34:21
Heißt aber nichts. Kann sein, dass gerade einer geöffnet wird. Aber grundsätzlich, wenn die Applikation das hergibt, viele Applikationen machen es noch nicht, würde ich tatsächlich maysql 8 verwenden. Das nächste sind dann die maysql Repos versus Linux. Auch gestern waren Konsulten da von maysql, der wieder gesagt hat, ja, das Upgrade, das ist ein Problem. Ich kann das so nicht
34:40
bestätigen. Normalerweise hätte ich gesagt, ich mach eine Demo, aber ich bin schon relativ weit mit der Zeit. Von der Seite spare ich mir jetzt diese Demo. Es gibt ein maysql Repository. Sie laden sich ein Paket runter von maysql.com Downloads, installieren dieses Paket. Dann machen Sie jam install maysql-server und das war's. Und wenn ein neues maysql-Release zur Verfügung steht, dann wird es eben mit abgedatet. Das gibt es
35:00
für das Release 5.5, 5.6, 5.7, das gibt es schon immer. Damit kann ich sehr sehr einfach maysql state of the art halten. Das wäre meine Empfehlung. Viele machen auch RPM-Installation, kann man alles tun. Wichtig an dieser Stelle vielleicht, die Pakete sollten tatsächlich von maysql.com kommen, weil ich es eben sonst nicht weiß. Red Hat 8 kennt mit Sicherheit
35:21
auch viele oder jeder oder Centos. Eine Centos 8 gibt es glaube ich noch nicht. Was für ein maysql wird mitgeliefert? Hat jemand geguckt? 8012, also aus unserer Sicht ein 5 altes Release, liefern die halt mit. Das ist auch klar, dass sie das tun. Nichtsdestotrotz sollte man sich einfach im Klaren sein, man arbeitet unter Umständen
35:41
mit dem älteren Release. Dann, wir reden jetzt über maysql 8. Die maysql-CNF, die kennt jeder von Ihnen. Jetzt muss ich dazu sagen, ich verwende die auch noch und vieles, ich schreibe jetzt auch immer maysql-CNF. Aber ganz ehrlich gesagt macht man das heute so nicht mehr. Man kann über dieses set-persist
36:00
die Werte in einer Session schreiben, somit kann ich gerade bei irgendwelchen Docker, Container, was weiß ich, Images, sehr, sehr einfach die Parameter ändern, ohne in der maysql-CNF umzuwurken. Und viele von den Parametern sind ja mittlerweile auch dynamisch. Ich kann das tatsächlich über set-persist sitzen. Wenn ich über set-persist set-persist setze,
36:21
dann wird der Wert in die maysql-deauto-CNF eingetragen. Der steht auch unter varlib maysql. Das heißt, wenn ich maysql starte, liest er erst die maysql-CNF, liest im zweiten Schritt dann die maysql-deauto und überschreibt die Werte der maysql-CNF. Es gibt da eine entsprechende History, kann man sich auslesen. Nur mal ganz grundsätzlich,
36:41
ich behaupte einfach mal, die maysql-CNF wird über kurz oder lang irgendwo sterben. Auch bei unseren internen Deployments mit der maysql in der maysql-cloud setzen wir tatsächlich primär nur noch auf set-persist und setzen die Sessions in der Variable selbst und nicht mehr über die maysql-CNF. Das geht nach wie vor, gar kein Problem. Ich referanziehe auch immer wieder drauf. Nur
37:00
besser ist es vielleicht, man guckt sich die maysql-deauto an. Dann alle Sessions gehören zur maysql-de section, keine Duplikaten in der Fall. Primary Key ist einfach ein Must-have, immer für irgendwelche Performance-Dinge. Und die Main Performance, haben wir schon gesagt, kommt nicht von der Hardware oder von den Betriebssystemen von guten Queries. Und ganz wichtig an dieser Stelle ist eben das Monitoring von maysql. Jetzt fangen wir mal an. Also die erste
37:21
Einstellung, die ich eigentlich immer ändere, ist der Standard-Port. Das hat einen ganz einfachen Grund, 3306. Wenn ich zwei Systeme habe, Master- und Slave-System, möchte ich ja nicht meine ganzen Applikationen sagen, wenn da irgendwas geändert ist oder wenn da irgendwie ein Umswitch macht. Das ist das neue maysql-System. Ich kann
37:41
mit einem Router, ob ich da jetzt in maysql-route, ob ich da in haproxy, an dieser Stelle erstmal ganz grundsätzlich egal, ich würde eine Instanz da vorstellen, die tatsächlich auf die aktive maysql-System routet. Das heißt aber auch, dass ich dieser Instanz den Port 3306 gebe, was dann wiederum heißt, dass maysql einen anderen Port haben sollte.
38:00
Kann man machen, muss man nicht machen, ist einfach optional. Aber denken Sie sich einfach, Sie haben drei maysql-Systeme, so wie gewährleiste ich den Zugriff auf das System, gibt es ganz viele Möglichkeiten, das Einfachste ist, ich setze einen Router oder einen Proxy davor und dem Router oder dem Proxy, dem gebe ich die 3306, damit ich meine Applikation selber nicht ändern muss. Ist optional, ist wie gesagt relativ einfach, nur grundsätzlich
38:22
Applikation connectet über 3306 an den Router und der Router connectet dann weiter an irgendwelche anderen maysql-Systeme. Oder Proxy, oder was auch immer. Deswegen ändere ich den Port und Standard-Port eigentlich im Regelfall ab. Maysql und Memory, ich habe es am Anfang schon gesagt, maysql liebt Arbeitsspeicher und InnoDB ganz im Speziellen. Da gibt es diese drei Werte,
38:42
also die, die man eben setzt für den Server-Start, also den InnoDB-Buffer zum Beispiel, das ist typischerweise ein sehr sehr großer Wert, das ist eine globale Einstellung, den setzt man einmal und den nimmt sich maysql. Punkt. Ob es das braucht oder ob es das nicht braucht ist egal, der ist gesetzt und das nimmt sich. Und das ist eben nur einmal allokiert. Der ist relativ unproblematisch,
39:00
kann man handeln. Schwieriger wird es bei Settings, die ich per Connections setze, zum Beispiel irgendwelche Temp-Table-Settings. Weil ich bleibe einfach jetzt mal bei 100 Verbindungen und wenn ich dann 100 mal die Verbindungen, wenn ich jetzt einfach sage, Temp-Table 1 Gig, dann sind das 100 Connections mal 1 Gig, sind 100 Gig nochmal für die Sessions drauf, da werde ich mit Sicherheit swappen und das ist der Super-GAU.
39:21
Von der Seite, egal was ich ändere, mir muss immer klar sein, wie setzt sich der Arbeitsspeicher zusammen. Diese Global Variablen sind wie gesagt relativ einfach, die kann ich handeln. In dem Moment, wo ich per Connection based Settings mache, wird es dazu führen, unter Umständen, wenn ich viele Connections habe, dass ich ein Arbeitsspeicher-Problem habe. So, ich habe jetzt hier erstmal Platzhalter
39:41
geschrieben, wir kommen da gleich nochmal drauf zurück. So, jetzt gibt es, was sind so diese typischen Werte, die ich ändere in MySQL? Also der Wert überhaupt ist der InnoDB-Buffer. Mal ganz grundsätzlich kann man sich vorstellen, also MySQL hat einen Buffer im Memory, Arbeitsspeicher ist immer noch Faktor 1000 schneller als die Festplatte und meine Daten stehen da drin. Und wenn ich jetzt irgendwie ein Read mache, ein Select mache,
40:02
dann ist das schnell. Je mehr Arbeitsspeicher ich habe, desto weniger muss ich auf die Platte greifen, eher gut, desto schneller ist es. Das ist so der Hauptwert, den ich ändere. Und da sagen wir typischerweise so 75% des Arbeitsspeichers. Ja, wenn ich ein dedizites System habe, wenn ich jetzt kein dedizites System habe, ist die Frage was steht mir wirklich zur Verfügung und wie stelle ich sicher, dass dieser Wert zur Verfügung steht?
40:21
Ziemlich schwierig. Und von der Seite ein dedizites System ist halt einfach besser. Gut. Ich sage einfach mal, das kann man sich als Cache vorstellen, das ist relativ einfach, das ist alles, wenn es um lesende Performance geht, ist das so dieser erste Wert, den man wissen sollte. Zweiter Wert, InnoDB Log File Size,
40:41
der sogenannte Transaction Log oder Redo Log. Stimmt nicht 100%, hat sich auch mit MySQL 8 geändert, ist aber für unsere Theorie, für unsere Überlegung relativ egal. Ich connecte auf dem MySQL System, ich habe eine Information, die steht dem Arbeitsspeicher zur Verfügung. Sinngemäß wird die Arbeitsspeicher, mit der Arbeitsspeicher in das Log übertragen und das Log updatet dann die InnoDB Engine.
41:01
Wenn dieses Log nicht groß genug ist, gibt es Verzögerungen und dementsprechend möchte ich das verhindern. Der Default sind 2x50 MB, 100 MB, gerade wenn ich also irgendwelche Dumps fahre, also einspiele, ist das unter Umständen zu klein und dementsprechend sollte man das anpassen. Ich habe jetzt hier auch mal geschrieben 256 MB,
41:22
ist ein guter Wert. Das heißt, wenn ich also was schreibe, wird tatsächlich dieses Log relativ schnell befüllt, wird aber an dieser Stelle noch nicht gesnapschottet mit der Storage Engine. Und dementsprechend kann ich erstmal diese 500 GB in diesem Beispiel auflaufen lassen, ohne dass es ein Problem gibt. Das ist wie gesagt das Äquivalent zu dem RIDO Log.
41:41
So, ich komme gleich nochmal auf diesen Platzhalter zurück. Und dann gibt es das InnoDB Flash Method. Die Idee ist ja, ich habe das MySQL System, das MySQL cached, das Betriebssystem cached, die Festplatte cached und dann irgendwann unten drunter wird es auch wirklich mal auf Platte geschrieben. Also zuviel Caching. Mit diesem ODIRECT gehe ich sinngemäß übergehe ich
42:01
den Cache von dem Betriebssystem und schreibe direkt in den Cache von der Festplatte, theoretisch. Ist eigentlich eine gute Sache, dadurch ist MySQL typischerweise eine ganze Ecke schneller. Man sollte natürlich ein grundsätzliches Verständnis davon haben, was wird denn auf die Platte geschrieben. So, ja, kann man alles setzen, muss man
42:21
mit MySQL 5.7 setzen. Mit MySQL 8 gibt es die variable InnoDB Dedicated Server. Und diese InnoDB Dedicated Server kann ich auf eins setzen und dann bemisst er diese Parameter automatisch. Ich muss mich nicht darum kümmern. Ich setze also, ich installiere mein MySQL, setze InnoDB Dedicated Server und alle anderen Werte werden tatsächlich
42:41
dann abgeleitet von meinem zur Verfügung stehenden Arbeitsspeicher. Gibt es nur in MySQL 8, ist die mit wichtigste Setting. Warum macht man das nicht bei Default? Wenn ich ein MySQL System habe, auf dem auch Applikationen Server laufen und ich greife mir dann einfach mal 75% des Arbeitsspeichers, hat die Applikation ein Problem. Dementsprechend können wir das nicht tun. Nichtsdestotrotz,
43:01
ich würde mal sagen, mit MySQL 8 ist das die wichtigste Setting. InnoDB Dedicated Settings und der bemisst mir diese ganzen anderen Werte automatisch auf Basis des zur Verfügung stehenden Arbeitsspeichers. Ändere ich den Arbeitsspeicher, ändert er die Werte mit. Coole Sache, gerade in der Cloud. Ich brauche mehr Performance. Ich setze meine Werte halt entsprechend hoch. Sie werden automatisch beim nächsten Reboot mit
43:21
angepasst. Gut, wie viel Arbeitsspeicher ist richtig? Ganz heikles Thema. Gibt es 1000 Meinungen dazu. Immer wenn es 1000 Meinungen gibt, gucke ich dann an, wenn der Kunden dies machen. Einer meiner Kundenbooking.com sagt immer näher, also so 40% der Datenbankgröße sollte es sein. Diese Aussage gebe ich so
43:41
jetzt einfach mal weiter. Also wenn ich 100 Gigabyte habe, dann gehen die von 40, also von 100 Gigabyte von 40 Gigabyte aus, was ich dem InnoDB Buffer zuweisen, plus das Betriebssystem 4, 5, also bei 50 Gig, wäre dann eben Schluss. Da gibt es 1000 andere Sagen, gerade wenn ich solche Log-Devices habe, die tatsächlich nur irgendwie so als Schreibinstanz sehen, brauche
44:01
ich das natürlich nicht. Es gibt da keine gute Antwort von der Seite. So ein Stück weit ist das tatsächlich Trial and Error. Also den fantastischen Wert dazu kann ich auch nicht benennen. Sorry. Dann gibt es InnoDB Flash Log at TRX. Also was passiert ganz grundsätzlich? Also ich schreibe in meinen Arbeitsspeicher rein und dann wird der Arbeitsspeicher runtergebrochen auf meine
44:21
Transaction Logs und die Transaction Logs daten dann entsprechend meine Storage Engine ab. Gut. Jetzt, wenn ich tatsächlich in den Arbeitsspeicher schreibe, die Information wird in dem Log vorgehalten, dann muss diese Information ja auf das Festplattensystem gefsinkt werden. Ich habe 1000 Transaktionen, ich habe 1000 F-Sinks. Das ist sehr ineffektiv. Kann man
44:41
machen. MySQL handelt das. Ich kann es aber auch tatsächlich so definieren, dass ich sage, ich mache das zwei. Das ist eine ganz gefährliche Setting, weil MySQL tatsächlich nicht mehr asset compliant ist. Wenn ich tatsächlich einen Stromausfall habe zu dieser Zeit, werden mir tatsächlich diese Daten verloren gehen. Muss ich sehr, sehr aufpassen, aber gerade die, die noch MyISAM einsetzen
45:01
oder die dieses ENO als irgendwelches CMS-System verwenden, mal ganz ehrlich, wie viele Updates habe ich denn und wie relevant ist es denn, wenn mir tatsächlich mal eine Sekunde an Daten verloren geht, wenn es tragbar ist, kann ich damit den throughput signifikant erhöhen. Wenn es nicht tragbar ist, dann dementsprechend nicht ändern. Jede Datenbank hat auch so ein bisschen seine
45:20
eigene Einstellung. Ich zwinge ja hier ein bisschen so auf Microsoft. Unsere ist wie gesagt bei Default eins, das ist nicht die schnellste. Wenn ich es auf zwei ändere, ist es wie gesagt per se 30-40% schneller. Dann Skip Name Resolve. Wie connecte ich mich bei einer MySQL-Datenbank? Username und Passwort, das kennt natürlich jeder. Aber da ist ja noch diese dritte Information, von wo connecte ich mich. Das kann eine IP-Adresse
45:41
oder das kann ein Hostname sein. Das kann man mit entsprechenden Zertifikaten dann secure gestalten. Was aber passiert? Mit jedem Connect auf MySQL macht MySQL einen DNS-Lookup. Was ist denn, wenn ich mich connecte als cast at Oracle auf MySQL und Oracle kann nicht aufgelöst werden? Das dauert.
46:00
Dementsprechend, wenn man es machen kann, es ist wie gesagt auch ein Security-Problem, Skip Name Resolve bei eins, würde verhindern, dass der DNS selber angesprochen wird. Ein ganz häufiges Problem gerade bei Telecom-Anbietern kann man einfach umgehen. Dementsprechend würde ich das auch setzen. Sind Binlocks, das ist das Äquivalent zu dem THX-Commit auf Basis der Binlocks, das spare ich mir an
46:21
dieser Stelle jetzt einfach. Max-Connections, eine super Setting. Bei default 151 und einer der Entwickler, Gear, hat einen Blog geschrieben, wo er sagt, also aus seiner Sicht sollte die Setting sein pro Thread, pro CPU Thread hat etwa vier Verbindungen. Dann überlege ich unsere Settings in 150
46:41
by default, das heißt also es geht davon aus, dass das System 38 Threads hat falsche Annahme. By default sind diese 151 wahrscheinlich zu hoch. Man muss tatsächlich gucken, also wie viele Systeme, wie viele Connections wird auf MySQL angewendet. Kann man relativ einfach Tracing Connections ist nur die Anzahl der connectierten Connections.
47:01
Die Thread Connectors, das ist tatsächlich die aktuell parallele Anzahl der Connections, die muss man tracen oder man schaut Max-Use-Connections nach und sieht dann eben den entsprechenden Value. Und dann kann man tatsächlich sagen, also für fünf virtuelle CPUs oder sechs, und dann setze ich einfach mal ein Faktor 10 an, ich bin nicht so konservativ wie Gear,
47:21
würde ich sagen, also mit 50 sind wir ganz gut bedient. In dem Moment, wo die CPUs nicht ausreißen, die Connections abzufruestigen, ist das Gesamtsystem langsam. Also das ist noch der schlechtere Anwendungsfall als außer, wenn ich dann den 51, 52, 53 besten Connection einfach ablehnen würde. Also von der Seite muss man sehr gut monitorn, kann man aber relativ einfach machen.
47:44
Es gibt noch zwei weitere Settings. IOCapacity von EnoDB, by default 200 und 2000. In dem Moment, wo ich wirklich ein System habe, was sehr, sehr, sehr viel schreibt, kann ich diese Werte anpassen. Aktuelle Festplattensysteme können deutlich mehr. Also einige unserer
48:01
Mitbewerber schreiben 6, 7, 8000, weiß ich nicht, aber ich glaube auch, dass die 2000, was der default ist, tatsächlich zu klein ist, kann ich relativ einfach hochbringen, heißt aber natürlich auch, ich bräuchte ein dediziertes System, weil sonst geht mir einfach die Komplett-Performance von dem System kaputt. Gut, die MySQL Shell, wer die nicht kennt, die gibt es auch schon seit Release 5.7.
48:22
Die MySQL Shell ist so das Ersatz von dem MySQL Client. Da kann man eine ganze Menge machen, man kann die nativ mit Javascript und nativ mit Reisen verbinden, das ist der Klein der Zukunft. Also ganz, ganz, ganz viel, wenn es um InnoDB Cluster und andere Funktionalitäten geht, kann man sehr, sehr schön in der Shell machen, kann man auch über den Client machen, aber da ist es mehr Arbeit.
48:41
Sollte man sich einfach mal anschauen, die Shell ist tatsächlich der Klein der Zukunft aus unserer Sicht und kann man viele Dinge automatisieren. Aber der MySQL Klein, auch die Workbench sind natürlich immer noch da. Auch hier, ich spar mir die Demos. So, es kommen zwei kleine Breakouts, einmal das Thema Verfügbarkeit. Also jeder will Hochverfügbarkeit, sind wir mal ganz ehrlich, das ist tatsächlich
49:01
so. Ja, das kann man über viele Möglichkeiten machen. Also, so ganz traditionell gab es die Replikation, ich habe einen Master und ich habe einen Slave. Wenn der Master kaputt gegangen ist, dann ist halt der B der neue Master geworden und ich habe mit dem B weiter gearbeitet. Hier müsste ich jetzt tatsächlich einen Router oder was davor haben, damit ich dann meine Applikation sagen kann,
49:21
nicht mehr das ist das aktive System, sondern der andere, ist an dieser Stelle aber kein Problem. Das kann man so machen. Da gibt es ganz viele Vorteile, aus meiner Sicht. Das wäre jetzt dann der Ablauf dazu, wie die Commits ablaufen. Also ganz grundsätzlich, ich habe den Master und der Master arbeitet vor sich hin und der dated sich mit keinem der Slave-Systeme ab.
49:41
Das Schöne dabei ist, das ist super einfach, das habe ich in zwei, drei Befehlen aufgesetzt. Es gibt keine Dependencies und Netzwerke, ob das jetzt in Deutschland oder in Amerika, das interessiert mich nicht, weil der Master wartet nicht auf den Slave. Umgekehrt, die Datensynchronität zwischen dem Master und dem Slave ist nicht gewährleistet. Es kann durchaus sein, dass der Slave irgendwie
50:00
kaputt ist, aus Mastersicht merke ich das erstmal nicht. Muss ich halt monitorn, sage ich dann dazu. Aber so kann man das machen. Gerade wenn ich dann auch Last ausgliedern will auf andere Systeme, ist das ein fantastisches Tool, um zu sagen, ich möchte den Master so sauber wie möglich halten und wenn der Master kaputt ist, dann gehe ich auf den Slave. Ganz einfach. Geht schon 20 Jahre, ist nichts Neues.
50:21
Das ist ein bisschen neuer. Das geht so etwa zehn Jahre, sieben, acht, neun Jahre. Ich habe meinen Master, ich habe wieder meinen Slave, ganz normale Standardreplikation, mit einem Unterschied. Die Information wird auf dem Master System gegenüber das DeutschEngine erst dann committed, wenn ich ein Acknowledgement von dem Slave System habe. Das ist immer noch super
50:40
einfach und es gibt hier eine Dependency. Also wenn der Slave Server nicht antwortet, kann ich definieren, was auf dem Master Server passieren soll. Ich kann verhindern, dass die zwei Systeme auseinanderlaufen. So macht es Booking, so macht es Facebook, so machen es ganz, ganz viele. Da kommt man sehr, sehr weit damit. Aber, ganz klar, man hat jetzt hier eine Dependency. Also das Netzwerk, das geht nicht mehr mit Deutschland und
51:02
Amerika, sondern die Netzwerkverbindung hier zwischendrin, die muss einfach sehr, sehr gut und sehr, sehr schnell sein. Kann man wie gesagt schon lange Zeit machen, nennt sich semi-synchronereplikation, ist immer noch Master-Slave, man kann auch Master-Master machen, funktioniert eigentlich so weit ganz gut, ist aber wie gesagt auch ein alter Hut. Das ist der neue Hut.
51:22
Grubreplikation in ODB Cluster. Funktioniert ein bisschen anders. Ich habe hier ein sogenanntes Konsensus-Building mit einer Zertifizierung zwischendrin. Das heißt, ich schreibe auf ein System, die Information wird auf die beiden anderen Systeme mit übertragen. Da gibt es mittlerweile verschiedene Consistency Levels, ich kann das garantieren. Das ist immer noch sehr einfach, aber ganz klar
51:41
das Netzwerk ist hier das A und das O. Also vor zwei Jahren, wo ich den Vortrag gehalten hatte, hatte ich vielleicht gesagt, hey, das ist alles super. Ganz klar, das ist auch super, aber das Netzwerk muss funktionieren, weil wenn das komplette Netzwerk weg ist, habe ich hier ein Datenproblem. Und dementsprechend Netzwerk ist hier A und O. Also wenn ich keine redundanten Netzteile, keine redundanten
52:01
Netzwerkinfrastruktur habe, bezweifle ich, dass der InnoDB Cluster, auch wenn es super einfach und nichts kostet, die richtige Lösung ist, weil ich eben in Daten inkonsistent arbeiten werde. Von der Seite also muss man an dieser Stelle aufpassen, Netzwerk ist das A und O. Der andere Nachteil ist natürlich, ich habe tatsächlich drei Systeme. Okay, ist so.
52:21
Wer diesen InnoDB Cluster vor zwei Jahren nicht gesehen hat, der ist auch aufgezeichnet worden. Ganz grundsätzlich, ich mache sechs, sieben Befehle und habe dann tatsächlich hier von den drei Systemen ein aktives System. Und je nachdem, welches von diesen Systemen dann ab oder down ist, wird der MySQL Route immer nur auf ein aktuelles System connecten. Wer das sehen will, können wir
52:40
am Stand machen, dauert fünf Minuten, hat man den aufgebaut, war wie gesagt lange Zeit überhaupt kein Problem. Ja, jetzt kommt es aber. In dem Moment, wo ich ein System habe, da sind schon, sagen wir mal, 50 GB Daten drauf. Und ich möchte da ein zweites, drittes System mit einfügen. Muss ich ja zunächst erstmal eine Kopie machen, einen Backup
53:00
machen, muss diese Backup einspielen auf dem zweiten System, dann nehme ich den zweiten Server dazu. Also dieser vorgeschaltete Schritt, das war tatsächlich ein Problem. Und das braucht man jetzt nicht mehr. Es gibt das sogenannte New Cloning, also Cloning Methode, ich habe meinen Server, da stehen die Daten drauf. Ich habe einen zweiten Server, dieser zweite Server
53:20
clont die Daten von dem ersten System einfach rüber. Ich baue dazwischen jetzt eine Replikation vielleicht noch auf, baue ganz in Ruhe meine zwei anderen Systeme auf, meine Applikation läuft weiter, ich habe alle Zeit der Welt, repliziert die Änderungen rüber, switchen meine Applikationen rum und hat man ihren DB Cluster. Das Ganze ist ein Aufwand von ein paar
53:42
Minuten und auch große Datenmengen, das ist im Prinzip nur ein Netzwerk Copy, den ich hier mache, kann ich so sehr, sehr einfach abbilden. Das Ganze ist automatisiert über die MySQL Shell, klingt komplizierter wie es in der Praxis ist. Es gibt wie gesagt leider noch keine Videos dazu, wahrscheinlich sind noch Sommerferien, aber ich denke, die werden jetzt sehr, sehr schnell nachkommen. Wie gesagt, Grubreplikation, Alterhut,
54:02
dieses Clon, das ist tatsächlich jetzt neu. Aber wie gesagt, ich brauche drei mal die Ressourcen, das Netzwerk ist immens wichtig, GTID ist mandatory, ich brauche einen Primary Key, ohne Primary Key geht es gar nicht und MySQL Shell ist irgendwo verbindlich, die muss tatsächlich verwendet werden, sonst habe ich da ein Operationen-Betriebssystem
54:22
Problem, aber kann man machen. Einfach mal vor zwei Jahren, wie gesagt, hatte ich den Vortrag gehalten, einfach mal anschauen, das stimmt immer noch, das Einzige, das Cloning, das ist jetzt die neue Komponente, die mit dazu gegangen ist, Entschuldigung. So, zwei weitere Folien noch, einmal Documents dort, das ist in Anlehnung an den Vortrag von dem Markus Wiener
54:41
und gestern. Also unsere, die Datenbank Sicht ist immer die, ich habe so spezialisierte Tabellen und da habe ich Columns und ich habe Zeilen, alles schön und gut, die Entwicklerssicht ist oft eine andere, die Entwicklerssicht ist oft, dass ich sogenannte Documents habe, ganz oft sind das tatsächlich Chasing-Documents und diese Chasing-Documents sollen tatsächlich in MySQL gespeichert werden, das kann man tun,
55:03
das nennt sich NoSQL in MySQL oder MySQL Document Store, auch das ist keine neue Funktionalität, sinngemäß habe ich hier meinen alten Zugriff über SQL und ich habe hier meinen neuen Zugriff über X-Protokoll, neuer Zugriff heißt, es gibt es etwa auch schon so zwei Jahre, tatsächlich ist es hier so, dass ich die relationalen Daten speichere
55:21
und die Chasing-Daten werden tatsächlich auch in der Tabelle vorgehalten, aber wir sagen, es ist schemales, weil es tatsächlich nur ein einziges Feld ist, was hier abgelegt wird. Vieles, was Sie von Namongo oder von anderen Systemen können, können Sie mit MySQL ganz genauso auch machen, das funktioniert. So, das
55:41
alles wird in InnoDB gespeichert, sodass letztlich auch alles Asset Compliance ist, über Support und Replikation und Verschlüsselung kann man auch alles mit dieser Methode machen, gilt es immer für das SQL, als auch für das NoSQL Interface. Das ist einfach die Referenz dazu, die Befehle, einfach in Ruhe durchgucken, ich habe ein kleines Zeitproblem, sorry.
56:03
Dieses sogenannte Crud Engine ist eben kein klassisches SQL mehr, hier sind jetzt vier Beispiele benannt, dort nicht fehlt, man könnte es mit Dortnet an dieser Stelle auch machen. Es ist tatsächlich, der Zugriff auf MySQL wird anders abgefrühstückt, als mit einem SQL, typischerweise sehr, sehr viel einfacher und
56:20
ja, es ist eine Art Mongo-Equivalent-Produkt. Da gibt es Unterschiede, aber auch hier können wir gerne dann im Nachgang diskutieren. Und wie gesagt, in dem Moment, wo ich alles mit trx-commit1 und mit dem SyncBankLog1, wie auch der Standard wäre, belasse, ist tatsächlich alles nach wie vor Asset Compliance, das ist übrigens der Mike Sinner, der hat das entworfen, also
56:41
ist das irgendwie ein Symbolenbild, ist er auch ein Österreicher, wie der Markus Wiener eben auch. Gut, ich glaube, Security mache ich jetzt wirklich nur ganz schnell. Die Daten, die auf MySQL abgelegt werden, liegen auf lokaler Festplatte, Punkt. Dieses lokale File kann ich in weitestem Sinne auslesen. Ob ich das jetzt wirklich ganz simple Methoden
57:02
mit einem VI oder mit anderen lasse ich an dieser Stelle erstmal außen vor. Aber mal grundsätzlich, wenn der Server bei mir im Rechenzentrum steht, ist es vielleicht kein Problem. Wenn der Server vielleicht bei einem Cloud-Anbieter irgendwo läuft, möchte ich das vielleicht nicht. Und ja, man kann diese Daten verschlüsseln. Das geht. Das ist keine kommerzielle Extension. Da gibt es zwar nochmal ein paar schönere Lösungen,
57:22
aber das kann man tatsächlich mit MySQL auch machen. Grundsätzlich ist es so, ich habe hier einen sogenannten Master Key. Der Master Key wird verwendet, um den Tabel-basierten Key zu entschlüsseln. Dementsprechend einfach kann ich den Master Key auch ändern. Kann man sehr, sehr einfach umsetzen. Grundsätzlich lade ich einfach ein Plugin, das nennt sich Keyring File Plugin. Und mit diesem
57:41
Keyring File Plugin kann ich dann sehr, sehr einfach sagen, ok, ich lade das. Wie gesagt, ich verwende auch noch die MyCNF. Ich leide dieses Keyring File Plugin. Es wird automatisch ein Key angelegt. Wichtig an dieser Stelle ist, das ist halt so in Anführungsstrichen meine Versicherung. Dieser Key muss halt in irgendeiner Art und Weise geschützt werden. Das ist genau die Methode, wo die kommerzielle MySQL-Version ein paar elegantere Methoden hat.
58:03
Nichtsdestotrotz, wenn man da einfach mal bei den Hostern guckt, da gibt es ganz viele Möglichkeiten, was man machen kann. Und das kann man auch tatsächlich mit MySQL anwenden. Und last not least, wenn ich das Plugin geladen habe, wenn ich mein Master Key habe, kann ich tatsächlich eine Tabelle XYZ sehr, sehr einfach verschlüsseln. Was letztlich heißt, dass wenn diese Platte oder wenn die Datei auf Platte liegt,
58:21
nicht mehr ausgelesen werden kann. Und Sie erinnern sich vielleicht, eingangs hatte ich gesagt, das geht jetzt auch mit dem MySQL System Tablespace, ja, also den kann ich eben an dieser Stelle ganz genauso einfach verschlüsseln. Aber wichtig ist der Key und der Key muss tatsächlich geschützt werden. Gut, das war jetzt zum Schluss alles sehr, sehr schnell.
58:41
Ich hatte eingangs gesagt, 8 Schritte und tatsächlich, es sind auch 8 Schritte. Also wie gesagt, das ist dieses U-Limit, was ich ändern würde. Ich würde die Yam Repository verwenden. InnoBD Dedicated Server ist eben diese in Anführungsstrichen Speicheroption. Ob Sie dieses TRX-Commit das Sync Binlog ändern, hatten wir kurz drüber gesprochen. Heißt halt auch, es ist unter Umständen nicht Asset
59:00
Compliant, aber gerade für diese MyISAM Anwender, schöne Sache. Es gibt Name Resolve, eine Security Einstellung, Max Connection, hatten wir kurz drüber gesprochen. Ich würde auf alle Fälle eine HA-Lösung in irgendeiner Art und Weise verwenden, aber halt so einfach wie möglich. Also Master Slave oder Master Master oder halt in InnoDB Cluster, wenn ich ihn dann verwenden kann. Und diese
59:21
Document Store Ansätze in Verbindung mit der CRUD Engine sind einfach für Entwickler sehr, sehr interessant. Einfach mal ausprobieren. Ich würde empfehlen, die Daten so oder so zu verschlüsseln, vor allen Dingen eben dann, wenn ich diesen Server nicht in meinem Rechenzentrum habe. Zu viel Security gibt es nicht. Und das ist nicht alles, aber das sind so die Punkte. Ich glaube,
59:41
da hat man ganz, ganz, ganz viel damit schon abgefrühstückt. Und gerade mit diesem Dedicated Server, ich behaupte mal, viele von Ihnen kannten das nicht. Es ist eine Einstellung. Einfach ausprobieren. Es gibt viel, viel mehr. Monitoring, Outing, User Management, Authentication, schenke ich mir an dieser Stelle jetzt alles. Haben wir noch zwei?
01:00:00
2 Minuten Zeit für Fragen? Ich muss mal fragen, also habe ich jetzt bis 3 oder bis viertel nach? Bis 4 oder... bis 3, ok, gut, aber 2, 3 Fragen gehen noch? Ok, also Fragen, ne? Also wir sind noch eine Zeit lang am Stand, einfach mal vorbeikommen und ich weiß,
01:00:24
Sergej wird mit Sicherheit auch, viele viele Antworten wissen, auch von MySQL, von der Seite einfach dann mal Nachfolgefragen. Vielen Dank für die Aufmerksamkeit, schönen Sonntag noch.