Einrichten der NoSQL Funktionalität auf einer bestehenden Instanz
Mit der Version 12.10.xC2 hat IBM die Möglichkeit geschaffen, mit MongoDB-Clients auf die Informix Datenbank zuzugreifen und die Informix NoSQL Funktionalität zu nutzen.
Leider bekommt man diese fantastische Feature nur, wenn man eine neue Instanz aufbaut. Alle Beschreibungen der IBM besagen, das man den Installer der xC2 Version eine neue Instanz anlegen lassen muss. Dann kann die Funktionalität, basierend auf dem Kopieren und Anpassen von 2 Dateien auf auf weitere neue Instanzen übernommen werden, die manuell erstellt werden.
How do I install and configure NoSQL?
How do I configure an additional instance of IDS with NoSQL support?
Leider gibt es keine Beschreibung, wie man auf einer bestehenden Instanz die Funktionalität einschalten kann.
Technisch ist die NoSQL Funktionalität als UDR gelöst. Die notwendigen Funktionen, Casts usw. sind im bootstrap-Script der Version 12.10.xC2 enthalten. Der Listener für MongoDB-Clients steckt nicht im oninit, sondern ist als extra Java-Service implementiert.
Gestartet wird dieser Listener vom Informix internen Scheduler, der das Vorhandensein der Datei $INFORMIXDIR/etc/jsonListener.properties prüft und den Listener startet, wenn die Datei existiert.
Der Name der Datei jsonListener.properties wird während der Initialisierung der Instanz im Start-Task hinterlegt. Dadurch können auch mehrerer Instanzen innerhalb einer Installation die Json-Funktionalität nutzen.
Dieser Artikel ist als Anleitung gedacht, wie man in einer bestehenden Instanz die NoSQL Funktionalität einschaltet.
Dann erfolgt ein Update auf die entsprechende 12.10.xC2 Version. Dabei gibt man den Pfad seiner vorherigen Installation an und achtet darauf, das die Option "Json Client Support" an gehakt ist.
Nachdem die Installation durchgelaufen ist, braucht man noch einige Dateien. Ein Paket 
Informix-NoSQL-Update-Dateien der notwendigen Dateien haben wir für Sie hier zusammengestellt.
Alle folgenden Aktionen müssen als Benutzer informix ausgeführt werden!
Als erstes muss man die UDR Funktionen erstellen. Dazu startet man eine Shell mit einer Informix-Umgebung. Geht in das Verzeichnis $INFORMIXDIR/etc und führt folgendes Kommando aus
dbaccess sysadmin boot1210.sql
Das Script sollte fehlerfrei durchlaufen.
Jetzt benötigt man die Datei $INFORMIXDIR/etc/jsonListener.properties Diese ist im Paket enthalten, muss aber entsprechend editiert werden.
Hier ein Beispiel:
Windows:
listener.port=27017
url=jdbc:informix-sqli://<hostname/IP des DB-Servers>:<Port des Informix SQLI
Listeners>/sysmaster:INFORMIXSERVER=<INFORMIXSERVER-Name>
Unix/Linux:
listener.port=27017
url=jdbc:informix-sqli:/<hostname/IP des DB-Servers>:<Port des Informix SQLI
Listeners>/sysmaster:INFORMIXSERVER=<INFORMIXSERVER-Name>;USER=<Username
Default: ifxjson>;PASSWORD=<Passwort>
Hier ein weiteres Beispiel:
listener.port=27017
url=jdbc:informix-sqli:/dbserver.cursor.de:9088/sysmaster:INFORMIXSERVER=ol_informix1210;USER=ifxjson;PASSWORD=extremgeheim
Die komplette Dokumentation der jsonListener.properties Datei ist hier zu finden.
Nachdem diese Datei korrekt erstellt wurde, muss noch der Scheduler-Eintrag erzeugt werden, der den Service startet und auf den Unix-Plattformen ein spezieller User für den Listener erstellt werden.
Dazu muss der Benutzer daemon in den surrogates cache eingetragen werden. Es muss eine Datei "allowed.surrogates" in /etc/informix angelegt werden. Die Rechte müssen sein:
-rw-r--r-- 1 root root 14 Oct 31 13:35 allowed.surrogates
In dieser Datei muss mindestens stehen:
USERS: daemon
Sie können prüfen, ob diese Datei korrekt angelegt ist, indem Sie:
onmode -cache surrogates
aufrufen. Dieser Befehl muss fehlerfrei durchlaufen. Gibt es Fehler, so steht im online.log (onstat -m) die Ursache.
Jetzt muss je nach Plattform noch die im Pack enthaltenen Datei sch_init_<plattform>.sql ausgeführt werden.
Besonderheit bei Unix/Linux ist, das hier der User ifxjson angelegt wird. Das dazughörige Passwort 'extremgeheim' muss in der Datei natürlich durch ein sinnvolles Passwort ersetzt werden, das mit dem in der jsonListener.properties übereinstimmen muss.
Sollen mehrere Instanzen einer Installation den Listener starten, so ist in dieser Datei, in der Zeile:
LET json_listener = 'jsonListener.properties';
bei jeder Instanz ein anderer Dateiname anzugeben. Dementsprechend müssen diese Dateien dann auch angelegt und mit den richtigen Werten versehen werden.
dbaccess sysadmin sch_init_<Plattform>.sql
Jetzt kann man den Server neu starten. Sollte der Listener nicht starten, sollten sie nochmal überprüfen, ob der Task "json listener" in der sysadmin.ph_task auf enabled ='t' steht.
Ist der Listener gestartet, kann man mit MongoDB-Clients auf die NoSQL-Funktionalität der Informix Datenbank zugreifen. Mein Test-Client war Robomongo.
Troubleshooting:
Meine Linux-Installation hat mit diese Anleitung problemlos funktioniert. Windows war da etwas Wiederspenstiger. Hier darf der Firewall den java-Prozess nicht blocken. Also $INFORMIXDIR/etc/extend/krakatoa/jre/bin/java.exe als Programm freischalten.
Normalerweise schreibt der Listener im $INFORMIXDIR eine Datei jsonListener.log Dort stehen hilfreiche Informationen bzw. Java-Stacktraces drin, denen man recht gut das Problem entnehmen kann, weshalb der Prozess nicht startet.
Man kann aber den Listener per Hand starten. Dazu verwendet man folgenden Aufruf als informix vom $INFORMIXDIR aus:
extendkrakatoajreinjava.exe -Dcom.ibm.tools.attach.enable=no -jar %INFORMIXDIR%injsonListener.jar -config %INFORMIXDIR%etcjsonListener.properties -logfile %INFORMIXDIR%jsonListener.log -start
oder unter Linux
extend/krakatoa/jre/bin/java -Dcom.ibm.tools.attach.enable=no -jar $INFORMIXDIR/bin/jsonListener.jar -config $INFORMIXDIR/etc/jsonListener.properties -logfile $INFORMIXDIR/jsonListener.log -start
Dann bekommt man auch das entsprechende Logfile geschrieben. Startet der Listener so korrekt, kann man auch damit die NoSQL Funktionalität testen.
Für erweiterte Ausgaben kann man beim Start noch die Trace-Funktion einschalten. Dazu muss man dem Aufruf noch die Option
-loglevel trace
hinzufügen. Die möglichen Level sind error, warn, info, debug und trace.
Dipl. Wirtschaftsinformatiker Andreas Seifert
(Geschäftsbereich IBM Distribution)
CURSOR Software AG
Friedrich-List-Straße 31
D-35398 Gießen
