Received: by 10.68.238.65 with SMTP id vi1mr9901398pbc.7.1338797675558;
        Mon, 04 Jun 2012 01:14:35 -0700 (PDT)
X-BeenThere: mongodb-user@googlegroups.com
Received: by 10.68.195.100 with SMTP id id4ls13422993pbc.8.gmail; Mon, 04 Jun
 2012 01:14:24 -0700 (PDT)
Received: by 10.68.240.33 with SMTP id vx1mr436787pbc.10.1338797664542;
        Mon, 04 Jun 2012 01:14:24 -0700 (PDT)
Date: Mon, 4 Jun 2012 01:14:23 -0700 (PDT)
From: Asya Kamsky <a...@10gen.com>
To: mongodb-user@googlegroups.com
Message-Id: <78986ded-8c8b-44ea-acf2-b80ca0b48270@googlegroups.com>
In-Reply-To: <fb2e0a0a-2436-40f4-ac09-55edf7e4d7f3@googlegroups.com>
References: <fb2e0a0a-2436-40f4-ac09-55edf7e4d7f3@googlegroups.com>
Subject: Re: Config server maintenance
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1079_9875497.1338797663460"

------=_Part_1079_9875497.1338797663460
Content-Type: multipart/alternative; 
	boundary="----=_Part_1080_17266675.1338797663460"

------=_Part_1080_17266675.1338797663460
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Erez,

The three config servers are not a replica set, they are three independent 
mongod servers.  All three are used by mongos processes.

When you take one of them down, the other config servers will become 
read-only - your sharded cluster will continue to operate, but no chunk 
splitting or balancing will happen (in other words, the sharding 
configuration becomes read-only, not your data).

This means that when you restore the data to hostA and start it again, it 
will not be "behind" the other two config servers (since those were 
read-only during the maintenance window) and it will not need to "catch 
up".   

Once there are three config servers again, the sharded cluster will be able 
to resume splitting and balancing as needed.

Asya

On Monday, June 4, 2012 12:33:08 AM UTC-7, Erez Zarum wrote:
>
> I have 3 config servers in a sharded environment hostA,hostB,hostC, i have 
> to take down hostA for maintenance.
> I will first shutdown the config server on hostA (it will automatically 
> failover to hostB), then i will backup the data on hostA.
> I assume the maintenance will take around 1 hour, after i am done with it, 
> i will copy the data back to hostA (after maintenance) and start it again.
> I couldn't find any information as of how much time can i let hostA be 
> down without it going out of sync and not able to "resync"? is there any 
> rule of thumb for that?
>
>
------=_Part_1080_17266675.1338797663460
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div>Hi Erez,</div><div><br></div>The three config servers are not a replic=
a set, they are three independent mongod servers. &nbsp;All three are used =
by mongos processes.<div><br></div><div>When you take one of them down, the=
 other config servers will become read-only - your sharded cluster will con=
tinue to operate, but no chunk splitting or balancing will happen (in other=
 words, the sharding configuration becomes read-only, not your data).</div>=
<div><br></div><div>This means that when you restore the data to hostA and =
start it again, it will not be "behind" the other two config servers (since=
 those were read-only during the maintenance window) and it will not need t=
o "catch up". &nbsp;&nbsp;</div><div><br></div><div>Once there are three co=
nfig servers again, the sharded cluster will be able to resume splitting an=
d balancing as needed.</div><div><br></div><div>Asya<br><br>On Monday, June=
 4, 2012 12:33:08 AM UTC-7, Erez Zarum wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">I have 3 config servers in a sharded environment hostA,hostB=
,hostC, i have to take down hostA for maintenance.<div>I will first shutdow=
n the config server on hostA (it will automatically failover to hostB), the=
n i will backup the data on hostA.</div><div>I assume the maintenance will =
take around 1 hour, after i am done with it, i will copy the data back to h=
ostA (after maintenance) and start it again.</div><div>I couldn't find any =
information as of how much time can i let hostA be down without it going ou=
t of sync and not able to "resync"? is there any rule of thumb for that?</d=
iv><div><br></div></blockquote></div>
------=_Part_1080_17266675.1338797663460--

------=_Part_1079_9875497.1338797663460--