Familienkreis

1994 waren die ersten Zeilen Quellcode für MySQL geschrieben. Vier Jahre später gründeten die Schweden Michael „Monty“ Widenius, David Axmark und Allan Larsson die Firma MySQL AB. Nach einigen Finanzierungsrunden durch Risikokapitalgeber übernahm Sun Microsystems sie im Jahre 2008 für eine Milliarde US-Dollar. Ein Jahr später schon kaufte Oracle wiederum Sun und entwickelt MySQL seitdem weiter.

Wegen seines Lizenzmodells und der einfachen Installation fand MySQL schnell Einzug in den Applikations-Stack vieler Web-Anwendungsentwickler, was sich in den Paketen LAMP, WAMP und MAMP (Linux/Windows/Mac, Apache, MySQL, PHP) widerspiegelt.

Neben der kostenlosen Nutzung bescherte seine offene Architektur MySQL eine hohe Verbreitung. Sie erlaubt unter anderem den Anschluss verschiedener Speichersubsysteme (Storage Engines). Das erste davon war MyISAM, das zwar keine Transaktionen bot, jedoch Daten flott lieferte und so bald zum Liebling der Webentwickler avancierte. Bis MySQL 5.5 war MyISAM die Standard-Storage-Engine, dann löste das transaktionsfähige InnoDB sie ab. Mit der Zeit entstanden eine ganze Reihe von Storage Engines. So kommt von der Firma Primebase mit PBXT eine weitere transaktionsfähige Engine mit verbesserter BLOB-Handhabung.

Lizenz erleichtert Weiterentwicklung

Die MySQL-Lizenz erlaubte es, den Code in eine eigene Version zu überführen, wenn diese ebenfalls der GPL unterlag. Deshalb kam es zu einigen Abspaltungen (Forks), zu neuen Firmen und Allianzen (s. Kasten „MySQL-Forks“). Das Benchmark-Team verließ im August 2006 MySQL AB und gründete die Firma Percona. Seitdem entwickelt das Unternehmen die GPL-Version der Storage Engine InnoDB unter dem Namen XtraDB weiter. Sie bleibt kompatibel zum Ahnen, verfügt aber über eine Reihe weiterer Funktionen. Außerdem bietet Percona sowohl zu MySQL 5.1 und 5.5 kompatible Versionen des eigenen Fork zum Herunterladen an. Sie enthalten einige Änderungen hinsichtlich Performance, Überwachung und Diagnose. So kann XtraDB servergeeignete (PCIe-)SSDs effizient nutzen, da sich die Größe der Datenblöcke per Konfigurationsparameter ohne Neukompilierung einstellen lässt.

Ein sogenannter FlashCache lässt sich als Puffer konfigurieren, was die Latenz beim Zugriff auf Festplatten mit SSD-Speicher reduziert. Dabei kommt unter Linux ein Kernel-Modul zum Einsatz, das Mohan Srinivasan und Mark Callaghan 2010 bei Facebook entwickelt (PDF) und unter der GPL2 auf GitHub veröffentlicht haben.

Für RAM-hungrige Datenbank-Anwendungen schuf Percona einen Mechanismus, der die Aufwärmzeit für den Cache des Buffer-Pools reduziert. Ist ein Datenbankserver mit viel Speicher ausgerüstet, nutzt InnoDB ihn zumeist als Buffer-Pool, um I/O-Zugriffe auf die langsamen Festplatten zu vermeiden. Der Buffer-Pool besteht aus vielen Seiten (pages), in denen Daten von Abfragen, Änderungen, Transaktionen oder eines Index stehen können. Beim „Warm-up“ lädt sie der Server nach einem Neustart von den Massenspeichern in den Hauptspeicher. Je mehr RAM zur Verfügung steht, desto länger dauert dieser Aufwärmvorgang. XtraDB liest beim Neustart eine Liste der zuletzt benutzten Speicherseiten (Least Recently Used, LRU), um den Buffer-Pool der Storage Engine wiederherzustellen. Diese LRU-Liste schreibt ein Hintergrundprozess alle fünf Minuten, was die Antworten der Datenbank-Engine kaum messbar verzögert.

Mehr Informationen und Statistiken

