node-0

Möchte man das RubyGem mysql unter Ubuntu oder Kubuntu installieren, ist es zunächst notwendig, die Dev-Sourcen des MySQL-Clients zu installieren, sonst kommt es zu folgender Fehlermeldung:

Wer die Ruby-Bindings für sqlite3 namens sqlite3-ruby unter Ubuntu oder Kubuntu mittels rubygems installieren möchte, stößt auf Probleme:

$ sudo gem install sqlite3-ruby
Building native extensions.  This could take a while...
ERROR:  Error installing sqlite3-ruby:
        ERROR: Failed to build gem native extension.
 
/usr/bin/ruby1.8 extconf.rb install sqlite3-ruby
checking for sqlite3.h... no
 
make
make: *** No rule to make target 'ruby.h', 
      needed by `sqlite3_api_wrap.o'.  Stop.

Die Lösung für dieses Problem: Man muss zunächst das Ubuntu-Package libsqlite3-dev installieren:

$ sudo apt-get install libsqlite3-dev
$ sudo gem install sqlite3-ruby

Ein kurzer Test in irb:

Erick Dennis und Michael Otto von der epublica GmbH referierten über die Möglichkeiten, eine ständig wachsende Webapplikation – nämlich OpenPC/Xing – durch verschiedene Maßnahmen auch unter Performance-Gesichtspunkten zu skalieren.

Zunächst wurden die beiden Alternativen scale up (höherwertige Hardware, Mehrprozessorsysteme, SPeicherlösungen) und scale out (Off-the-shelf-Hardware, Problemananalyse, Anpassung der Applikation) definiert und diskutiert. Offensichtlich ist scale out für viele Situationen der richtige Weg, da man immer einen weiteren Standard-Server ins System bringen kann, der dann im bestenfalls zu einem linearen Performance-Zuwachs führt.

Hans-Jürgen Schönig spricht über die verschiedenen Möglichkeiten, mit Postgres eine hochverfügbare Lösung zu bauen und stellt dabei zunächst die »klassischen« Alternativen hot standby/failover, synchrone Replikation und asynchrone Replikation vor. Dabei weißt er auch jeweils auf die Vor- und Nachteile hin:

• failover schützt nicht vor PEBKAC: Wenn der Admin einen Table dropt, dann ist der weg, und zwar auch auf dem Failover-Rechner. Von Vorteil ist allerdings die einfache Implementierung, da Lösungen sowohl auf Hardware- (SAN) als auch auf Softwarebasis bestehen.
• Synchrone Replikation kann ebenfalls nicht vor PEBKAC schützen; hinzu kommt, dass der Kommunikationsaufwand hierbei noch einmal deutlich höher wird.

Der deutschsprachige Clone der amerikanischen Blog-Recommender-Community digg.com names yigg.de hat zur Zeit leider einen kleinen Aussetzer. Zunächst sah man noch die MySQL-Fehlermeldung im Browser, inzwischen gibt es da eine (extrem einfach gehaltene!) statische Seite mit dem Hinweis, man habe zur Zeit technische Probleme.

Natürlich passieren Fehler. Aber ein solches Problem bei einem semi-professionellen Service? Naja …

Bereits im April gab es Probleme mit einem MySQL-Upgrade, nun gibt es einen weiteren Fall, in dem die Maintainer für MySQL bei Gentoo offensichtlich etwas zu schnell geschossen haben.

Historie oder: Was im April geschah

Nach der Aktualisierung von MySQL 4.1.14 auf die Version 4.1.14-r1 (und einer nicht angekündigten und schlecht kommunizierten Änderung des Standard-Encodings von latin1 auf utf8) funktionierten viele PHP-basierte Anwendungen entweder nicht mehr oder aber stellten Umlaute und andere Sonderzeichen falsch dar.

Sonntags hat man ja nichts zu tun, wir haben ja alle eine 40-Stunden-Woche und “Freitag ab eins macht jeder seins” :-D. Was macht man also? Während man die während der Woche liegengebliebene Arbeit nachholt und sich auf die nächste Arbeitswoche vorbereitet, kann man ja mal eben schnell seinen Server auf den neuesten Stand bringen.

Ich betreibe meine Rechner vorzugsweise unter Gentoo, nur zum Daddeln habe ich auf dem Laptop auch ein Windows. Das Schöne an Gentoo ist eigentlich, dass man sich darauf verlassen kann, dass alles so funktioniert, wie es soll. Es ist zwar manchmal ein bisschen Nachhilfe notwendig, aber das macht die Sache ja eher noch interessanter.