Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

Client als Dienst installieren

<< < (2/6) > >>

Tomz:
sehr witzig Leute...  O0

Erklärung: wir hatten neulich arge Probleme mit einer wirklich großen DB, wir sind mit der DB auf 12 Servern in einen Consistence Check gekommen (aufgrund des "unable to extend ID table"-Problems) aus dem die DB nie wieder aufwachte (Szenario bei IBM bekannt). Die DB war also nicht wiederbelebbar. Problem dabei, dass die Sicherung seit dem ersten Ausfall die defekten DBs auch nicht mehr sichern konnte. Wir haben uns also selber eine Sicherung über eine lokale Repklik auf den Servern gezogen. Wir haben dazu auf den Servern jeweils einen Client gestartet und lokal aushalb des Data repliziert. Hierbei wäre es für uns nützlich gewesen, daß wir einen Client gehabt hätten, der offen geblieben wäre, wenn wir uns auf dem Server remote abgemeldet hätten.

Die Idee war einfach einen Client zu haben der immer offen bleibt. Da wir die Replikation mit einem technischem User gemacht haben und unser Team aus vier Leuten alle Zugriff auf die ID hatten wäre die Anmeldung gar nicht das Problem gewesen. Wir hätten den Client einfach gesperrt, da jeder von uns das PW kannte.

Die DB ist wirklich ein schwer erziehbares Kind aufgrund seiner Größe und der Anzahl der Dokumente. Wir hoffen nicht, daß wir wieder vor dem Problem stehen, wollen aber für so einen Fall besser gerüstet sein.

Klar ist es ein wenig abwegig aber es geht nicht darum den Client beim Start zu öffnen, sondern beim Abmelden am Server offen zu lassen.

m3:
OK, mit der Hintergrundinfo wird die Frage etwas "sinnvoller". ;)

1) IMHO ist Replik != Backup
2) Wie wärs mit einem PC, der immer läuft und auf den Ihr Euch via VNC verbindet. Den könnte man auch so konfigurieren, dass er
a) nach einem Reboot automatisch einen User anmeldet und
b) den Notes-Client automatisch startet.
Zusammen mit einem eingerichteten Single Sign On hättest Du dann eine "gangbare" "Backup" Lösung.

Oder muss es auf dem Server sein? Wenn ja, wie wärs dort mit Server stoppen (etwa um 2 in der Früh), DB via OS kopieren, Server wieder starten? Oder wollt/müsst ihr dauernd sichern?

mcilly:
Jetzt wirds lichter, klar was ihr vorhabt. Aber wie Martin schon sagte, der Ansatz ist ok. Mich würd noch interessieren wie groß die DB ist.

Hive:
Ich denk es ist sinnvoller am Fehler der DB zu arbeiten. der "Extend ID Table" Fehler kann unteranderem vorkommen wenn im Design mehr als 3000 Felder definiert sind .. das sollte mit der DB Option "Mehr Felder in der DB zulassen"  (letzer Reiter der DB Eigenschaften) dann behebbar sein (falls die nicht schon aktiviert ist).

Desweiteren schafft es ein FixUp und Compact vom 7er Server in der Regel das Problem zu lösen also hilft vielleicht ein update auf 7.

Ich hab die gleichen Fehler auch bereits hintermir da bei uns ein Update verschiedener Applikationen wegen nicht möglich war, half am Ender nur eine Archivierung von Dokumenten, so dass die Anzahl der Dokumente und 200.000 blieb.

mfg KAI

Tomz:
Das Szenario sieht folgendermaßen aus:
Die DB ist auf allen Spoke-Servern ausgefallen. Alle Hub-Server liefen (haben mehr RAM) und beinhalten alle Dokumente. Die Spoke-Server haben über selektive Replikation nur einen Teil des Komplett-Bestandes.

Wenn wir lokal replizierten nachdem die Spokes alle Dokumente an den Hub geschickt haben war also ...

1) ... Replik = Backup, da die Replik alle Dokumente sich dann vom Hub wieder holen konnte
2) Das Übertragen der Repliken auf die Spoke-Server hätte zu lange gedauert, daher haben wir die Repliken lokal auf den jeweiligen Servern erstellt und außerdem, dürfen die Repliken nicht alle Dokumente beinhalten (sind sogar auf den Spokes nicht alle gleich)

Wir brauchen also keinen Rechner der den Client automatisch startet, nur einen Client der offen bleibt, wenn wir uns von den Servern via Remote Dektop oder VNC abmelden.

Server in der Nacht stoppen und kopieren war schlecht, zumal die DB immer irgendwann zwischen 18 Uhr und 03 Uhr in den Consitence Check gegangen ist.

War vielleicht nicht richtig rauszulesen aber wir haben das Problem mittlerweise im Griff (Repliziertabellen verkleinert, indem nicht mehr mit dem Cluster repliziert wird, sondern nurnoch mit einem Hub-Server; Deletion-Stubs in der Anzahl verringert und und und). Wir wollen uns nur für die Zukunft nochmal wappnen.


"Mehr Felder in der DB zulassen" ist bereits aktiviert. Der extended ID-table Fehler ist uns auch bekannt und wurde sogar auf einem Domino 7 Server nachgestellt, ist also anders als IBM es sagt immernoch vorhanden. FixUp bringt nichts, wenn die Replik nicht mehr aus dem Consistence Check aufwacht.
Die DB ist im schlimmsten Fall derzeit 16 GB groß mit c. 923.000 Dokumenten. Ein tägliche Archivierung läuft, wir waren schon mal bei 1,4 Mio Dokumenten. Das ist übrigens nicht unsere größe DB  :-\

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete