[Date Prev][Date Next]
Re: Fixing a multi-master divergence
- Subject: Re: Fixing a multi-master divergence
- From: Guillaume Rousse <email@example.com>
- Date: Tue, 04 Sep 2012 12:12:57 +0200
- Cc: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=S7wSESOoLFjHjxNcHCTq4O6XNjyDUYIsE/VnshfDCX4=; b=TqA2yurGlzfyr9/U8HkhAWOTwHxY+t4Awt0/ML/vcKeW4ql4o87bs1R8KbDvn3DOcV d/uZKuelFOhDJmujhZicbSbCTm0/fbsS4cw2L9D/+2xVNx+6nm9OBO89magDEqr66BG3 rqazYj8dzZCZ2ySJuhNd0ZuA3PPFf/yH3Ri/eWllgRCxt4LgWGA+pO2bUVS5oN4kazIm Yj9WyF6ZFNFMBLH3RpDq2PBcCpO8+AKyOEea0wv7gI1oYprdsyzM8vpBtnCY+gqjMHuA M8NpO+2UF+j0fMxtjng6Dc1KjlYatNFHFGDtK9uejGuORY1NIQ/zmHbt0M/YRyQ6vA96 5jlg==
- In-reply-to: <B1AD8261A0E3E8B8E5AC6156@[192.168.1.52]>
- References: <5044B60E.email@example.com> <B1AD8261A0E3E8B8E5AC6156@[192.168.1.52]>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120829 Thunderbird/15.0
Le 03/09/2012 22:45, Quanah Gibson-Mount a écrit :
--On Monday, September 03, 2012 3:52 PM +0200 Guillaume Rousse
I can't change ldap version easily, and I'd rather return to classic
master-slave setup if the problem is not fixable otherwise.
I would advise you to read the CHANGES file and look at all the fixes
for Syncrepl and MMR since 2.4.23 was released, and then hopefully you
realize that either upgrading the *patch* level or going back to classic
provider-replica setup is the wise choice.
Since the CHANGES file is publicly available on the web, I'm somewhat
unclear as to why you haven't already read it over and come to a very
quick and easy conclusion.
I did, of course.
However, just the number of issues isn't enough to distinguish between
corner-case and immediate issues. Given than I've been running ldap
server 2.4.19 in multi-master modes for years without effective
problems, I'm quite used to moderate the usual 'you should never run
anything else than the latest version otherwise everything will blow up'
advice. Also, I'm in a very low-concurrency setup, and I could easily
make sure 99% of write operations always apply on a single server.
BTW, I jsut figured than multiple CSNcontext values was perfectly
normal: one is expected per data provided, and the third value (the one
labelled with rid 0) was due to artifacts of my initial dataset.
BOFH excuse #72:
Satan did it