Moderne MySQL-Forks und -Patches

Gina Sanders, Fotolia

Wer die Wahl hat …

MySQL ist die Standardlösung für freie relationale Datenbanksysteme im Web-Bereich. In den letzten Jahren ist durch neue Forks, weitere Storage Engines und gepatchte Versionen das Feld sehr unübersichtlich geworden. Höchste Zeit, sich einen Überblick über die wichtigsten Angebote zu verschaffen.
Immer größere Datenmassen sicher zu speichern ist eine Herausforderung für jede IT-Infrastruktur. Schon mit Gigabit-Ethernet lassen sich aber ... (mehr)

Ist der MySQL-Server zu langsam, gibt es verschiedene Lösungsstrategien: Neben dem Optimieren von Abfragen und Indizes [1], dem Überarbeiten der Konfiguration und Aufrüsten der Hardware bietet sich der Umstieg auf eine angepasste Version des MySQL-Servers an. In den letzten Jahren wurde eine kaum überschaubare Anzahl an Patches, Forks und neuen Storage Engines veröffentlicht. Für anspruchsvolle Entwickler und Datenbank-Administratoren bedeutet dies eine Abkehr von der einfachen Wahl der MySQL-Standard-Distribution.

Kleine Pflaster

Viele Verbesserungen für MySQL kommen von großen Unternehmen wie Facebook [2], Google [3], das unter anderem ihren Adwords-Dienst auf der Basis von MySQL betreibt, wie auch von MySQL-Spezialisten wie Percona [4], die durch den zur Pflichtlektüre gewordene "MySQL Performance Blog" [5] bekannt wurden. Prinzipiell lassen sich die Patches in drei Kategorien einteilen: erstens Verbesserungen am Reporting, zweitens Funktionserweiterungen des MySQL-Kerns und der Datenbank-Engines, drittens reine Performance-Optimierungen. In der Regel erweist sich ein Zusammenspiel von Patches aus allen drei Kategorien als sinnvoll.

Der Umstieg auf einen selbst gepatchten und kompilierten Datenbankserver mag jedoch abschrecken. Erfreulicherweise bieten Projekte wie Ourdelta.org Repositories mit sinnvoll gepatchten und vorkompilierten MySQL-Paketen für gängige Distributionen wie Debian, Ubuntu und Centos/RHEL an. Die im folgenden besprochenen Patches sind ein Auszug aus den aktuellen Ourdelta.org-Versionen des MySQL-Servers, deren vollständige Patch-Liste mit Hinweisen zur Nutzung online einsehbar ist. [6]

Reporting

Erweitertes Reporting erlaubt es, genauere Daten über das Verhalten des MySQL-Servers unter Last zu sammeln. Bisher war vor allem das wenig konfigurierbare »slow.log« erste Anlaufstelle. Sein Nutzen beschränkte sich aber darauf, einzelne rechenintensive Queries anhand verbrauchter Zeit und nicht genutzter Indizes aufzuspüren. Das Patch Microslow bietet neue Filter, um gezielter nach ungünstig formulierten Abfragen zu suchen. So lassen sich Queries loggen, die für das Schreiben temporärer Tabellen auf der Festplatte, vollständige Tabellenscans oder das Lesen einer frei definierbaren Mindestzahl von Tabellenzeilen verantwortlich sind. Das eher unbekannte, aber zur MySQL-Standard-Distribution gehörende Slowlog-Statistiktool »mysqldumpslow« ist entsprechend angepasst, um auch die erweiterten Einträge einlesen und auswerten zu können.

Ebenso hilfreich sind kumulierte Laufzeitstatistiken über das tatsächliche Nutzungsverhalten. Das Userstats-Patch erweitert MySQL hierfür um Statistiken für Benutzer, Clients, Tabellen und Indizes. Wenn der Admin die Datensammlung in der »my.cnf» oder zur Laufzeit per SQL-Befehl »SET GLOBAL userstat_running = 1« aktiviert hat, füllt MySQL die vier Tabellen »USER_STATISTICS« , »CLIENT_STATISTICS« , »INDEX_STATISTICS« und »TABLE_STATISTICS« im Schema »information_schema« kontinuierlich mit statistischen Daten, die sich über den »SHOW« -Befehl abrufen lassen. Das Kommando »SHOW TABLE_STATISTICS« liefert eine tabellenweise Auswertung über gelesene und geänderte Zeilen sowie aktualisierte Indizes.

Besonders hilfreich ist der direkte Zugriff auf die Statistiktabellen in »information_schema« , da sie als normale Tabellen ansprechbar und die Ergebnisse gezielt manipulierbar sind. Listing 1 zeigt eine Abfrage nach den fünf Tabellen mit den meistgelesenen Zeilen. Dieses Beispiel aus dem Livebetrieb der Rails-basierten Film-Community Moviepilot und der zugrunde liegenden Filmdatenbank OMDB (beide für diese Auswertung anonymisiert) zeigt einen auffällig häufigen Lesezugriff auf die »images« -Tabelle.

Listing 1

Das Userstats-Patch im Einsatz

 

Im nächsten Schritt kann der Datenbankanwender ausprobieren, ob Code-Optimierungen die Zugriffe minimieren können oder weitere Änderungen am Format der Tabelle Zeiteinsparungen bringen. Verdächtig ist außerdem die verhältnismäßig schreib-intensive Tabelle »movies« mit ihrer zugleich hohen Anzahl von Index-Aktualisierungen.

Da sich die Statistiken zum Beispiel per »FLUSH TABLE_STATISTICS« bequem zurückgesetzen lassen, bietet sich eine Intervall-basierte Auswertung über ein selbst geschriebenes Munin-Plugin oder ähnliche Methoden an. Hier können nachträglich Lastspitzen in Relation zu Tabellen-Zugriffen und -Änderungen untersucht werden.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite