[Fedora-directory-users] MMR issue

Mon Jun 23 16:48:04 UTC 2008

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://listman.redhat.com/archives/fedora-directory-users/attachments/20080623/d8fae750/attachment.bin>