Immer größere Datenmassen sicher zu speichern ist eine Herausforderung für jede IT-Infrastruktur. Schon mit Gigabit-Ethernet lassen sich aber ... (mehr)

Percona Xtradb

Noch einen Schritt weiter als das Innodb-Plugin geht Percona Xtradb [9] . Dabei handelt es sich um die Zusammenführung einer aktuellen Innodb-Plugin-Version mit weiteren Performance- und Feature-Patches. Von der Codebasis her stellt Xtradb damit die innovativste Innodb-Version dar. Vom Namen sollte man sich nicht abschrecken lassen: Xtradb ist eine Innodb-Engine. Die Namensänderung soll lediglich den starken Unterschied zu der mit MySQL ausgelieferten Innodb-Version unterstreichen.

Die Installation von Xtradb gestaltet sich am einfachsten durch Rückgriff auf die von Ourdelta.org paketierten Mariadb-Pakete. Mariadb [10] wiederum ist ein MySQL-Fork des MySQL-Entwicklers Michael "Monty" Widenius. Widenius arbeitet an einer transaktionalen Alternative zu Myisam – der neuen Maria-Engine. Zugleich nimmt der Mariadb-Fork erfreulicherweise Xtradb als leistungsstarke Innodb-Aktualisierung auf.

Für den Administrator bedeutet dies gleich ein ganzes Bündel an Optimierungen: eine aktuelle MySQL-Version, überarbeitet durch das Mariadb-Projekt und erweitert um Xtradb (und Maria), sowie zusätzliche Patches durch das Ourdelta.org-Projekt.

Eine Konvertierung von Innodb-Tabellen nach Xtradb ist nicht notwendig, da Xtradb wie das Innodb-Plugin als Ersatz für die Standard-Innodb-Engine funktioniert. Bestehende und neue Innodb-Tabellen verwaltet Xtradb automatisch. Ein Downgrade auf das Innodb-Plugin und die Standard-Innodb-Engine ist möglich. Über »SHOW ENGINES« zeigt sich Xtradb weiterhin als Innodb – hier sind auch die weiteren modernen Engines wie Maria und PBXT zu sehen. Listing 4 zeigt zum Beispiel die Engines eines aktuellen Mariadb-Servers.

Listing 4

Engines eines Mariadb-Servers

 

Mehrere Tests auf Livesystemen erwiesen den Umstieg auf das Mariadb-Paket als weitgehend unproblematisch. Myisam-Tabellen blieben unberührt, Innodb-Tabellen funktionierten weiter. Lediglich MySQL-spezifische Konfigurationen in der »my.cnf« werden etwas strikter interpretiert. Die Zeile »sql-mode=NO_ENGINE_SUBSTITION,TRADITIONAL« versetzt MySQL in den Traditional-Modus, der viele Warnungen als Fehler behandelt. So lief eine Rails-Datenbankmigration nicht, da sie nicht standardkonforme Queries verwendet, etwa Defaultwerte für Text- und Blob-Felder.

Im Nicht-Traditional-Modus ignoriert MySQL die Defaultwerte und führt die Queries dennoch aus, im Traditional-Modus endet die Query mit einem Fehler. Es empfiehlt sich daher in vielen Fällen, die Zeile auf »sql-mode=NO_ENGINE_SUBSTITUION« zu ändern und den Server neu zu starten. Hierbei handelt es sich nicht um ein Problem mit Mariadb, sondern nur um eine sehr restriktive Konfiguration nach MySQL-Standard. Zusätzlich ist zu prüfen, ob Programme, die gegen Libmysqlclient-dev kompiliert sind, noch einmal gegen die aktuelle Libmariadbclient-dev kompiliert werden sollten. In Rails-Umgebungen ist das zum Beispiel das MySQL-Gem.

Neben den bereits beschriebenen Vorteilen des Innodb-Plugins bietet Xtradb noch einmal einen deutlichen Performance-Gewinn, wie diverse Benchmarks mit verschiedenen Setups belegen [11] . Es gibt etliche weitere Funktionen, die die Arbeit für Entwickler und Administratoren erleichtern. Erwähnt sei hier noch die Möglichkeit, den Innodb-Buffer auf die Festplatte schreiben zu lassen. Bei einem notwendigen Neustart des MySQL- oder Mariadb-Servers verliert die Innodb-Engine ihren wertvollen Buffer Pool im Arbeitsspeicher.

Der kann je nach Konfiguration und Nutzung mehrere GByte groß sein und wird typischerweise im Laufe von Stunden befüllt. Das Speichern dieses Buffer Pools vor dem Beenden und Laden nach dem Neustart spart wertvolle Warmup-Zeit, die sich sonst durch langsame Antworten des Datenbankservers bemerkbar macht. Listing 5 zeigt die Befehle und Rückgaben für das Speichern und Laden des Buffer Pools.

Listing 5

Buffer Pool speichern und laden

 

Drizzle

Nicht unerwähnt bleiben darf die Neuentwicklung Drizzle [12] . Der Fork setzt nach eigenen Aussagen auf die frühen Werte von MySQL: Einfachheit, Zuverlässigkeit und Performance. Drizzle basiert ursprünglich auf dem Code des noch nicht veröffentlichten MySQL 6.0 und verfolgt vor allem die Entfernung nicht benötigter Funktionen und Reduzierung von Komplexität. Die Drizzle-Entwickler haben radikal Gebrauch vom Feature-Rotstift gemacht: So entfernten sie die Storage-Engines Federated und Merged, andere wie CSV und Myisam sind nur noch temporäre Engines. Moderne Engines wie Xtradb pflegen sie in einem eigenen Branch.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023