[SERVER-8649] upgrade 2.0.6 -> 2.2.3 Created: 21/Feb/13 Updated: 10/Dec/14 Resolved: 04/Jun/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Kenny Gorman | Assignee: | Nicholas Tang |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
We would like to upgrade just a single slave in a 2.0.6 replica set to 2.2.3. This is in a sharded configuration. The reason for this is we want to just upgrade the most minimalistic portion of the set we can, so users can test with their code/drivers against the slave and ensure there aren't core incompatibilities. We would then shut down everything and upgrade all components to 2.2.3 when they are sure everything works OK. This doc: http://docs.mongodb.org/manual/release-notes/2.2/ Doesn't appears to address this situation directly. Can you commend on any potential issues with having 1 member of a RS in a sharded configuration as 2.2.3? We would reconfigure it so with priority = 0 so it can't become master. I am testing this now, and so far it seems to be benign. But I want your official opinion. I have no problem updating the docs and doing a pull request should this be OK. |
| Comments |
| Comment by Ian Whalen (Inactive) [ 04/Jun/13 ] | |
|
Hi Kenny, I'm closing this now since we haven't heard back, but please don't hesitate to let us know if you have any more questions and I'll re-open the ticket. | |
| Comment by Nicholas Tang [ 27/Feb/13 ] | |
|
Kenny, Just wanted to check in on this and see how it was going - do you need any additional assistance? Is the testing going well? Thanks, | |
| Comment by Mark porter [ 25/Feb/13 ] | |
|
Hi Kenny, First off, sorry for the delay in responding. We definitely support running a secondary on a newer version of the code, even for a more extended period; the docs that you referenced imply it here:
but you're correct, they don't state it explicitly. We support running multiple versions for an extended period, but generally to be safe we recommend that you keep that extended period shorter rather than longer as there is naturally less testing done against differing versions than with matching versions. In your case, while testing the 2.2.3 secondary, I would recommend setting it to hidden. This will prevent it from receiving any queries except from the clients that you manually connect directly to it. Having a priority of 0 without making the node hidden will still allow clients with a read preference of secondary or secondaryPreferred to read from it, thus preventing you from completely isolating it during testing. Any questions, please let me know. Thanks, | |
| Comment by Kenny Gorman [ 21/Feb/13 ] | |
|
Just a bit more info. When I say above 'test the drivers/code', I mean they would connect to the 2.2.3 slave directly, set slaveOK() and perform sanity checks. Basically bypass the 2.0.6 mongos's just for this sanity test. |