Über den MySQL-Router haben wir hier bereits an mehreren Stellen berichtet. Er spielt bei MySQL-Hochverfügbarkeits-Lösungen (z. B. dem InnoDB-Cluster) eine zentrale Rolle. Seit der Version MySQL 8.0.17 wurde der Router um eine REST API erweitert. Über diese Schnittstelle lässt sich der Zustand und die ordnungsgemäße Funktionsweise überprüfen. In diesem Beitrag stellen wir ihnen den Funktionsumfang der jetzt aktuellen Version 8.0.29 vor.
Mehr unter: blog.ordix.de
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:
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:
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