Alternativ lässt sich die Aufwärmphase durch das Ausführen bestimmter Abfragen verkürzen. Große und oft genutzte SQL-Queries können auf diese Weise häufig benötigte Daten in die Caches der Storage Engine befördern. Die Datei mit den Abfragen gibt man zur Startzeit mit dem Parameter - -init-file an. Um diese Funktionen zu realisieren, hat Percona einiges an der Speicherverwaltung und -konfiguration geändert. Beispielsweise verwendet XtraDB mehr Mutexe als MySQL, die Konflikte bei konkurrierendem Zugriff auf den InnoDB-Buffer-Pool regeln.

Einige Percona-Erweiterungen an MySQLs Metadaten-Schema INFORMATION_SCHEMA erleichtern das Überwachen der Datenbank. So kann man zum Beispiel zu Diagnosezwecken Inhalt und Art der im InnoDB-Buffer-Pool gespeicherten Seiten (Pages) einsehen. Mit

select * 
 from INFORMATION_SCHEMA.index_statistics 
 where table_name='tabellen_name'; 

und

select * 
 from INFORMATION_SCHEMA.table_statistics 
 where table_name='tabellen_name'; 

lassen sich Statistiken der Index- und Tabellennutzung einer spezifischen Datenbank-Tabelle betrachten. Um Statistiken der Zugriffe verschiedener Anwendungen auf die Datenbank zu ermitteln, schaltet man mit

set global userstat = 1; 

das Protokoll ein. Danach liefert die Abfrage

SELECT * FROM 
   INFORMATION_SCHEMA.client_statistics\G 

CLIENT: 192.168.0.22
      TOTAL_CONNECTIONS: 15
 CONCURRENT_CONNECTIONS: 2
         CONNECTED_TIME: 0
              BUSY_TIME: 23
               CPU_TIME: 45
         BYTES_RECEIVED: 9087
             BYTES_SENT: 177415
   BINLOG_BYTES_WRITTEN: 217
           ROWS_FETCHED: 81
           ROWS_UPDATED: 0
        TABLE_ROWS_READ: 164825112
        SELECT_COMMANDS: 122
        UPDATE_COMMANDS: 9
         OTHER_COMMANDS: 87
    COMMIT_TRANSACTIONS: 8
  ROLLBACK_TRANSACTIONS: 0
     DENIED_CONNECTIONS: 0
       LOST_CONNECTIONS: 0
          ACCESS_DENIED: 0
          EMPTY_QUERIES: 0
  TOTAL_CONNECTIONS_SSL: 0 

eine Ausgabe ähnlich der in Listing 1.

So lassen sich Daten über die Nutzung der Datenbank gewinnen, die MySQL nicht verrät. Beispielsweise kann man Clients identifizieren, deren Abfragen den Server besonders stark beschäftigen.

Abhilfe bei einem Performance-Engpass schafft Perconas Konfigurationsparameter innodb_lazy_drop_table. Beim Löschen einer Tabelle mit DROP TABLE prüft MySQL, welche Pages innerhalb des InnoDB-Buffer-Pools von der zu löschenden Tabelle betroffen sind und sperrt alle anderen Tabellen in dieser Zeit für den Zugriff, um die jeweiligen Pages aus dem Pool zu entfernen. Das kann besonders bei einem großem Buffer-Pool die Anwendungen länger blockieren, da die Suche darin mehr Zeit benötigt. Mit innodb_lazy_drop_table=1 markiert XtraDB die entsprechenden Speicherseiten zunächst nur, ein Hintergrund-Thread löscht sie dann nach und nach aus dem Pool. Das verhindert seine komplette Sperrung für alle anderen Abfragen.

Für das Sichern von MySQL-Datenbanken stehen neben dem MySQL-eigenen mysqldump und dem kommerziellen MySQL Enterprise Backup kostenlose Tools bereit. Während sich mysqlhotcopy nur für MyISAM-Tabellen eignet, erlaubt Perconas kostenloses XtraBackup das Sichern einzelner InnoDB-Tabellen ohne Table-Locks und das Erstellen inkrementeller Backups. Sie können auch komprimiert an den Sicherungsserver übertragen werden.

Hilfe von der Kommandozeile

