Outage due to Replica Set Protocol Version upgrade?
My production system has a replica set created in MongoDB v3.0, which still has protocol version undefined (i.e. version 0). It is now running v3.4 and I intend to upgrade to replica set protocol version 1, but I'm wary of what will happen while the replica set reconfigures itself.
Is there any risk of an outage at all? Either if all nodes are running normally, or if any nodes have problems during the change? The documentation warns that reconfiguration can trigger the current primary to step down in some situations but doesn't say which situations.
Apart from the protocol version, I am making no other configuration changes; for example, the member priorities will be unchanged so the same priority node will hopefully remain primary.
The current config is:
rsMyApp:PRIMARY> rs.conf()
{
"_id" : "rsMyApp",
"version" : 26139,
"members" : [
{
"_id" : 4,
"host" : "DB2:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 5,
"host" : "DB3:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "DB1:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 60000,
"getLastErrorModes" : {},
"getLastErrorDefaults" : {
"w" : "majority",
"wtimeout" : 0
}
}
}
mongodb
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
bumped to the homepage by Community♦ 10 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
My production system has a replica set created in MongoDB v3.0, which still has protocol version undefined (i.e. version 0). It is now running v3.4 and I intend to upgrade to replica set protocol version 1, but I'm wary of what will happen while the replica set reconfigures itself.
Is there any risk of an outage at all? Either if all nodes are running normally, or if any nodes have problems during the change? The documentation warns that reconfiguration can trigger the current primary to step down in some situations but doesn't say which situations.
Apart from the protocol version, I am making no other configuration changes; for example, the member priorities will be unchanged so the same priority node will hopefully remain primary.
The current config is:
rsMyApp:PRIMARY> rs.conf()
{
"_id" : "rsMyApp",
"version" : 26139,
"members" : [
{
"_id" : 4,
"host" : "DB2:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 5,
"host" : "DB3:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "DB1:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 60000,
"getLastErrorModes" : {},
"getLastErrorDefaults" : {
"w" : "majority",
"wtimeout" : 0
}
}
}
mongodb
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
bumped to the homepage by Community♦ 10 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Please post yourrs.conf()in your question
– RolandoMySQLDBA
Jan 4 '18 at 16:17
@RolandoMySQLDBA I've added it.
– Vince Bowdren
Jan 4 '18 at 16:30
It appearsDB1must be PRIMARY since it has priority 2. Questions: 1) Have you upgradedDB2orDB3yet ??? 2. Can you failover the PRIMARY toDB2orDB3???
– RolandoMySQLDBA
Jan 4 '18 at 19:37
I asked these questions in the event something goes awry.
– RolandoMySQLDBA
Jan 4 '18 at 19:53
All the nodes are at v3.4. The three nodes have the same hardware, and the different priorities are purely for convenience; it makes maintenance easier if you can just connect to DB1 and count on it being primary.
– Vince Bowdren
Jan 5 '18 at 9:01
add a comment |
My production system has a replica set created in MongoDB v3.0, which still has protocol version undefined (i.e. version 0). It is now running v3.4 and I intend to upgrade to replica set protocol version 1, but I'm wary of what will happen while the replica set reconfigures itself.
Is there any risk of an outage at all? Either if all nodes are running normally, or if any nodes have problems during the change? The documentation warns that reconfiguration can trigger the current primary to step down in some situations but doesn't say which situations.
Apart from the protocol version, I am making no other configuration changes; for example, the member priorities will be unchanged so the same priority node will hopefully remain primary.
The current config is:
rsMyApp:PRIMARY> rs.conf()
{
"_id" : "rsMyApp",
"version" : 26139,
"members" : [
{
"_id" : 4,
"host" : "DB2:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 5,
"host" : "DB3:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "DB1:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 60000,
"getLastErrorModes" : {},
"getLastErrorDefaults" : {
"w" : "majority",
"wtimeout" : 0
}
}
}
mongodb
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
My production system has a replica set created in MongoDB v3.0, which still has protocol version undefined (i.e. version 0). It is now running v3.4 and I intend to upgrade to replica set protocol version 1, but I'm wary of what will happen while the replica set reconfigures itself.
Is there any risk of an outage at all? Either if all nodes are running normally, or if any nodes have problems during the change? The documentation warns that reconfiguration can trigger the current primary to step down in some situations but doesn't say which situations.
Apart from the protocol version, I am making no other configuration changes; for example, the member priorities will be unchanged so the same priority node will hopefully remain primary.
The current config is:
rsMyApp:PRIMARY> rs.conf()
{
"_id" : "rsMyApp",
"version" : 26139,
"members" : [
{
"_id" : 4,
"host" : "DB2:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 5,
"host" : "DB3:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "DB1:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 60000,
"getLastErrorModes" : {},
"getLastErrorDefaults" : {
"w" : "majority",
"wtimeout" : 0
}
}
}
mongodb
mongodb
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
edited Jan 5 '18 at 8:59
Vince Bowdren
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
asked Jan 4 '18 at 16:15
Vince BowdrenVince Bowdren
351115
351115
bumped to the homepage by Community♦ 10 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 10 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Please post yourrs.conf()in your question
– RolandoMySQLDBA
Jan 4 '18 at 16:17
@RolandoMySQLDBA I've added it.
– Vince Bowdren
Jan 4 '18 at 16:30
It appearsDB1must be PRIMARY since it has priority 2. Questions: 1) Have you upgradedDB2orDB3yet ??? 2. Can you failover the PRIMARY toDB2orDB3???
– RolandoMySQLDBA
Jan 4 '18 at 19:37
I asked these questions in the event something goes awry.
– RolandoMySQLDBA
Jan 4 '18 at 19:53
All the nodes are at v3.4. The three nodes have the same hardware, and the different priorities are purely for convenience; it makes maintenance easier if you can just connect to DB1 and count on it being primary.
– Vince Bowdren
Jan 5 '18 at 9:01
add a comment |
Please post yourrs.conf()in your question
– RolandoMySQLDBA
Jan 4 '18 at 16:17
@RolandoMySQLDBA I've added it.
– Vince Bowdren
Jan 4 '18 at 16:30
It appearsDB1must be PRIMARY since it has priority 2. Questions: 1) Have you upgradedDB2orDB3yet ??? 2. Can you failover the PRIMARY toDB2orDB3???
– RolandoMySQLDBA
Jan 4 '18 at 19:37
I asked these questions in the event something goes awry.
– RolandoMySQLDBA
Jan 4 '18 at 19:53
All the nodes are at v3.4. The three nodes have the same hardware, and the different priorities are purely for convenience; it makes maintenance easier if you can just connect to DB1 and count on it being primary.
– Vince Bowdren
Jan 5 '18 at 9:01
Please post your
rs.conf() in your question– RolandoMySQLDBA
Jan 4 '18 at 16:17
Please post your
rs.conf() in your question– RolandoMySQLDBA
Jan 4 '18 at 16:17
@RolandoMySQLDBA I've added it.
– Vince Bowdren
Jan 4 '18 at 16:30
@RolandoMySQLDBA I've added it.
– Vince Bowdren
Jan 4 '18 at 16:30
It appears
DB1 must be PRIMARY since it has priority 2. Questions: 1) Have you upgraded DB2 or DB3 yet ??? 2. Can you failover the PRIMARY to DB2 or DB3 ???– RolandoMySQLDBA
Jan 4 '18 at 19:37
It appears
DB1 must be PRIMARY since it has priority 2. Questions: 1) Have you upgraded DB2 or DB3 yet ??? 2. Can you failover the PRIMARY to DB2 or DB3 ???– RolandoMySQLDBA
Jan 4 '18 at 19:37
I asked these questions in the event something goes awry.
– RolandoMySQLDBA
Jan 4 '18 at 19:53
I asked these questions in the event something goes awry.
– RolandoMySQLDBA
Jan 4 '18 at 19:53
All the nodes are at v3.4. The three nodes have the same hardware, and the different priorities are purely for convenience; it makes maintenance easier if you can just connect to DB1 and count on it being primary.
– Vince Bowdren
Jan 5 '18 at 9:01
All the nodes are at v3.4. The three nodes have the same hardware, and the different priorities are purely for convenience; it makes maintenance easier if you can just connect to DB1 and count on it being primary.
– Vince Bowdren
Jan 5 '18 at 9:01
add a comment |
1 Answer
1
active
oldest
votes
What that protocol change do, is change decision pattern what nodes do when new primary must be elected. At the situation where all SECONDARY nodes are up-to-date (not falling behind) and your current PRIMARY have higher priority than any of SECONDARY node, nothing will happen. The system continues as it was.
But afterward, if your current PRIMARY is unavailable, next primary is elected faster than it was with protocolVersion:0
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f194635%2foutage-due-to-replica-set-protocol-version-upgrade%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
What that protocol change do, is change decision pattern what nodes do when new primary must be elected. At the situation where all SECONDARY nodes are up-to-date (not falling behind) and your current PRIMARY have higher priority than any of SECONDARY node, nothing will happen. The system continues as it was.
But afterward, if your current PRIMARY is unavailable, next primary is elected faster than it was with protocolVersion:0
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
add a comment |
What that protocol change do, is change decision pattern what nodes do when new primary must be elected. At the situation where all SECONDARY nodes are up-to-date (not falling behind) and your current PRIMARY have higher priority than any of SECONDARY node, nothing will happen. The system continues as it was.
But afterward, if your current PRIMARY is unavailable, next primary is elected faster than it was with protocolVersion:0
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
add a comment |
What that protocol change do, is change decision pattern what nodes do when new primary must be elected. At the situation where all SECONDARY nodes are up-to-date (not falling behind) and your current PRIMARY have higher priority than any of SECONDARY node, nothing will happen. The system continues as it was.
But afterward, if your current PRIMARY is unavailable, next primary is elected faster than it was with protocolVersion:0
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
What that protocol change do, is change decision pattern what nodes do when new primary must be elected. At the situation where all SECONDARY nodes are up-to-date (not falling behind) and your current PRIMARY have higher priority than any of SECONDARY node, nothing will happen. The system continues as it was.
But afterward, if your current PRIMARY is unavailable, next primary is elected faster than it was with protocolVersion:0
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
answered Jan 6 '18 at 9:39
JJussiJJussi
3,0341314
3,0341314
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f194635%2foutage-due-to-replica-set-protocol-version-upgrade%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please post your
rs.conf()in your question– RolandoMySQLDBA
Jan 4 '18 at 16:17
@RolandoMySQLDBA I've added it.
– Vince Bowdren
Jan 4 '18 at 16:30
It appears
DB1must be PRIMARY since it has priority 2. Questions: 1) Have you upgradedDB2orDB3yet ??? 2. Can you failover the PRIMARY toDB2orDB3???– RolandoMySQLDBA
Jan 4 '18 at 19:37
I asked these questions in the event something goes awry.
– RolandoMySQLDBA
Jan 4 '18 at 19:53
All the nodes are at v3.4. The three nodes have the same hardware, and the different priorities are purely for convenience; it makes maintenance easier if you can just connect to DB1 and count on it being primary.
– Vince Bowdren
Jan 5 '18 at 9:01