Autor Thema: Clusterreplikation einschränken  (Gelesen 2256 mal)

Offline Maverick

  • Aktives Mitglied
  • ***
  • Beiträge: 150
  • Geschlecht: Männlich
  • New day - same shit
Clusterreplikation einschränken
« am: 21.06.05 - 11:18:34 »
Hallo,

1. ich habe in einem Forum darüber gelesen, die log.nsf aus Performancegründen aus der Clusterreplikation herauszunehmen.

2. Ich dachte bislang, dass die Clusterreplikation nicht auf Datenbankebene zu parametrisieren ist, "Wenn Repliken auf beiden Servern vorhanden sind, werden sie eben vom Clusterreplikator repliziert"

Ist das so?

1. ?
2. ? Wenn Nein, wo kann ich Datenbanken ausnehmen?

Thx

Paul

eben war's noch da

Paul    (Server: ja, Clients: zu viele)

Driri

  • Gast
Re: Clusterreplikation einschränken
« Antwort #1 am: 21.06.05 - 11:30:41 »
Generell werden alle verfügbaren Datenbanken im Cluster repliziert.

Man kann allerdings bestimmte Datenbanken davon ausnehmen. Dazu im Admin-Client die Datenbank(en) wählen und über "Cluster..." die Cluster-Replikation aktivieren/deaktivieren.

Offline diali

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.023
  • Geschlecht: Männlich
Re: Clusterreplikation einschränken
« Antwort #2 am: 21.06.05 - 11:31:04 »
die Clusterreplikation gilt erstmal für alle DDs, die in dem Cluster liegen. In der cldbdir.nsf im Root des Servers kannst Du dann einzelne DBs deaktivieren.

Gruß
Dirk
Gruß
Dirk

Offline werxs

  • Junior Mitglied
  • **
  • Beiträge: 62
Re: Clusterreplikation einschränken
« Antwort #3 am: 21.06.05 - 11:31:49 »
Hi,
für mich stellt sich als erstes die Frage, welchen Vorteil Du Dir davon versprichst, die log.nsf überhaupt als Replik auf die verschiedenen Server zu legen ?   ???

Grüße
Helmut

Offline Maverick

  • Aktives Mitglied
  • ***
  • Beiträge: 150
  • Geschlecht: Männlich
  • New day - same shit
Re: Clusterreplikation einschränken
« Antwort #4 am: 21.06.05 - 11:37:05 »
@werxs: Oh Mann, das hätte nicht passieren dürfen.  :-[

Natürlich habe ich meine logs nicht als Repliken. Das halte ich auch für ausgesprochenen Quatsch.

Es ging vielmehr um die Frage, wie kann ich Repliken aus der Clusterreplikation ausnehmen, sie aber bei der Standardreplikation berücksichtigt zu wissen.

shame on me :-)

Paul
eben war's noch da

Paul    (Server: ja, Clients: zu viele)

Offline Maverick

  • Aktives Mitglied
  • ***
  • Beiträge: 150
  • Geschlecht: Männlich
  • New day - same shit
Re: Clusterreplikation einschränken
« Antwort #5 am: 21.06.05 - 11:40:45 »
@diali:

die Clusterreplikation gilt erstmal für alle DDs, die in dem Cluster liegen. In der cldbdir.nsf im Root des Servers kannst Du dann einzelne DBs deaktivieren.

Das war genau die Info. Danke.

Notes kann manchmal so einfach sein...

Grüße
Paul
eben war's noch da

Paul    (Server: ja, Clients: zu viele)

Offline aclchecker

  • Frischling
  • *
  • Beiträge: 26
  • Geschlecht: Männlich
Re: Clusterreplikation einschränken
« Antwort #6 am: 21.09.05 - 15:22:42 »
Hallo zusammen,

meine Frage passt ganz gut zu dem Fred hier, deshalb mach ich keinen neuen auf:

