[389-users] csngen_adjust_time: adjustment limit exceeded
Juan Asensio Sánchez
okelet at gmail.com
Mon Aug 16 17:40:49 UTC 2010
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>
More information about the 389-users
mailing list