On 10/12/2011 02:08 PM, Reinhard Nappert wrote:
Rich,
I was thinking about
the "Replica has a different generation ID than the local
data." error, because I have seen this before. If possible,
I want to avoid that I have to go though each box and
re-initialize.
So, you suggest I
take let's say D (or A) and re-initialize B with D's data.
Then, I would have to re-initialize F from B, right?
Right.
Let's go a bit
further: If I had an agreement from A to F (and vice versa),
I would not even have to re-initialize F from B. Is this
correct?
Assuming the AtoF agreement is not complaining about "unable to find
CSN" and "data reload", then yes.
-Reinhard
On 10/11/2011 02:41 PM, Reinhard Nappert wrote:
How do I do this
manually on server A?
The other question
is, what kind of impact does it have when I re-iitialize
server B? To be more precise, my replication environment
is more complex than just server A and server B. In fact,
I have a setup like the following:
srv C <--> srv
A <--> srv B <--> srv D <--> srv C
/\ /\
| |
\/ \/
srv
E srv F
I don't want to end
up to re-initialize all boxes in my environment.
Assuming C and D are up to date and don't have any problems,
reinitializing B should affect only B and F.
Thanks,
-Reinhard
On 10/11/2011 01:22 PM, Reinhard Nappert wrote:
Hi,
I encountered the
following logs in the errors:
[06/Oct/2011:10:11:57 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=srvAtosrvB" (srvB:389): CSN 4e8d804a0000000c0000 not found, we aren't as up to date, or we purged
[06/Oct/2011:10:11:57 +0000] NSMMReplicationPlugin - agmt="cn=srvAtosrvB" (srvB:389): Data required to update replica has been purged. The replica must be reinitialized.
[06/Oct/2011:10:11:57 +0000] NSMMReplicationPlugin - agmt="cn=srvAtosrvB" (srvB:389): Incremental update failed and requires administrator action Does anyone have an idea, what could have caused this and more importantly, how to fix this? Thanks -Reinhard
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
On server A, read a changelog to manually run the changes on
server B.
May be tune up nsds5ReplicaPurgeDelay if such errors somehow
appears regularly.
Otherwise, like the errors log says, the change was
purged/removed, and replica need a re-init.
M.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
|
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