Hier läuft ein Domino-Cluster mit 2 Servern (Einer 5.0.11 und der andere 5.0.13, wobei die Version wohl keine Rolle spielt) und das funkt bis auf ein paar kleinere Probleme ganz gut.

Eines der Probleme sind die Ungelesen-Markierungen, die bei meinen Usern im Falle eines Failovers ständig mein Telefon klingeln lassen, denn dann sind jede Menge vorher gelesene Mails wieder ungelesen. Hab mir dazu mal das Forum auf der IBM-Website vorgenommen, aber da habe ich auch nix greifbares gefunden.
Kann das vielleicht an der neben der Cluster-internen Replikation liegen, da gibt es noch eine periodische, alle 45min. in die eine und alle 60min. in die andere Richtung. Wenn ich das richtig verstanden habe, werden damit alle "normalen" DB's ausser den Mail-DB's repliziert.

Ein anderes Problem sind Mailagenten bei 2 Usern, die vor Eintreffen neuer Mails jeweils Kopien der neuen Mails an andere User senden. Die Agenten habe ich selbst geschrieben und die funktionieren auch prächtig. Ausser bei einem Failover. Auf dem anderen Mailserver (Also nicht der Administrations-Server der Notes-Domain) funktionieren beide nicht. .....not allowed in this session kommt dann. Angeblich sollen Mailagenten, die bei neuer Mail getriggert werden, sich nicht auf einen bestimmten Server beschränken. So stehts jedenfalls in Julie Kovachevichs Ausführungen, aber irgendwie tun die beiden das doch. In den ACL der beiden Mail-DB's stehen beide Server drin, daran kanns also nicht liegen. Einen ausführenden Server kann man bei dieser Art Agent nicht einstellen, das geht nur bei scheduled Agents. Hmpf.

Uuund noch eines: Gibts eigentlich eine Liste von DB's, die auf keinen Fall via Cluster-Replizierung repliziert werden sollten? Log.nsf sollte man nicht, das hab ich oben schon gelesen. Noch welche, bei denen das besser abgestellt werden sollte, admin4.nsf oder so? Hab mir die cldbdir.nsf mal angeschaut, da stehen jede Menge nsf und auch ntf drin. Bei einigen nsf gibt es unterschiedliche Replica-ID's, bei denen funktioniert das Replizieren ohnehin nicht, oder?
Das Redbook.pdf zum Clustern und noch eines, was hier im Forum angeboten wurde, hab ich mir reingezogen. Aber da steht nix dazu drin.

Mein erster Beitrag hier und schon gleich ein Haufen Kram. ;-)
HTH
Uwe

Driri

  • Gast
Re: Clusterreplikation einschränken
« Antwort #7 am: 21.09.05 - 15:33:29 »
Hallo und willkommen im Forum.

zu 1) Ungelesenen Markierungen werden nicht mitrepliziert, sie gelten je Replik.

zu 2) Sind die Einstellungen unter Sicherheit in den beiden Serverdokumenten identisch ?

zu 3) Ich wüßte jetzt keine Liste, aber generell sollten keine Datenbank repliziert werden, die nur für genau einen Server gelten, also eben z.B. die log.nsf, domlog.nsf etc.

Offline aclchecker

  • Frischling
  • *
  • Beiträge: 26
  • Geschlecht: Männlich
Re: Clusterreplikation einschränken
« Antwort #8 am: 21.09.05 - 15:42:03 »
Grazie Ingo.

Zu 1): Das ist aber mistig. ;-)
Meine User haben zum grössten Teil 2 Jahre Mails drin und dann jedesmal die Ungelesen-Markierungen bei einem Failover auf den neuesten Stand zu bringen, ist mehr als lästig. Gibts da einen Ausblick, ob das bei 6.x oder 7.x in den Griff zu kriegen ist?

zu 2): Ja, sind sie. Absolut und etlich geprüft.

zu 3): Mir fehlt da ehrlich gesagt ein bisschen der Überblick, was genau dazugehört. Vielleicht kann mir jemand ein paar Tipps geben.
HTH
Uwe

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz