Ich bin der Meinung, dass es sich gehört, dass Blogs Kommentare zulassen. Ist dies nicht der Fall, wird aus einem Blog zu schnell ein authistisches Tagebuch.
In diesem Blog fragt sich der Autor, ob er einen Bug in den neueren MySQL-Versionen (>5.1.x) gefunden hat:

mysql>SELECT BENCHMARK(100, fibonacci(10000));
ERROR 1690 (22003): DOUBLE value is out of range in '(f1@1 + f2@3)'


Uups, was ist das. Die MySQL Version 5.5.9 steigt mit einem SQL-Fehler (ERROR 1690) aus. Ist dies ein Bug?


Ganz im Gegenteil die Fehlermeldung ist hier genau richtig. Denn die Fibonacci-Reihe übersteigt den Definitionsbereich von DOUBLE. Das tat es schon in der 5.1.x und früher. Nur jetzt gibt es eben einen Fehler .. was gut ist!
Warum die genutzte Funktion …

"Kris, kannst Du bitte mal gucken?"

Seit heute morgen, 10:00 Uhr, wächst das Undo Log immer weiter an.

Immer wenn InnoDB Daten schreibt wird die alte Version einer Zeile aus der Tabelle in das Undo-Log verschoben, also physikalisch von der ibd-Datei der Tabelle in die ibdata1 im Datadir von MySQL. In der Tabelle wird in der veränderten Zeile ein Zeiger von der neuen Version auf die alte Version der Zeile im Undo-Log installiert, der Roll(back)-Pointer. Die alte Version im Undo-Log zeigt mit ihrem eigenen Roll-Pointer auf eine noch ältere Version derselben Zeile und so weiter - es entsteht für jede Zeile in der Datenbank eine lineare Liste von Versionen in die Vergangenheit einer Row.

Der InnoDB Purge Thread hat die Aufgabe, das Undo Log zu verkürzen. Wenn er das nicht tut, dann sieht das so aus wie oben im Graphen gezeigt. Dafür kann es zwei Gründe geben: Purge Lag - also mehr Writes als der Purge Thread …

Am Donnerstag, den 19. Mai 2011 findet in Hannover die Gründungsversammlung der DOAG SIG - Database zum Thema "MySQL" statt. Es wird viele interessante Vorträge geben.

Mehr:
http://mydoag.doag.org/termine/termine.php?tid=423270

ALTER TABLE vs. Schemaless

ALTER TABLE in MySQL nervt. Das tut es in erster Linie, weil es die Tabellen, die es verändert, mit einem exklusiven Lock (Write Lock) belegt, während es die Änderung durchführt, und weil es die Änderung durch Umkopieren der Daten und Indices durchführt, was bei einer großen bestehenden Datenmenge doch recht lange dauern kann.

Es gibt inzwischen eine Reihe von Verbesserungen in MySQL 5.5, wenn InnoDB (inzwischen die Default Storage Engine) verwendet wird. Diese Verbesserungen beziehen sich zum größten Teil auf das Erzeugen und Löschen von Indices im Hintergrund, also ohne Lock und ohne den Betrieb aufzuhalten.

Auch für das Erzeugen und Löschen von Spalten oder das Ändern von Defaults gibt es Lösungen, die in InnoDB jedoch noch nicht umgesetzt sind. Die meisten dieser Lösungen basieren …

Ich brauche einmal Hilfe. Von Euch. Ich verstehe nämlich ein Konzept nicht. Es geht um den Begriff "Schemaless", der im Zusammenhang mit einigen NoSQL-Datenbanken verwendet wird.

Ich kann verstehen, daß für einige Leute ein ALTER TABLE wie in MySQL ein Problem ist, weil es Tabellen während der Schemaänderung lockt. Da ALTER TABLE in vielen Fällen die Daten zur Durchführung der Änderung umkopieren muß, kann dieses Lock entsprechend lange bestehen bleiben, wenn die Daten nur hinreichend groß sind.

Ich kann nicht verstehen, wieso Leute glauben, daß "Schemaless" da eine Hilfe wäre oder wieso Leute glauben, daß es so etwas wie "Schemaless" überhaupt gibt.

