Hi

Well, in short, the procedure described by Rich did work fine. The only thing no note, is that the replicas on all servers which are multimaster of the replica giving errors must be disabled totally (replication agreements and the own replica), in the same time; so the replication will not be working during the work.

Also, when disabling the replica and stop the server, the nsState could not be removed because that attribute is in the cn=replica object, and the replica has been disabled, so that entry does not exists anymore.

Agains, thanks Rich for your help.


El 16 de agosto de 2010 19:40, Juan Asensio Sánchez <okelet@gmail.com> escribió:
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@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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users