Monitoring-Lösungen (auch für MySQL) gibt es viele. Das Portfolio umfasst kommerzielle aber auch viele Open Source Lösungen. Unter diesen Produkten gibt es Spezialisten, die sich vollständig auf eine Anwendung konzentrieren und im Gegensatz dazu stehen Generalisten, welche Plugins und / oder Module für nahezu jede denkbare IT-Komponente haben und / oder sich einfach selbstständig (z.B. über Skripting) erweitern lassen. Heute wollen wir uns einmal mit dem MySQL Enterprise Monitor (https://www.mysql.com/products/enterprise/monitor.html) beschäftigen, der von Kunden mit den entsprechenden Support-Leveln (Enterprise oder Cluster GCE) genutzt werden kann.

Mehr unter: blog.ordix.de

Berechtigungen auf Datenbanken zu vergeben kann ein mühsamer Job sein. Gerade das Vergeben von restriktiven Rechten à la „Du darfst alle Tabellen lesen, bis auf die Informationen in der Datenbank XYZ" war ein aufwändiges Unterfangen. Für eine solche Aufgabe mussten die SELECT-Rechte für alle Datenbanken definiert werden, die der User lesen können sollte. Die unerwünschte Datenbank wurde einfach mit keinen Rechten bedacht. Natürlich kann man sich solche GRANT-Anweisungen mit SQL dynamisch erstellen, um den Aufwand in Grenzen zu halten. Mit der Version 8.0.16 gibt es hier eine kleine Erleichterung.

Mehr dazu finden Sie hier:

Über den MySQL-InnoDB-Cluster und die zugehörigen Komponenten wie die MySQL-Shell und den MySQL-Router haben wir an dieser Stelle bereits mehrfach berichtet (z.B. https://blog.ordix.de/mysql-shell-cluster-your-application-in-40-minutes). Mit der Version 8.0.28 gibt es eine weitere Neuerung bei diesem "Dreigestirn". Die InnoDB-ClusterSets. Damit ist der DBA komfortabel in der Lage eine asynchrone Replikation zwischen zwei InnoDB-Clustern mit wenigen Kommandos aufzubauen.

Mehr dazu gibt es hier.

Morgen, Donnerstag, den 16. März 2023 findet um 18:00 Uhr (CET) der englischsprachige ORACLE MySQL Live Webcast zum Thema "

Tips for MySQL Performance Tuning" statt.Der Referent ist Michael Marx, MySQL Master Principal Solution Engineer

More:

https://go.oracle.com/LP=127708?elqCampaignId=347339&src1=:so:fb:or:dg:msq:::&SC=:so:fb:or:dg:msq:::&pcode=MSQL220513P00045

Ab und zu kommt es vor, dass die eine oder andere Applikation ungünstig formulierte Statements an einen MySQL-Server schickt. Dies kann dann zu Performance-Problemen führen, da beispielsweise vom Optimizer ein ungünstiger Ausführungsplan generiert wird. Im besten Fall kann der Entwickler der Software dieses Problem schnell für einen Fix selbst lösen. In vielen Fällen, z.B. bei Kaufsoftware oder bei kompilierten Code, ist dies nicht so einfach möglich.

Mehr dazu unter: https://blog.ordix.de/query-rewriting-mit-mysql

Morgen, Mittwoch, den 15. März 2023 findet um 18:00 Uhr (CET) der englischsprachige ORACLE MySQL Live Webcast zum Thema "

MySQL Enterprise in Financial Services" statt.Die Referenten sind Pedro Andrade, MySQL Key Account DirectorTom Disheroon, MySQL Principal Solution Engineer

More:

https://go.oracle.com/LP=127708?elqCampaignId=347339&src1=:so:fb:or:dg:msq:::&SC=:so:fb:or:dg:msq:::&pcode=MSQL220513P00045

Seit der MySQL-Version 5.7 gibt es eine Neuerung im Umfeld der Replikation: Multi Source Replication. In diesem Blog möchten wir Sie kurz darüber informieren, was die Besonderheiten dieses Replikationssetups sind und wie man dieses einrichtet. In unserem Beispiel soll es zwei Master (Port 3306 und 3307) und ein Replikat (Port 3308) geben. 
Mehr dazu unter: https://blog.ordix.de/mysql-multi-master-replikation-niemand-kann-zwei-herren-dienen-matthaeus-6-24

Dieser Beitrag bezieht sich auf ein Problem eines unserer Kunden, welches beim Import einer Datenbank in ein neues InnoDB Cluster entstanden ist.

Unser Kunde ist dabei, seine bestehende (veraltete) MySQL-5.5-Single-Instanz-Datenbank zu migrieren. Die Zielumgebung soll dabei aus einem Drei-Knoten-InnoDB-Cluster bestehen.

Mehr dazu können Sie unter diesem Link lesen.

 Bei einem der letzten Beratungseinsätze in Sachen MySQL haben wir bei einem Kunden einen MySQL-Server analysiert, auf dem mehrere Tausend interne Mandanten in eigenen Schemata betrieben wurden. Das Setup war zum Glück recht einfach und transparent: 1 Mandant = 1 Schema = 1 Account (User).

Das System war über die Zeit stark gewachsen (Anzahl Mandanten und Datenvolumen) und hatte diverse Performanceprobleme (I/O, CPU, Metadaten Locks, ...).
Mehr dazu unter: https://blog.ordix.de/proxysql-auch-umwege-fuehren-zum-ziel

Mittlerweile gibt es unterschiedliche Werkzeuge, um Performance-Probleme in MySQL aufzudecken. Nicht immer stehen diese jedoch ad hoc bei unseren Analysen auf Kundensystemen zur Verfügung. Zwar ist beispielsweise das „performance_schema" in den aktuellen MySQL-Version per default aktiviert, jedoch nutzen viele unser Kunden noch ältere MySQL-Versionen, wo dies nicht der Fall war. Zum Glück gibt es aber aber auch etablierte, althergebrachte Werkzeuge, die unmittelbar genutzt werden können und immer noch gute Dienste leisten.

Mehr dazu unter: https://blog.ordix.de/eile-mit-weile-mysqldumpslow