OK Rich, thank you very much. I will try this tomorrow, it's evening here in Spain. For "replicas" I mean replicated suffixes/databases on each server in my previous message. Regards. 2010/8/16 Rich Megginson <rmeggins at redhat.com> > Juan Asensio S?nchez wrote: > > Hi > > > > Thanks Rich for your answer. Just some questions: > > > > > > The bug that caused this to happen was fixed, but unfortunately > cannot > > fix the bad nsState that already exists. The problem is that the CSN > > generator attribute (nsState) in the cn=replica entry for the suffx > is > > not cleaned up properly when you re-init replication. In general, > you > > can't do this, because you could generate CSNs that you have > generated > > before. > > > > I think the solution here is to first unconfigure replication, > > > > > > Must I unconfigure all the replicas, or just for the database giving > > problems? > If by "replicas" you mean "directory servers", then yes, all directory > servers. If you mean "one of several replicated suffixes/databases on a > server", then no. The nsState entry is in each cn=replica entry for > each suffix, so you only have to fix the one that is causing problems. > > > > > > then > > shutdown the servers, then dump the database(s) to LDIF, > > > > > > I suppose I must export only the data (with db2lif), > correct > > not the replica information (with db2ldif.pl <http://db2ldif.pl> -r) > correct > > because the server has shut down and this last script requires the > > server to be running. > No, because you do not want to keep the old replication state > information (generated by -r) because it is bogus. > > > > > > then remove the > > nsState attribute. > > > > > > When exporting the data, has any entry that attribute? Or from where > > remove that attribute? > In dse.ldif, in the cn=replica entry under each suffix under cn=mapping > tree,cn=config. > > > > > > You will have to do this on every server. Then, > > start up, reconfigure replication, reload the data, > > > > > > What do you want to say with "reload the data" and after "re-init the > > other replicas"? Import the exported data in one server, and then > > re-init the rest of the servers? > Yes. import the exported data on your "primary" master, then use that > one to re-init the other servers. > > > > and re-init all of > > the other replicas. Make sure all of your servers are in time sync > > before you begin. > > > > > > Yes of course. > > > > > > I know this is a pain but I don't know any other way to get rid of > the > > bad nsState. > > > > > > Regards and thanks in advance. > > > > > > > > > Regards and thanks in advance (again ;)). > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users at lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100816/b0e0b506/attachment.html
