Gary Windham wrote: > We have a downtime scheduled for our production FDS instance (used for > our campus authentication service) this Friday, in order to > reestablish MMR. After reestablishing MMR we will be monitoring with > the script, so we should be able to provide some data shortly. Excellent. Thanks! > > Thanks, > --Gary > > -- > Gary Windham > Senior Enterprise Systems Architect > The University of Arizona, UITS > +1 520 626 5981 > > On Jun 23, 2008, at 8:11 AM, Rich Megginson wrote: > >> debu wrote: >>> >>> Hi Chris, >>> >>> Thanks for your round about way. >>> As you suggested we have removed everything, along with that we have >>> reinstalled the latest version in two machines, and kept one machine >>> as is (in total we have 3 machines). >>> >>> Now, we configured these two servers in multi-master mode and >>> initialized one of them from the old machine. Then all the data got >>> pushed into the new servers. These two new machines are replicating >>> properly. >>> >>> but the replication agreement between the old server and new server >>> is breaking. But we used the console interface to push the delta of >>> updates. But the process is very slow, may be because we haven't >>> done db2ldif to dump the data. >>> >>> We are planning to push delta of updates from old server to 2 new >>> servers (using the console interface) and remove the old server from >>> the system. >>> >>> Then these two servers will become primary point of live interaction >>> for read and write. >>> Since, we can't afford for downtime, we have done like this. >>> >>> Till now the replication is happening fine. >>> >>> hope this continues. >>> >>> Thank you very much for your help. >>> >> We are working on a fix for the time skew issue. However, we need >> your help. The bug >> https://bugzilla.redhat.com/show_bug.cgi?id=233642 has attached to it >> a script which will provide us with some much needed data. You >> basically run this on your masters like this: >> readNsState.py /etc/dirsrv/slapd-yourinstance/dse.ldif >> The data that it prints out is very useful for help with debugging >> this problem. You can either attach the output to the bug, or just >> email the output to me. >> >> Anyone else interested in helping? Anyone have MMR running? Please >> run the script and either attach the output to the bug or just send >> it to me. >>> >>> >>> Regards, >>> -Debu,vivek >>> >>> >>> On Fri, 20 Jun 2008 Chris St.Pierre wrote : >>> >Did you try the workaround in the bug report I sent to you on the >>> >Redhat list? What were your results? >>> > >>> >For reference, that bug is >>> https://bugzilla.redhat.com/show_bug.cgi?id=233642 >>> > >>> >Chris St. Pierre >>> >Unix Systems Administrator >>> >Nebraska Wesleyan University >>> > >>> >On Fri, 20 Jun 2008, debu wrote: >>> > >>> >> >>> >> >>> >>Hi Guys, >>> >> >>> >>I am stuck in a very crucial FDS server issue, it would be great >>> if any one of you can help me somehow. >>> >> >>> >>We are upgrading from Fedora Directory Service from 1.0.4 to 1.1.0-3 >>> >> >>> >>We have one existing Server with 1.0.4 >>> >> >>> >>Now To one server we have initialized the data base and we were >>> able to load the full DB. But, and when we start the replication we >>> see the following error, and the incremental update is not happening. >>> >> >>> >>We are going for a multi master replication. >>> >> >>> >> >>> >>Here is the error. >>> >> >>> >>On Supplier: (FDS Version 1.0.4) OS: Red Hat Enterprise Linux ES >>> release 4 (Nahant) >>> >> >>> >> >>> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - >>> agmt="cn=Replication_to_10.91.X.Y" (10:8888): Unable to acquire >>> replica: Excessive clock skew between the supplier and the consumer. >>> Replication is aborting. >>> >> >>> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - >>> agmt="cn=Replication_to_10.91.X.Y" (10:8888): Incremental update >>> failed and requires administrator action >>> >> >>> >> >>> >> >>> >>On consumer: (FD version 1.1.0-3) OS: Red Hat Enterprise Linux >>> Server release 5.1 (Tikanga) >>> >> >>> >> >>> >> >>> >>[17/Jun/2008:11:12:59 +051800] NSMMReplicationPlugin - conn=46251 >>> op=1975 replica="o=TejaUsers": Unable to acquire replica: error: >>> excessive clock skew >>> >> >>> >>[17/Jun/2008:11:23:34 +051800] - csngen_adjust_time: adjustment >>> limit exceeded; value - 86401, limit - 86400 >>> >> >>> >>[17/Jun/2008:11:23:34 +051800] NSMMReplicationPlugin - conn=46461 >>> op=792 replica="o=TejaUsers": Unable to acquire replica: error: >>> excessive clock skew >>> >> >>> >> >>> >>Now, My doubt is we succeded in a test environment with the same, >>> with the only diference that we had the same OS in both the server, >>> rest all same. Our servers are perfectly synced with NTP also. >>> >> >>> >>Please help in this scenario.. >>> >> >>> >>Regards >>> >>~Debajit >>> >>> >>> >>> Sharekhan Zero >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20080623/d8fae750/attachment.bin
