Crash while performing initial sync (2.2) - mongodb-user

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Crash while performing initial sync (2.2)
Date: Thu, 15 Nov 2012 12:09:10 -0800 (PST)
From: Eric Milkie <mil...@10gen.com>
To: mongodb-user@googlegroups.com
Message-Id: <d63ef07c-f2d5-4dec-96b7-d1e129940322@googlegroups.com>
In-Reply-To: <11de370b-a395-4609-af1c-9707c22ba375@googlegroups.com>
References: <09042996-fd83-4369-b3a7-9df02f6a5736@googlegroups.com>
 <4b9bc55c-0bfc-44bc-9bee-2fa0cddf15a9@googlegroups.com>
 <dfe384da-ed03-41c2-b89c-d0ef451ad2c9@googlegroups.com>
 <c87ec043-3340-436c-935a-9a5b6abc8031@googlegroups.com>
 <4ed8b44a-0d51-42b7-af6d-40d2c5525920@googlegroups.com>
 <11de370b-a395-4609-af1c-9707c22ba375@googlegroups.com>
Subject: Re: Crash while performing initial sync (2.2)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_705_21496013.1353010150720"

------=_Part_705_21496013.1353010150720
Content-Type: multipart/alternative; 
	boundary="----=_Part_706_2936546.1353010150720"

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

Hi Andy,
Sorry about the lack of clarity regarding this bug.  SERVER-5961 was 
mismarked as "Fixed in 2.3" when in fact it was superseded by two other 
SERVER tickets mentioned at the bottom of it.  The fixes for those tickets 
were actually committed to version 2.2.1, but there are some caveats to the 
fixes which you have personally run into.

It turns out that the fix is not competely live until the primary is 
running 2.2.1, since it is the primary that is generating the 
non-idempotent operations.  To upgrade fully to 2.2.1 (or 2.2.2, which is 
in rc now and will be released in 2 weeks), you will need to sync a 
secondary on 2.2.1 and then make that the primary while you upgrade the 
other members of the replica set.
To do so, we have some options:
1- stop writes on the primary while the secondary is cloning databases 
(after the first clone stage, writes can proceed again)
2- restart all members of the replica set onto 2.2.1 after taking a backup
3- start a secondary using a copy of the datafiles from the primary, rather 
than allowing initial sync to clone the data

There is also one fix in 2.2.2 that makes this upgrade more likely to 
succeed, as it restores some of the 2.0.x behavior if a secondary is 
syncing from a primary of that version.
-Eric


------=_Part_706_2936546.1353010150720
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<span class=3D"Apple-style-span" style=3D"border-collapse: separate; color:=
 rgb(0, 0, 0); font-family: Helvetica; border-spacing: 0px; font-size: medi=
um; ">Hi Andy,</span><div><span class=3D"Apple-style-span" style=3D"border-=
collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; border-spa=
cing: 0px; font-size: medium; ">Sorry about the lack of clarity regarding t=
his bug. &nbsp;SERVER-5961 was mismarked as "Fixed in 2.3" when in fact it =
was superseded by two other SERVER tickets mentioned at the bottom of it. &=
nbsp;The fixes for those tickets were actually committed to version 2.2.1, =
but there are some caveats to the fixes which you have personally run into.=
</span></div><div><span class=3D"Apple-style-span" style=3D"border-collapse=
: separate; color: rgb(0, 0, 0); font-family: Helvetica; border-spacing: 0p=
x; font-size: medium; "><br></span></div><div><span class=3D"Apple-style-sp=
an" style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: H=
elvetica; border-spacing: 0px; font-size: medium; ">It turns out that the f=
ix is not competely live until the primary is running 2.2.1, since it is th=
e primary that is generating the non-idempotent operations. &nbsp;To upgrad=
e fully to 2.2.1 (or 2.2.2, which is in rc now and will be released in 2 we=
eks), you will need to sync a secondary on 2.2.1 and then make that the pri=
mary while you upgrade the other members of the replica set.<div>To do so, =
we have some options:</div><div>1- stop writes on the primary while the sec=
ondary is cloning databases (after the first clone stage, writes can procee=
d again)</div><div>2- restart all members of the replica set onto 2.2.1 aft=
er taking a backup</div><div>3- start a secondary using a copy of the dataf=
iles from the primary, rather than allowing initial sync to clone the data<=
/div><div><br></div><div>There is also one fix in 2.2.2 that makes this upg=
rade more likely to succeed, as it restores some of the 2.0.x behavior if a=
 secondary is syncing from a primary of that version.</div><span class=3D"H=
OEnZb"><font color=3D"#888888">-Eric</font></span><div><div class=3D"h5"></=
div></div></span><div><span class=3D"Apple-style-span" style=3D"border-coll=
apse: separate; color: rgb(0, 0, 0); font-family: Helvetica; border-spacing=
: 0px; font-size: medium; "><span class=3D"HOEnZb"><font color=3D"#888888">=
<br></font></span></span></div></div>
------=_Part_706_2936546.1353010150720--

------=_Part_705_21496013.1353010150720--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
