Reihe von Problemen im Domino Cluster

[papadave]

Hi,

ich setzte vor einigen Tagen meinen ersten (Failover) Domino Cluster auf um
eben die Ausfallssicherheit zu erhöhen und mit Linux Bordmitteln ein Online-Backup
zu realiseren.
Da es mein erster Cluster ist, sind natürlich fehler meinerseits nicht ausgeschlossen
Ich verwendete die Onlinehilfe und das Buch "Lotus Notes/Domino Administration" als Anleitung.

Meine Dominoumgebung:

Server1: "Domino/leonhardlang"
Ist das "Urgerät". Läuft nun seit nem halben Jahr ohne Probleme.
Domino 6.5.1 mit DE Language Pack unter RedHat 9 auf einer PIII DualProzessorMaschine

Server2: "domino2/leonhardlang"
Soll in Zukunft das Failovergerät sein
Domino 6.5.2 noch ohne Language Pack unter Fedora Core 2 Final auf einer P4 HT Maschine

Bisher getan:

Server2:
Fedorer installiert
Domino 6.5.2 en installiert.
Als 2. Gerät in einer Dominodomain registriert
Notes.ini: Server_Availability_Threshold=100
Verbindungsdok. auf Server1 erstellt
Server 2 Managerzugriff auf alle nsf gewährt.
Server1 auf Server2 die Rechte zum erstellen von Repliken gewährt.

Server 1:
Server2 und Server1 in einen neuen Cluster gesteckt
Das Replizieren dem AdminProzess überlassen
Verbindungsdoc auf server 2 erstellt

Generell:
--> Mich gewundert, dass er nur am Server2 bereits vorhandene .nsf clustert.
Sodann einfach offlinekopien alles nsf-Files von Server1 auf Server2 geschoben
Server1 abgeschalten --> "Cluster" funktioniert soweit  Jedoch mussten die
Clients (6.5 de) neu gestartet werden ...
Logfiles geguckt, Probleme mit den Indexes erkannt. Mal alle ft-Files auf Server2 gelöscht.
Danach sah alles sehr gut aus, doch nun über Nacht sind die Logfiles voll von:

Fehler in den Logs:
Error full text indexing xxx.nsf: Full text error from Topic
Full Text message: UBM error. File name = xxx.ft/ftgi/gtr.PLF, UBM error code = 5006, errcode = 3085
Error updating view '($All)' in mail/dwinkler.nsf: B-tree structure is invalid
NIF: DETECTED STORAGE CORRUPTION ERROR 'B-tree structure is invalid'
NIF: in /local/notesdata/mail/dwinkler.nsf collection "($All)", ID=97602 length 21504
Failing over from domino/leonhardlang for replica id C1256E5B:0050D4DA, directing open to domino/leonhardlang
err_invalid_btree ERROR: The buffer pool is extremely full; delay the thread. [xxx.nsf]
err_invalid_btree ERROR: B-tree structure is invalid [xxx.nsf]
NIF: DETECTED STORAGE CORRUPTION ERROR 'B-tree structure is invalid'
...

ein Show Cluster auf Server2:
> sh cl
 Cluster information:
 Cluster name: BackupCluster, Server name: domino2/leonhardlang
 Server cluster probe timeout: 1 minute(s)
 Server cluster probe count: 1738
 Server cluster default port: *
 Server availability threshold: 100
 Server availability index: 69 (state: BUSY)
 Server availability default minimum transaction time: 3000
 Cluster members (2):
        Server: domino/leonhardlang, availability index: 69
        server: domino2/leonhardlang, availability: BUSY


Das sieht irgendwie alles nicht so toll aus   
Ich fand das oben angegeben Buch irgendwie nicht so toll. Zu mindest ging für mich nicht hervor, dass ich erst selbst Repliken aller DBs selbst anlegen muss...

Frage:
Muss ich auf Server2 nun "händisch" Repliken aller DBs (auch mail.box) anlegen?
Wieso hat er mir ständig die Indexes zusammen?
Müssen für ein Cluster beide die selbe Dominoversion laufen haben?

Wah, ich bin verwirrt 

Tia, David

[Driri]

Hi,

meines Wissens erzeugt der Domino-Cluster nicht automatisch Repliken von Datenbanken auf dem anderen Clustermember. Mein Kollege hat zu diesem Zweck extra einen Agent geschrieben, der für DBs, die nicht auf dem zweiten Cluster existieren eine Administrationsanforderung erzeugt.

Ist aber auch nicht das wahre, nach der Migration auf 6.5.2 scheint sich der Agent ab und an mit dem Adminp ins Gehege zu kommen, wir hatten auf jeden Fall schon nen paar deftige Crashes.


Die Fehlermeldung sieht mir so aus, als wenn er die FTI nicht erzeugen kann, weil die Datenbanken einen Schlag haben.
Evtl. wäre es doch besser, die Repliken über Domino und nicht per Filecopy zu erzeugen.


Zu den Versionen : Nein, es müssen nicht die selben Versionen laufen, ich weiß z.B. von Konstellationen, wo ein R5 mit nem 6er geclustert wurde. Trotzdem würde ich immer die gleiche Version benutzen, einfach um schon evtl. dadurch entstehende Probleme aus dem Weg zu räumen.

[papadave]

ojeoje, also muss ich auf jeden Fall, wenn ich ne neue Datenbank anlege, auf das "Replik auf anderem Server erzeugen" (oder so) achten...?

Hab nun die Betreffenden DBs gelösch und per Replik auf Server2 gezogen.
Dennoch gleiches Problem mit dem Index.
Auch nach löschen und dann neuanlegen des Indexes gleiches Problem.
Jedoch nur bei diesen 5 (von 40) Datenbanken.

2004/10/15 11:36:59 AM  Full Text message: UBM error. File name = /local/notesdata/mail/slang.ft/ftgi/gtr.PLF, UBM error code = 5006, errcode = 3085
2004/10/15 11:36:59 AM  Error full text indexing document NT0000473E /local/notesdata/mail/slang.ft (rc=3857) Full text error; see log for more information


Weiters hab ich gelesen, dass Domino scheinbar noch nicht mit Linux Kernel 2.6.x kann???
Sollt ich die Kompatibilitäts-library compat-libstdc++ nachinstallieren?

Danke, David

[papadave]

bin nun nen Schritt weiter. Die Probleme scheinen vom Fedora Core 2 herzurüheren.

Es wird nur 1MB für den Pool zu reserviert

show stat database.database.*
> show stat database.database.*
  Database.Database.BufferPool.Maximum.Megabytes = 1
  Database.Database.BufferPool.MM.Reads = 0
  Database.Database.BufferPool.MM.Writes = 0
  Database.Database.BufferPool.Peak.Megabytes = 1
  Database.Database.B

Eintrag in die Notes.ini: NSF_Buffer_Pool_Size_MB=400

Danach die hinkenden Indexes löschen, neu aufbauen und ...
es scheint nun ohne Probleme durchzulaufen!! 

Ob die anderen Probleme auch daher rühren,
und wie sich das ganze im Dauerbetrieb verhält,
wird sich noch zeigen.

Also vielleicht doch RHEL 3.0 verwenden

David