[389-users] csngen_adjust_time: adjustment limit exceeded

[Juan Asensio Sánchez]

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 at 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 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/20100820/64a565c0/attachment.html>