Daten in Datenbanken existieren ja in der Regel nicht im luftleeren Raum, sondern sie werden von Code genutzt. Dieser Code macht Annahmen über die Attribute, die in einer Tabelle (oder was immer Euer NoSQL als Tabellenäquivalent verwendet) existieren …

Nach einigen Jahren Pause war ich dieses Jahr einmal wieder auf der MySQL Conference & Expo, diesmal erstmals in einer neuen Rolle, als Aussteller: Mein Arbeitgeber hat eine Box auf der Ausstellung dort gemietet, weil wir dort Werbung für Booking.com als Arbeitgeber machen sollen.

Das hat bemerkenswert gut geklappt, und die Organisation der Konferenzpausen hat da sicher mit dazu beigetragen: O'Reilly baut die Kaffee- und Eiscremetische in den Konferenzpausen jetzt nur noch in der Ausstellungshalle auf. Außerdem gibt es ein Begleitheftchen zur Ausstellung, in dem man einer Bingo-Karte gleich die Aussteller finden kann und bei dem man gewinnen kann, wenn man sich nur genügend Besuche bei den Ausstellern bescheinigen läßt. Natürlich kommen viele nur vorbei, …

Moinsen,
Leser von planetmysql.org haben folgende Meldung schon lesen dürfen. Lenz Grimmer ist  nicht mehr im Community Team von MySQL. Im Gegensatz zu anderen verlaesst Lenz nicht Oracle, sondern beschaeftigt sich mit neuen Themen innerhalb von Oracle.
Auch wenn er sich freut, finde ich es selbstredend doof, dass so eine Mischung von Kompetenz und Symphatie eine Luecke zuruecklassen wird, welche schwer zu fuellen ist.
Alles Gute und bis Bald.

Gegeben:

root@localhost [test]> select version();
+------------+
| version()  |
+------------+
| 5.5.10-log |
+------------+
1 row in set (0.00 sec)

Doing:

root@localhost > create table a (id int) engine=myisam;
Query OK, 0 rows affected (0.01 sec)

Ok das ist nichts ungewöhnliches.

root@localhost > create table aa (id int) engine=innodb;
ERROR 1173 (42000): This table type requires a primary key

Hups das ist aber gar nicht usus einen PK zu fordern.

root@localhost > create table aa (id int primary key) engine=innodb;
Query OK, 0 rows affected (0.00 sec)

Und nein es handelt sich hier nicht um eine inkompatible Änderung seitens MySQL, sondern meinereiner hat riesige Mengen von …

Auf dem diesjährigen Frühjahrsfachgespräch hielten  Lenz und ich Vorträge zu MySQL. Lenz hielt seinen Vortrag über Replikationstechniken und entfachte eine nette Diskussion zur Semisynchronous Replication. Mein Vortrag mit dem Titel Baukasten MySQL lies leider keinen Raum für Diskussionen:/

Was ich an der GUUG so mag, ist der akademische Habitus. Die Workshops sind immer wieder ein Genuß. Nicht unbedingt, weil der Vortragende/Leitende zwangsläufig ein Spezialist seines Faches ist, sondern weil es immer eine handvoll erschreckend fitter Teilnehmer gibt, die durch ihre Anregungen, Einwände, Erläuterungen etc. dem Workshop(Vortrag) seine Tiefe geben :D

Ich arbeite ja nun seit nunmehr fast 3 Jahren für ein kleines Reisebüro mit Hauptsitz in Amsterdam (Booking.com ist Teil der Priceline Group of Companies): Wir vermitteln Hotelzimmer auf Kommissionsbasis an Onlinekunden und bringen so jede Nacht einige hunderttausend Leute ins Bett.

Zu diesem Zweck betreiben wir eine dreistellige Anzahl von Datenbankservern auf CentOS-Basis in gut drei Dutzend Replikationshierarchien, die so gut es geht mit Puppet automatisiert administriert werden. Unsere Anwendungsentwickler malträtieren diese Kisten dann mit einer Apache/mod_perl-Anwendung. Weil wir weiterhin schneller als der Markt wachsen, suchen wir mehrere MySQL DBAs für die Standorte Amsterdam, NL und Cambridge, UK.

Ein Bewerber sollte einige Erfahrung mit MySQL im Betrieb haben, und sich insbesondere in den Bereichen InnoDB, Replikation und Partitionen auskennen. Gute …