Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
6.5.0
-
Untriaged
-
1
-
Yes
Description
It so happens that we can interrupt a hard failover of one node to then auto-failover the same node. ns_server should not be overriding a hard failover request from the user to do an auto-failover.
Before 6.5 hard failover was a synchronous operation, that would be completed in the idle state.
For durability we made changes to hard failover which potentially could take a long time to complete. Hence, we perform this failover in rebalancing state and return immediately to the user.
This allows hard failover to be interrupted, by auto-failover, which is not desirable.
Attachments
| For Gerrit Dashboard: MB-42420 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 139322,2 | MB-42420 auto-failover shouldn't interrupt hard failover | mad-hatter | ns_server | Status: MERGED | +2 | +1 |
| 139485,1 | Merge remote-tracking branch 'couchbase/mad-hatter' | master | ns_server | Status: MERGED | +2 | +1 |
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Dave Finlay [ dfinlay ] | Abhijeeth Nuthan [ abhijeeth.nuthan ] |
| Description |
It so happens that we can interrupt a failover of one node to then auto-failover the same node.
I feel we should not be overriding a failover request from the user to do an auto-failover. |
It so happens that we can interrupt a failover of one node to then auto-failover the same node. ns_server should not be overriding a failover request from the user to do an auto-failover.
Before 6.5 failover was a synchronous operation, that would be completed in the idle state. For durability we made changes to failover which potentially could take a long time to complete. Hence, we perform failover in rebalancing state and return immediately to the user. This allows failover to be interrupted, by auto-failover, which is not desirable. |
| Is this a Regression? | Unknown [ 10452 ] | Yes [ 10450 ] |
| Description |
It so happens that we can interrupt a failover of one node to then auto-failover the same node. ns_server should not be overriding a failover request from the user to do an auto-failover.
Before 6.5 failover was a synchronous operation, that would be completed in the idle state. For durability we made changes to failover which potentially could take a long time to complete. Hence, we perform failover in rebalancing state and return immediately to the user. This allows failover to be interrupted, by auto-failover, which is not desirable. |
It so happens that we can interrupt a failover of one node to then auto-failover the same node. ns_server should not be overriding a hard failover request from the user to do an auto-failover.
Before 6.5 failover was a synchronous operation, that would be completed in the idle state. For durability we made changes to failover which potentially could take a long time to complete. Hence, we perform failover in rebalancing state and return immediately to the user. This allows failover to be interrupted, by auto-failover, which is not desirable. |
| Summary | failover gets interrupted by auto-failover | Hard failover gets interrupted by auto-failover |
| Description |
It so happens that we can interrupt a failover of one node to then auto-failover the same node. ns_server should not be overriding a hard failover request from the user to do an auto-failover.
Before 6.5 failover was a synchronous operation, that would be completed in the idle state. For durability we made changes to failover which potentially could take a long time to complete. Hence, we perform failover in rebalancing state and return immediately to the user. This allows failover to be interrupted, by auto-failover, which is not desirable. |
It so happens that we can interrupt a hard failover of one node to then auto-failover the same node. ns_server should not be overriding a hard failover request from the user to do an auto-failover.
Before 6.5 hard failover was a synchronous operation, that would be completed in the idle state. For durability we made changes to hard failover which potentially could take a long time to complete. Hence, we perform this failover in rebalancing state and return immediately to the user. This allows hard failover to be interrupted, by auto-failover, which is not desirable. |
| Link | This issue blocks MB-40528 [ MB-40528 ] |
| Labels | approved-for-6.6.1 |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
Build couchbase-server-7.0.0-3620 contains ns_server commit d629e0c with commit message:
MB-42420 auto-failover shouldn't interrupt hard failover
| Attachment | MB-42420.png [ 116291 ] |
Validated this on Enterprise Edition 6.6.1 build 9192 ‧ IPv4 © 2020 Couchbase, Inc.
See 
for more details.
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Build couchbase-server-6.6.1-9166 contains ns_server commit d629e0c with commit message:
MB-42420auto-failover shouldn't interrupt hard failover