So we tested the 5.6.7-RC. And ran into a strange problem:

Because of a test, a preexisting configuration with GTID enabled existed, and suddenly we did not have properly initialized grants in mysql.* created for a new installation. Turns out: GTID and non-transactional tables are no friends, and that is even documented.

When using GTIDs, updates to tables using nontransactional storage engines such as MyISAM are not supported. This is because updates to such tables mixed with updates to tables that use a transactional storage engine such as InnoDB can result in multiple GTIDs being assigned to the same transaction.

Also, this is supposed to work with GRANT and REVOKE, but not with INSERT and DELETE. Now guess what mysql-install-db and friends are using?

server:~ # less …

Mein Kollege Dennis Kaarsemaker hat jetzt einen Artikel zu dem Replication Load Monitor von Booking.com gebloggt. Der Monitor basiert auf Arbeiten von Mark Leith.

Möge er Euch allen nützen.

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. …

Florian Haas von Linbit (den DRBD-Leuten) kündigt einen Webcast für den 7. April an: MySQL scale-out with replication and Pacemaker. Pacemaker ist, was aus dem Heartbeat des Linux-HA Projektes geworden ist.

Der Webcast wäre sein Vortrag für die MySQL-Konferenz geworden, wenn sein Papier angenommen worden wäre. Jetzt macht er es so einem größeren Publikum zugänglich - und das kostenfrei und ohne lästige Anreise. Der Vortrag dauert 45 Minuten und wird am 7. April um 15 Uhr UTC (17 Uhr MESZ) stattfinden.

(Kostenfreie Registrierung …

Lars Thalmann hat auf der OSCON einen Vortrag gehalten zum Thema "The Future of MySQL Replication". Die Slides zum Vortrag hat er in seinem Blog zum Runterladen bereitgestellt.