Heute findet der User Group Sonntag, mit meinem Vortrag, und der offizielle Beginn der ORACLE Open World in San Francisco statt. Die DOAG wird auch präsent sein. Die MySQL Connect geht in ihren zweiten und letzten Tag. Der Tag wird mit dem ORACLE ACE Dinner und der OPN Exchange "After Dark" Reception enden. Mal schauen was der Tag sonst noch so bringen wird.

More:
https://blogs.oracle.com/optimizer/entry/day_1_of_oracle_openworld

Mit dem Empfang der Teilnehmer der MySQL Connect ging in San Francisco der erste Tag der MySQL Connect zu Ende. Es wurde in der MySQL Keynote die Version 5.6 angekündigt und die neuen Eigenschaften kurz erläutert.

Oracle präsentiert erstes Development Milestone Release von MySQL Cluster 7.3 - Die neue Version ist einfacher und flexibler

Erweiterungen sorgen für erhöhte Sicherheit und zusätzliche Hochverfügbarkeits-Optionen

Neueste Version der beliebtesten Open-Source-Datenbank ist schneller und skalierbarer

Jetzt geht es los. Die ORACLE Open World 2012 startet mit der MySQL Connect. Mal schauen wie es wird.

More:
http://www.oracle.com/mysqlconnect/index.html

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.

Das MySQL 5.5 auf Servern mit vielen CPU-Cores mehr Transaktionen als MySQL 5.1 durchsetzt, kann man vielen Benchmarks im Internet entnehmen. Allerdings werden bei diesem Benchmarks meist Server mit 32, 48 oder sogar 64 CPU-Cores eingesetzt, die nur in großen und sehr großen Unternehmen Verwendung finden. In kleinen und mittelständigen Unternehmen werden aber im Normalfall eher Single- oder Dual-CPU-Sockel Server verwendet, die mit 4-16 CPU-Cores aufwarten können. Welchen Leistungszuwachs kann bei dieser Server-Klasse erwartet werden? Diese Frage soll der folgende Benchmark klären.

Die Ausgangssituation:
Hardware:

Server: HP DL380 G7
2 x Intel® Xeon® Processor X5660 (6 Core)  2,8 GHz
56 GB RAM (DDR3-1333/PC3-10600)
HP QLogic Dual 8 GB FC-HBA
3 x HP 146GB 6G SAS 10K (Raid 1 + Hot Spare)

SAN:
2 x Qlogic Sanbox 5800 (Multipathing)

Ich habe heute an dem Problem weiter geforscht und wir haben etabliert, dass die Ursache nicht der Quelltext des betreffenden Diamond-Collectors sein kann.

Auf allen betroffenen Kisten habe ich dann gesehen, daß die entsprechenden Queries gegen Performance-Schema ein

CODE:mysql> select * from performance_schema.threads;

Empty set (0.01 sec)

zurück liefern.

Weitere Untersuchung stellt heraus: P_S ist aber an. Jedoch:

CODE:mysql> select * from performance_schema.setup_instruments;

Empty set (0.03 sec)

mysql> select * from performance_schema.setup_timers;

Empty set (0.01 sec)

mysql> select * from performance_schema.setup_consumers;

Empty set (0.02 sec)

…

Heute erreicht mich eine Mail, in der ein DBA sich über steigende Replication Delay in einer bestimmten Replikationshierarchie beschwert.

Das ist schlecht, denn die betreffende Hierarchie ist wichtig. Also die 'Wenn die nicht geht schlafen Leute unter Brücken'-Art von wichtig.

Die Theorie war, daß die Änderungsrate in dieser Hierarchie so hoch ist, daß die Schreiblast von MySQL Replikation, die ja Single Threaded ist, nicht mehr bewältigt werden kann. Für diese Theorie sprach nach dem ersten Augenschein, daß alle betroffenen Kisten keine lokalen Platten hatten, sondern auf einem Filer lagen, und Filer sterben wegen der hohen Kommunikationslatenz im SAN bei uns in der Regel weit vor lokalen Platten, wenn es um Replikation geht: Filer sind mehr so beim parallelen Schreiben mit mehreren Threads gut.

Wenn dem so wäre, wäre das schon einen Seufzer wert, denn die betreffende Replikationshierarchie war gerade beim …