Häufig wird bei Geschwindigkeitsproblemen auf die MySQL-Engine MyISAM verwiesen. Diese sei deutlich schneller als die InnoDB Variante. Wenn nur Performance wichtig ist, mag dies stimmen, aber wenn das Kriterium Datenqualität dazu kommt, dann ist MyISAM nur noch zweite Wahl.

Die DOAG ("Deutsche ORACLE Anwendergruppe e.V.") ist das Netzwerk der deutschen Oracle-Community mit über 3500 Mitgliedern. Im November dieses Jahres (vom 16.-18.) findet wieder die jährliche DOAG 2010 Konferenz in Nürnberg statt.

Diese Konferenz kann man mit Recht als eine Institution betrachten – sie findet dieses Jahr zum 22. Mal statt. Geboten werden mehr als 400 Vorträge von über 300 Sprechern. Zum ersten Mal wird es auf der diesjährigen Konferenz auch einen eigenen Stream zum Thema MySQL geben. Ich werde dabei sein und zwei Vorträge zum Thema MySQL-Replikationstechnologien sowie Werkzeuge zur MySQL-Administration geben.

Hier ist der aktuelle Stand der Vorträge im MySQL-Stream:

Dienstag, 2010-11-16

• 10:00-10:45: …

In diesem Kommentar versprach ich:

Für den von Dir genannten Sonderfall der Filialsysteme habe ich noch einen deutschen Artikel in der Warteschlange, ich muß nur Zeit finden ihn zu schreiben.

Normalerweise sieht MySQL Replikation so aus:

MySQL Replikation - Architekturübersicht Master Binlog

Auf dem Master ist mit der Konfigurationsanweisung log_bin das Binlog aktiviert.

Das Binlog loggt bei Statement Based Replication (SBR) alle Anweisungen, die Daten verändern (also quasi alles außer SELECT). Binlog-Dateien haben dasselbe Namensprefix und werden dann durchnumeriert. Die Datenbank beginnt ein neues Binlog, wenn die laufende Binlog-Datei größer als max_binlog_size (Default 1G) wird, wenn das Kommando FLUSH LOGS ausgeführt wird oder wenn der Server neu gestartet wird. …

FromDual veröffentlicht seine Datenbank Performance Monitoring Lösung für MySQL / MariaDB. Diese Lösung verfügt über Monitoringmöglichkeiten für die meisten MySQL Storage Engines (Aria, InnoDB, MyISAM, NDB, PBXT und XtraDB). Im Weiteren können MySQL Master - Slave Replikationen, UNIX Prozesse (mysqld, ndbd) und MySQL/MariaDB spezifische Informationen überwacht werden.
Mehr Informationen finden sie auf der Seite Performance Monitor für MySQL.

Lalufu fragt:

Ich habe eine MM-Replikation mit zwei Servern. Beide haben auto_increment_increment=10, Server A hat auto_increment_offset=0 und Server B hat auto_increment_offset=1.

Ich lege mir eine Tabelle mit einem auto_increment-Feld (id) an und mache auf Server A einen INSERT, dann kriegt die row id=0, und wird auf B repliziert, richtig? Dann noch einen INSERT auf A, die row kriegt id=10, und wird auf B repliziert.

Wenn ich jetzt auf B einen INSERT mache, welchen Wert kriegt das id in der row?

Statt einer Antwort hier die Methode zum selber rausfinden.

Wir installieren zwei MySQL-Instanzen zum Testen (Mac OS X mit Macports). Das ist recht einfach, denn dazu muß man nur zwei Datenverzeichnisse mit mysql_install_db initialisieren und passende minimale Konfigurationen …

Immer mal wieder kommt jemand im Internet auf die Idee, wie man Master-Master und verteilte Transaktionen ganz einfach realisieren kann. MySQL verteilte Daten von Okami ist ein gutes Beispiel für diese Idee:

Wir nutzen dabei aus, dass MySQL bei zusammengesetzten Indizes einen AUTO_INCREMENT-Wert pro distinktem Schlüsselpräfix zählt.

Das heißt ganz konkret: Wir legen einen Primär-Schlüssel aus zwei Spalten zusammen. In der ersten Spalte verwenden wir einen sehr kleinen Wert, der die Quelle der Daten kennzeichnet: Source tinyint unsigned NOT NULL; Den zweiten Teil legen wir als einfache ID int unsigned NOT NULL AUTO_INCREMENT an. Und ein Timestamp-Wert bietet sich für das Triggern der Updates an.

Diese Lösung ist exemplarisch schön, weil sie beide Fehlannahmen enthält, die man bei der direkten Lösung des Problems machen kann. …

Ich möchte nur kurz auf einige Konferenzen mit MySQL-Inhalten aufmerksam machen, die in der nächsten Zeit so anstehen:

Am nächsten Wochenende (21. und 22. August) findet in Sankt Augustin bei Bonn die Free and Open Source Software Conference (FrOSCon) statt. Auch in diesem Jahr wird es wieder einen von mir organisierten Track namens "OpenSQL Camp" geben. Es wird insgesamt 12 Vorträge rund um das Thema MySQL und andere Open-Source Datenbanken geben. Darüberhinaus haben die Veranstalter der FrOSCon einen dedizierten Track zum Thema "NoSQL Datenbanken" zusammengestellt. Es wird also reichlich Information zum Thema …

MySQL mit memchached wurde zur Grundlage für viele dynamische Webdienste - und wird auch weiterhin in vielen Fällen das Fundament bilden. Diese Kombination hat sich in einigen der größten und produktivsten Webpräsenzen bewährt. Es gibt allerdings bestimmte Webdienste, die sehr aktualisierungsintensiv sind und daher Echtzeit- Reaktionsverhalten und ständige Verfügbarkeit erfordern.

In diesen Fällen bietet MySQL Cluster die gewohnten Eigenschaften und einfache Nutzung des regulären MySQL Server, ermöglicht aber erheblich bessere Schreibleistung bei weniger Komplexität, niedrigerer Latenz und 99,999% Verfügbarkeit. In diesem Webseminar werden die Anwendungsbereiche für beide Ansätze betrachtet und es wird aufgezeigt, wie Sie mit MySQL Cluster aktualisierungsintensive Webdienste skalieren können.

Date and Time: Wednesday, 08 Sep 2010, 15:00 CET

Nachdem ich in meinem Blog bisher ausschließlich auf Englisch geschrieben habe, bin ich nun zu dem Entschluß gekommen, ab und zu auch mal Artikel und Kommentare zum Thema MySQL auf Deutsch zu verfassen. Wenn es in Zukunft also um Themen geht, die primär für Anwender aus dem deutschsprachigen Raum (der berühmten DACH-Region) interessant sind (z.B. Hinweise auf Veranstaltungen, Konferenzen oder Treffen von MySQL-Anwendergruppen), werde ich es in dieser Kategorie vermelden.

Der deutschsprachige Teil von Planet MySQL sucht auf jeden Fall noch weitere Autoren! Falls Ihr also noch deutschsprachige Blogger kennt, die ab und zu mal das Thema MySQL behandeln - hier kann man einen RSS Feed anmelden!

Anbei eine kleine Idee für alle, die verteilte Datenhaltung haben, und dazu eine architektonisch recht einfache Synchronisation brauchen. Manchmal kommt aus diversen Gründen ein Replikationsmechanismus nicht in Frage. Dafür nun die folgende Idee. Wir nutzen dabei aus, dass MySQL bei zusammengesetzten Indizes einen AUTO_INCREMENT-Wert pro distinktem Schlüsselpräfix zählt. Das heißt ganz konkret: Wir legen einen [...]