[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8609) segfault in mods.c - modify_add_values
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8609) segfault in mods.c - modify_add_values
- From: hyc@symas.com
- Date: Fri, 21 Apr 2017 00:26:26 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
quanah@symas.com wrote:
> --On Thursday, April 20, 2017 9:02 PM +0000 henson@acm.org wrote:
>
>>> From: Quanah Gibson-Mount
>>> Sent: Thursday, April 20, 2017 8:07 AM
>>>
>>> You stated previously that you are in 4-way MMR. It's not valid to have
>>> a serverID of 0 in an MMR environment (See
>>> <http://www.openldap.org/its/index.cgi/?findid=8635>).
>>
>> Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people
>> have serverID's of 0 in their replicated environments, as I don't know
>> that I've ever seen that information before. What are the ramifications
>> of having a server with an ID of 0 in a replicated environment? What is
>> the procedure for remediating the issue? Is it as simple as shutting down
>> that server, updating the configuration to have a serverID of 4 and
>> restarting it? Or does the database need to be stripped of all CSN's
>> which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w
>> option on the master and then reloading from ldif on all the replicas?
>
> It's fine for there to be legacy entryCSNs and a contextCSN for serverID of
> 0. However, it is not fine for any master in an MMR setup to have a
> specific serverID of 0. If you're running with serverID's 0-3, I'd simply
> try an ldapmodify on the server with 0 to set its serverID to 4, and then
> do a modification against it, so it generates a new contextCSN that gets
> pushed out to all nodes.
Performance-wise, it would be better to delete the SID 0 contextCSN value too.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/