Seite wählen

NETWAYS Blog

MySQL New Features – Background I/O Threads

Vor knapp zwei Wochen hatte ich die MySQL New Features Serie mit dem Thema Semisynchronous Replication gestartet. Als eines der Features, welches auch ohne tief gehendes Verständnis der Datenbankarchitektur in vielen Umgebungen Verwendung finden kann, bereits eine echte Bereicherung.
Gerade unter der Haube im Bereich der Storage-Engines und vor allem InnoDB ist viel passiert. In den letzten Jahren musste sich MySQL immer wieder den Vorwurf gefallen lassen, aktuelle Hardware nicht ausreichend auszulasten und gerade im SMP-Bereich hinter alternativen Datenbank zurückzufallen. Einem besonderen Kritikpunkt hat sich SUN/Oracle ebenfalls in der Version 5.5 angenommen.
Gemeint sind hier die so genannten Background I/O Threads, welche für die Verarbeitung von Prefetches und dem Schreiben von Dirty Pages verantwortlich sind. Für das Prefetching kennt MySQL grundsätzlich zwei Entscheidungsregeln. Einmal das Vorablesen von Blöcken bei Identifizierung eines sequentiellen Lesevorgangs oder der überdurchschnittlicher Leserate in bestimmten Speicherblöcken und somit vorsorglicher Leseverarbeitung der beteiligten Blöcke. In den bisherigen MySQL-Versionen gab es hierfür genau einen Thread, der aktuelle Serverhardware und vorallem Speichersubsysteme nicht wirklich vollständig auslasten konnte. Hierfür gibt es seit Version 5.5 nun den Parameter innodb_read_io_threads, der eine dynamische Konfiguration der Read-Threads und somit optimierte Auslastung des Plattensubsystems ermöglicht.
In die andere Richtung, nämlich dem Schreiben von veränderten Datenblöcken aus dem Buffer-Cache auf die Disk ist ebenfalls die Möglichkeit zum Feintuning, hier innodb_write_io_threads entstanden. Bei modernen RAID-Controllern wird das Tuning der read_io_threads vermutlich den größeren Erfolg versprechen, da Schreibvorgänge häufig schon im Cache der Controller acknowledged und somit als abgeschlossen markiert werden.
Beide Parameter bedürfen im Praxisbetrieb genauer Beobachtung und können bei Überstrapazierung auch zu steigendem I/O-Waits auf den Disks führen. Wie immer bei Tuning gilt auch hier der Grundsatz nicht alle Schrauben gleichzeitig zu drehen, sondern verschiedene Kombinationen über die Zeit zu nutzen und die gewonnenen Ergebnisse zu dokumentieren und vergleichen.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

MySQL New Features – Semisynchronous Replication

Bereits seit dem 15. Dezember gibt es die aktuelle GA Release von MySQL in der Version 5.5. Obwohl ein großer Nutzerkreis der Datenbank, nach Installation und Anlage von Benutzern, häufig keine größere Aufmerksamkeit zukommen lässt, lohnt es sich durchaus einen genaueren Blick auf die neuen Features zu werfen. In den nächsten Woche werde ich die aus meiner Sicht wichtigsten Themen zusammenfassen und Euch zum Wochenende damit beglücken.
Starten möchte ich die Serie mit einer kleinen Einführung in die Semisynchronous Replication. Dieses von vielen lang erwartete Feature löst den bisher nicht vorhandenen Transaktionskontext über verteilte Replikationsumgebungen nun endlich auf. Aber was heisst das nun genau?
In einer normalen (synchronen) Replikationsumgebung schreibt die Master-DB alle Änderungen in lokale Binlogs und schert sich nicht über die weitere Bearbeitung durch einen oder mehrer Slaves. Diese Entkopplung zwischen Spooling der Änderungsdaten und spätere Einarbeitung in den Slaves bietet zwar einen Performancevorteil, kann bei Ausfall des Masters im weiteren Verlauf jedoch den Verlust von Daten zur Folge haben.
Wenn in einer Datenbankumgebung transaktionsorientiert gearbeitet wird, also mit autocommit=0 oder Initierung durch den Befehl start transaction, hat dies zur Folge, dass erst nach dem nächsten Commit die Daten für alle anderen Benutzer sichtbar geschrieben werden. Voraussetzung hierfür ist der Einsatz von InnoDB, welche seit Version 5.5 auch Standard-Engine, und die  ACID-Kriterien erfüllt. Sobald der Benutzer den Commit abgesetzt hat, werden die Daten geschrieben und für das lokale System ist die Integrität hergestellt. Was aber wenn ein angeschlossener DB-Slave die Daten noch nicht eingearbeitet hat und es nun zu einem Ausfall des Masters kommt? Genau hier setzt die Semisynchronous Replication an. Bei Aktivierung, welcher für Master und Slave erforderlich ist, bekommt der Benutzer erst dann einen Status „committed“ wenn die Transaktion auf mindestens einem Slave eingearbeitet ist. So kann auch in verteilten Umgebungen die Integrität auf mindestens einem weiteren Knoten sichergestellt werden. Bei Ausfall aller Slaves springt die Datenbank nach einem gewissen Timeout in die normale (synchrone) Replikation zurück und stellt so trotzdem die Verfügbarkeit sicher. Sobald wieder ein Slave verfügbar ist, wird natürlich wieder die Semisynchronous Replication verwendet. Über einige neue Servervariablen kann der Admin auch die entsprechenden Transaktionen im System sichtbar machen. So gibt die Variable Rpl_semi_sync_master_no_tx beispielsweise Auskunft über noch offene Transaktionen, welche noch nicht auf einem Slave committed wurden.
Für alle, denen eine replikationsübergreifende Transaktionssicherheit wichtig ist, ist dieses Feature ein Muss.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Nagios 3 New Features – Serie

In den vergangenen Wochen haben wir immer wieder einige Neuerungen von Nagios 3 vorgestellt und sind in kurz Beispielen darauf eingegangen. Nachfolgend haben wir nochmals die vergangenen Posts zusammengestellt um einen Überblick über die aus unserer Sicht wichtigsten Features zu geben.

Selbstverständlich gab es darüber hinaus noch eine Vielzahl an Änderungen und Erweiterungen. Eine vollständige Liste findet ihr auf nagios.org. Gerne stehen wir natürlich für weitere Fragen zu Nagios zur Verfügung. Entweder via Kommentar oder vielen anderen Möglichkeiten welche unserer Site zu entnehmen sind.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Nagios 3 New Features – Custom Object Variables

Bei Nagios wurde immer wieder die Möglichkeit vermisst, eigene Informationen an Objekte wie Host und Services zu binden und so zusätzliche Angaben wie SNMP-Community oder ICQ-Number zu speichern. Auch Standortangaben wie Rackplatz und ggf. Serverraum sind immer wieder von Bedeutung.
Mit Nagios 3 haben Administratoren genau diese Möglichkeit indem Sie den entsprechenden Variablen bei Host-, Service und Contakt-Definition ein „_“ voranstellen.
So könnte eine Hostdefinition dann aussehen:

define host{
   host_name	netways_server
   _dc_name	RZ1; Angabe des Rechenzentrums
   _dc_rackr	R104;	 Angabe des Racks
   }

Die entsprechenden Variablen werden über Templates bei Bedarf auch vererbt und können mit Hilfe von Macros in anderen Scripts verwendet werden. Eine detaillierte Auskunft gibts in der offiziellen Doku.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.