[Date Prev][Date Next]
Re: what databases are to be replicated for a slave?
- To: Quanah Gibson-Mount <email@example.com>
- Subject: Re: what databases are to be replicated for a slave?
- From: Jephte Clain <firstname.lastname@example.org>
- Date: Wed, 30 Dec 2015 23:01:49 +0400
- Cc: "email@example.com" <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=univ-reunion-fr.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5fCjwiawKPtc/wyBirSAk+8xi/twEgup34meh3lJhGM=; b=YY01VrTrOqCtGMvgGggPIPz1XdJVhpDyC6pnaEmKn4biwCR1pLx7NwrYFbgIB04LR5 ZTc1x/pUL5ecg8jwexBSp2I3SYUyQSfg31bE4nLKZarHt7UM25JB+OokgHDDrSIYY2Du +zUsi7Z6MlIdaUJkZbkQ/4m1F6ErZ30UR8zwOOJ/QzZS0mSCeBEYockmy7jopJIqRK3H HqvBtDPR5KHAieqaAzv50gORjI9QxUfdICLvIz/uQCRhcigy3E+aQFtdRdWYJ+E8uPwk ycdy3XBIR8StLM5PcNk6Nez4OX7P9pdzXVMlwMnF1W4EVUqH94FBro4myx6INdjxIIdq +Fdg==
- In-reply-to: <47952E452F9C593286AEB6F2@192.168.1.9>
- References: <5680DA4A.email@example.com> <8C7723C95356A14A0F8A2994@192.168.1.9> <56822AA5.firstname.lastname@example.org> <3605E973AA9B3F2264C20701@192.168.1.9> <568248E5.email@example.com> <47952E452F9C593286AEB6F2@192.168.1.9>
2015-12-29 20:38 GMT+04:00 Quanah Gibson-Mount <firstname.lastname@example.org>:
> --On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain
> <email@example.com> wrote:
>>> No. Replicas do not accept writes. Replicas do not have a master
>>> configuration for cn=config. Replica's do not have server IDs.
>> ok I guess I understand. this is the reason why I usually call them
>> "slaves", not replicas (but I messed things up and called them replicas
>> this time ^^)
>> I also have replicas that only replicate data (or a subset of data) for
>> some services
> No. The terms replica and slave are interchangeable. As are master and
> provider. Given the very negative connotations of the concept of masters
> and slaves, the preferred terms are "provider" instead of "master" and
> "replica" instead of "slaves".
Aaargh, now I can't help thinking about "providers" whipping
"replicas". slapd can be so cruel sometimes :-)
And in case you wonder, here in reunion island we have a (relatively)
long history of slavery. We even have a day to commemorate abolition
of slavery: december 20th
>> the slaves are there in case of catastrophic failure of both masters (we
>> had one of these failure for another service due to a problem with the
>> shared storage. No one want to have this kind of emergency...)
>> If the master(s) crash, I just have to choose a slave as the new master,
>> slapcat the cn=config database, update the provider address, slapadd the
>> updated config, and update the loadbalancer settings. this is a bit of
>> work but at least we can restore service in a (relatively) small amount
>> of time.
> If they accept writes, they are not slaves/replicas. If you are replicating
> cn=config across all the systems, then they must all be masters. Your
> general description above sounds like you do not correctly understand how
> MMR functions.
OK... I finally understand what was bothering you
My replicas do _not_ accept writes. Sorry to have let you think so
I have two setups:
- a "legacy" one, with one master accessible to the applications that
can write, and two complete replicas (data + cn=config) behind a
loadbalancer for the reads. One of these replicas could become the new
master if the needs arise. And there are a bunch of partial replicas
(only a subset of data) for some specific services. The reason is on
our vmware farm, network access is regularly cut (don't know why, the
system guy neither), and these services cannot reconnect on their
own... piece of #$*! software :(
- a "new" one, with two masters in mirror mode (only one get the
writes at anytime thanks to the loadbalancer), and two replicas (only
data) which get all the reads. I feel like configuring chaining to be
able to write from the replicas, but I have no experience of the
benefits of this configuration...
I have read the admin guide several times, but I am open to any
suggestion to improve my skills
>>> Accesslog is unique to a given master.
>> Ok that's what I wanted to know for sure
>> Shouldn't the doc stat this clearly?
> Please file an ITS noting the docs should be updated on this point.
Ok. I may even provide a patch. I'll do it tomorrow.
Have a nice day/night (don't know where you live ^^)
Jephté CLAIN | Développeur, Intégrateur d'applications
Service Système d'Information
Direction des Systèmes d'Information
Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24