MySQL bringt eine Reihe von Hilfsmitteln für die tägliche Administrations- und Entwicklungsarbeit mit. Darüber hinaus stehen freie Werkzeuge zur Verfügung, die weitere Aufgaben übernehmen. Maatkit und sein Nachfolger Percona Tools sind Sammlungen von Kommandozeilen-Tools, die sowohl Entwicklern von Datenbank-Anwendungen als auch Administratoren von MySQL-, MariaDB- und Percona-Datenbankservern nützen.

So findet das Kommandozeilenwerkzeug pt-duplicate-key-checker doppelte Indizes und Fremdschlüssel auf MySQL-Tabellen, und pt-online-schema-change ändert Schemata ohne Table Lock. Mit pt-query-advisor lassen sich Abfragen im Slow Query Log analysieren. Dabei gibt es Erklärungen zu den untersuchten Abfragen aus. Beispielsweise bekommt die Query SELECT * FROM tabelle das Etikett „CLA.001“, weil sie keine WHERE-Klausel enthält.

Beim Beschleunigen von Queries helfen Tools wie pt-index-usage, pt-pmp und pt-visual-explain. Letzteres analysiert dabei die Ausgabe von MySQLs EXPLAIN und erzeugt daraus eine Baum-Ansicht (s. Listing 2):

mysql -e "explain KOMPLEXE_QUERY" | pt-visual-explain 

Dem Administrator stehen Werkzeuge für die Datenbankkonfiguration zur Verfügung. pt-config-diff beispielsweise vergleicht die Konfiguration zweier Server sowohl hinsichtlich der MySQL-Konfigurationsdateien als auch der Server-Variablen. Percona bietet darüber hinaus Tools für die Überwachung von MySQL-, MariaDB-, und Percona-Servern. Dazu stehen Plug-ins für Cacti und für Nagios zur Verfügung (s. Abb.).

Das Verteilen von Datenbanken über Servergrenzen hinweg ist sowohl mit klassischer Replikation als auch per Clustering möglich. Oracle bietet mit der MySQL Cluster Carrier Grade Edition ein kommerzielles Produkt an. Anfang Juni stellte Percona seinen eigenen XtraDB-Cluster vor. Damit lassen sich Perconas Server in Umgebungen mit hoher Verfügbarkeit einsetzen und Daten über mehrere Serverknoten verteilen (Multi-Master-Replikation).

Dank Tokuteks TokuDB Storage Engine sollen MySQL-Server Big-Data-fähig werden. So verspricht die Firma eine 10- bis 50-fach schnellere Indizierung der Daten innerhalb des eigenen Speichersubsystems und fünfmal flotteres Schreiben bei Datenbanken der Terabyte-Klasse. Wer die Lizenzkosten von 2500 US-Dollar pro 100 GByte und Jahr nicht scheut, kann mit der TokuDB die InnoDB- oder XtraDB-Storage-Engine ersetzen.

Ramon Wartala

ist Diplom-Informatiker und arbeitet als Director Technology für die Online-Marketing-Agentur Performance Media Deutschland GmbH. Anfang 2012 erschien sein Buch „Hadoop – Zuverlässige, verteilte und skalierbare Big-Data-Anwendungen“.

Alle Links: www.ix.de/ix1208091

oot@pmdb1:~# pt-visual-explain --user=root --ask-pass --database=beispiel_db --host=db1.local --connect test_query.txt
 Enter password:
 Filesort
 +- TEMPORARY   table          temporary(aa,b,c)
     +- JOIN
        +- Bookmark lookup
        |  +- Table
        |  |  table          c
        |  |  possible_keys  PRIMARY
        |  +- Index lookup
        |     key            c->PRIMARY
        |     possible_keys  PRIMARY
        |     key_len        4
        |     ref            beispiel_db.aa.table1_id
        |     rows           1
        +- JOIN
           +- Bookmark lookup
           |  +- Table
           |  |  table          b
           |  |  possible_keys  PRIMARY
           |  +- Unique index lookup
           |     key            b->PRIMARY
           |     possible_keys  PRIMARY
           |     key_len        4
           |     ref            beispiel_db.aa.table2_id
           |     rows           1
           +- Filter with WHERE
              +- Bookmark lookup
                 +- Table
                 |  table          aa
                 |  possible_keys  order_id,idx_date
                 +- Index lookup
                    key            aa->order_id
                    possible_keys  order_id,idx_date
                    key_len        5
                    ref            const
                    rows           242314 

(ck)