[Date Prev][Date Next]
Re: what databases are to be replicated for a slave?
- To: Quanah Gibson-Mount <email@example.com>, firstname.lastname@example.org
- Subject: Re: what databases are to be replicated for a slave?
- From: Jephte Clain <email@example.com>
- Date: Tue, 29 Dec 2015 12:48:37 +0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=univ-reunion-fr.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MT8Th1Vugqq9olHVzoxy9tTwGhdYKie0qIx88wlj9+I=; b=1MaW4CNt5bbxTQLYZbfvzvSqOAobsCxwrahQ2/Ygqr99Yog+WiLa7maTtnh8rXt/Ht hBQYZQ2xrt3tx2GpRYB2qpj6mydoITgZRHtRQSXRLx2YgEhXdiJp/mfKVGVUmfTPI3Qf 8fKiqKddhmC8Gp7z8K1LCalqAD54ejpsziZr+uRQXUZryz7C/HjFeaARKTR9742du1t8 wLd5580+no6iJk1wcyVmRXU6LZZV20v9dUyMTSE9+2FJa0Q55TbK/k3Mp+kft5KZb6NH fpFz0G1Svqvi5I4G05kvGIH3ifObXQ5nPhLOOfUNvX0v9+gitN4BYyfhDJqGInOsNw01 TxEQ==
- In-reply-to: <3605E973AA9B3F2264C20701@[192.168.1.9]>
- References: <5680DA4A.firstname.lastname@example.org> <8C7723C95356A14A0F8A2994@[192.168.1.9]> <56822AA5.email@example.com> <3605E973AA9B3F2264C20701@[192.168.1.9]>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
Le 29/12/2015 11:04, Quanah Gibson-Mount a écrit :
--On Tuesday, December 29, 2015 10:39 AM +0400 Jephte Clain
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
Le 28/12/2015 19:12, Quanah Gibson-Mount a écrit :
I'm not sure to understand what you are saying.
the "master" and the "slaves" are identical, and the cn=config are the
same on all hosts
so they are truly replicates, right?
No. Replicas do not accept writes. Replicas do not have a master
configuration for cn=config. Replica's do not have server IDs.
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
In fact, the configuration is generated by a script I wrote several
ago, and all databases for a "master" configuration are generated with a
syncprov overlay and a syncrepl directive, to enable "seed replication":
After the problems I had, I took the time to read the admin guide again
and noticed the accesslog database was not to be replicated, or it
I then wondered if the replication I configured on the accesslog
was the cause for my issues...
hence my question to be sure I understood correctly
Accesslog is unique to a given master.
Ok that's what I wanted to know for sure
Shouldn't the doc stat this clearly?
Here is another question: if an accesslog database is stricly local to a
server, how should two masters in mirror mode be configured?
I have a bi-master setup with an active/passive configuration: the
loadbalancer only send the requests to the first master, unless it stop
if the first master crashes, and writes are diriged toward the second
master, won't I lose the accesslog informations?
Every master must have a unique server ID. Each master will replicate
the writes from another master, and update their accesslog
accordingly. You will not lose any writes.
that's a relief
I'm guessing your configurations are generally incorrect.
Yes, I'm updating them right now to disable replication of the accesslog
Thanks a lot for the clarification. In case you come to the reunion
island someday, I owe you a beer!
*Jephté CLAIN | Développeur, Intégrateur d'applications*
Service Systèmes d'Information
Direction des Systèmes d'Information <http://dsi.univ-reunion.fr>
Tél: +262 262 93 86 31 <tel:+262262938631> || Gsm: +262 692 29 58 24
www.univ-reunion.fr <http://www.univ-reunion.fr> || Facebook
|| Twitter <http://twitter.com/univ_reunion>