So, nachdem ich nun auch den Seminarvortrag gehalten habe (mit dem ich im großen und ganzen recht zufrieden bin) möchte ich hier auch die Folien zu dem Vortrag  sowie den Quellcode der von mir vorgeführten Demo online stellen.

Kristian Köhntopp hat einen sehr schönen Artikel über die Funktionsweise von InnoDB sowie der Bedeutung der einzelnen InnoDB spezifischen Optionen in der my.cnf geschrieben. Vielen Dank!

Im moment mache ich ein interessantes Seminar am Institut für Telematik an der Uni-Karlsruhe. Es geht um Hacking, Hackerabwehr, etc. Die Ausarbeitung habe ich mal online gestellt. Ich hätte btw. nie gedacht, wie viele Fehler man in 15 Seiten einbauen kann.

Lustiges Detail am Rande: Aufgrund von Befürchtungen der Fakultät hat dieses Seminar eine Zeit lang jedes Wochen seinen Namen gewechselt. Aus “Hacking und Hackerabwehr” wurde “Hacker und Hackerabwehr”… Im moment heisst sie “Netzsicherheit und Hackerabwehr”.

In http://justinsomnia.org/2007/08/search-engine-marketeers-are-the-new-script-kiddies/ beschreibt Justin Watt, wie er eines Tages fesstellen musste, dass seine Seite plötzlich aus dem Google Index verschwunden war. Durch einiges Nachforschen stellt er fest, dass ein Suchmaschinenspammer daran schuld ist – aber lest selbst, der Artikel ist sehr spannend und lesenswert.

Bei einem Kunden haben wir neulich einige Datenbanken auf einen neuen Datenbankserver umgezogen. Da wir aus Latenzgründen jedoch nicht alle Anwendungen auf den neuen Server umstellen konnten (der neue Server befindet sich im Rechenzentrum eines anderen Providers), haben wir uns entschlossen, eine Kopie der Datenbanken auf dem bisherigen Datenbankserver zu belassen.

Nun stellte sich allerdings das Problem, dass wir irgendwie beide Datenbanken synchron halten mussten. Replikation war leider keine Option, da wir den besagten Server bereits mit einem Backup-Server replizierten. Auch das periodische ziehen eines Dumps kam nicht in Frage, da wir die Daten nach dem Schreiben sofort auf beiden Systemen benötigten.

Wir entschieden uns daher, die Pflegeanwendung in beide Datenbanken gleichzeitig schreiben zu lassen. Damit es zu keinen Problemen mit inkonsistenten Datenbeständen zwischen den beiden Servern kommt implementierten wir das Schreiben folgendermaßen:

Starte Transaktion auf Server 1
Starte Transaktion auf Server 2

For QUERY in QUERIES:
    Führe Query auf Server 1 aus
    Führe Query auf Server 2 aus

If !ERROR:
    Commite Transaktion auf Server 2
    Commite Transaktion auf Server 2

Else:
    Rolle beide Transaktionen zurück

In unseren Tests lief alles gut, das Transaktionshandling funktionierte. Selbst bei provozierten Fehlern verhielt sich alles so, wie erwartet.

Kurz nach der Installation der Anwendung beim Kunden traten jedoch Probleme auf mit einem Fall, den wir leider vollkommen übersehen hatten: Durch einen unglücklichen Umstand war es möglich, auf Server 1 ein Insert-Query auszuführen, das auf Server 2 fehl. Eigentlich sollte hier unser Transaktionshandling eingreifen und die Änderungen rückgängig machen.

So weit die Theorie. In der Praxis hat das Rollback zwar durchaus die Änderung rückgängig gemacht, hat allerdings das AUTO_INCREMENT Value nicht wieder dekrementiert. Dies bedeutete nun, dass das AUTO_INCREMENT auf Server 2 eins niedriger war als das auf Server 1, was dazu führte, das alle weiteren Updates fehlschlugen, da nun alle von unserer Tabelle abhängigen Foreign Keys schief standen.

Die rettende Idee kam von einem Kollegen: Nach dem ausführen des Insert Statements auf dem ersten Server lesen wir nun mit LAST_INSERT_ID() den Wert der AUTO_INCREMENT Spalte aus und fügen diese explizit in den Set Part des Statements, das wir auf dem zweitem Server ausführen, ein. Somit laufen die IDs nicht auseinander und unser Tag und die Applikation war gerettet.

MySQL überrascht mich immer wieder. Gerade ist mir aufgefallen, dass es in der Version 5.0 möglich ist, über mehrere Datenbanken hinweg Foreign Keys zu setzen. Der Syntax dafür lautet wie folgt:

FOREIGN KEY(`blub`) REFERENCES  `andereDatenbank.andereTabelle` (`column`) ON …

Und  ja, das funktioniert wirklich und ja, der MySQL Server enforced die Foreign Keys richtig. Und ja, ich bin mir ziemlich sicher, dass das in der Version 4.1 noch nicht ging.

Durch einen freundlichen Hinweis von Christoph erfuhr ich heute von einem Google Vortrag in der Uni, den ich auch spontan besuchte. Der Vortrag wurde von Thomas Hofman gehaltern, seineszeichens “Director of Engineering” bei Google in Zürich. Davor war er Professor an der ETH.

Der Vortrag war sehr interessant, einige bemerkenswerte Dinge möchte ich hier in Auszügen wiedergeben.

(weiterlesen…)

Einer meiner Kunden hatte nach einem Datenbankredesign das Problem, dass einige Anwendungen noch nicht auf das neue Datenbankdesign umgestellt war. Also hatten wir die Idee, mittels Views die alte Struktur auf Basis der neuen Datenbank nachzubauen. Es stellte sich nun folgendes Problem: Die neue Datenbank befindet sich auf einem ganz anderen Server wie die alte. Nach einigem Überlegen fassten wir den Plan, die Views auf dem entfernten Datenbankserver, auf dem sich auch die neue Datenbank befindet, zu definieren und diese als Federated Tables auf dem Datenbankserver, mit der alten Datenbank einzubinden. Zangsläufig ergab sich daraus für uns die Frage, ob es überhaupt möglich ist, Federated Tables auf Views zu definieren. Um es kurz zu fassen: Es ist möglich! Ein Select auf die Federated Table ist sogar recht performant.

Wie sich jedoch leider herausstellte, überträgt die Federated Storage Engine bei einem Join den gesamten Inhalt der Tabelle, was dazu führt, dass ein Join gelinde gesagt – äh – nicht wirklich performt. In unserem Testfall dauert ein Join über zwei Tabellen über 20 Sekunden. Insgesamt war die Lösung also leider nicht für den praktischen Einsatz geeignet.

Das Problem mit dem Join ist den MySQL Entwicklern übrigens bekannt, und Abhilfe wurde in Aussicht gestellt. In welcher Version diese Verfügbar sein wird, ist mir allerdings nicht bekannt.

19:55 < daniel> Kann mir jemand das hiererklären?
19:56 < daniel> some_binary: libgcc_s.so.1: version `GCC_4.2.0′ not found
(required by /usr/lib/libstdc++.so.6)
19:58 < marcel> daniel: dein binary wurde wohl mit einer anderen gcc version
compiliert als deine libstdc++
19:59 < daniel> Also eigentlich bezieht sich das ‘required’ auf some_binary und
nicht auf libstdc++.so.6 ?
20:09 < daniel> Argh. Vergiss meine Frage, ich hab das Problem gefunden
20:11 < marcel> was awr es denn?
20:12 < daniel> some_binary brachte seine eigene lib_gcc.so.1 mit, und der
fehlte das Symbol