All, I am having issues with replication breaking once I promote a hub to a multi-master. My test set-up has a master/hub/slave environment using basic replication. This works as intended. However, once I select multi-master and set the replica id for the hub/new master, replication no longer works to the new master to the slave. The only thing that I have been able to do is disable replication on the new master, re-enable replication, create a new replication id and setup a new replication agreement and re-initializing the slave. Is there a way to get replication working on a promoted hub without completely tearing down the existing replication setup and re-initializing the slave? Thanks Cary Anderson, System Software Specialist UNIX/Linux Services Data Center Section Information Technology Services Branch Technology Services & Support Division Phone: (916) 795-2588 Fax: (916) 795-2424 Email: Cary Anderson@xxxxxxxxxxxxxx From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Rich Megginson On 11/08/2011 08:27 AM, SHAW-MILLER, JOHN (Synetrix) wrote: Its CentosDS – but the other server doesn’t have the issue? It may be an issue of operation origin - it may be that it is a problem with the processing of the original operation, or with the processing on the server that gets the operation as a replicated operation. regards, John Shaw-Miller ISP Services ITNS Professional Services
From: Rich Megginson [mailto:rmeggins@xxxxxxxxxx] On 11/08/2011 05:55 AM, SHAW-MILLER, JOHN (Synetrix) wrote: Hi Rich, To answer your questions Centos 5.6 X64 389-DS – 8.1.0 – Build 2009.134.1334 rpm -qi 389-ds-base Yes I have full administrative rights across all directory servers with an ACL The process doesn’t run, it just drops right out – no core dumps, nothing, and the log files really aren’t helpful but I intend to try and “crash” it again and see if I can find out whats happening. The ONLY log entry in /var/log/messages is to a segfault Nov 7 14:08:35 cc-teh-pds-01 kernel: ns-slapd[8677]: segfault at 00000036c682e824 rip 00002b4232552842 rsp 000000004f0c2cd0 error 7 Is this segfault from around the time the server stops responding? If so, then this is likely the cause. regards, John Shaw-Miller ISP Services ITNS Professional Services
From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Rich Megginson On 11/07/2011 07:17 AM, SHAW-MILLER, JOHN (Synetrix) wrote: All, I am wondering if any of you can help with this …… Scenario: I log into 389 using my own credentials (not the directory manager), I have full permissions on all directory servers What platform? What version of 389-ds-base? Result: 389 Directory Server stops on the logged on server, nothing in the logs, and PID is still there Can you be more specific about what you mean by "stops"? Is the process still running? If so, is it not accepting any new connections? Is it running at 100% cpu? Is there anything in the errors log from around the time it "stops"? Are there any core files in /var/log/dirsrv/slapd-INSTANCE? Recovery: Restart the service…. When you restart the service, do you see any "disorderly shutdown detected" messages in the errors log? Any slapd messages in /var/log/messages? Has anyone seen this before? It DOESN’T occur if I log in as the Directory Manager, and replication is unaffected – it just starts up again when the service is restarted regards, John Shaw-Miller ISP Services ITNS Professional Services
Synetrix (Holdings) Limited is a limited company registered in England and Wales. Registered number: 0349 1956. VAT number: GB618 1841 40. Registered office: Synetrix (Holdings) Ltd, 17-19 Rochester Row, London, SW1P 1QT. IMPORTANT NOTICE: -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users Click here to report this email as spam. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users |
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
