© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Reproduced on 3.0
Status:
https:/
Force removal of the primary (0), IP 10.246.27.32. It does a step-down, and calculates are peer-group change with a single voter to maintain an odd number. It reports success, *but* it is confused as to who the primary is. 10.246.27.45 (machine 1) is reported as self=true.
https:/
Despite reporting success, the replica-set does not change.
https:/
Over on machine 1, which is reported as the primary when you log into Mongo, it seems to think that it is machine 0.
https:/
It is trying to remove member 1 (machine 0) but keeps failing, despite being primary.
https:/
It certainly says PRIMARY when you connect directly to it.
https:/
I think we're somehow using sessions with crossed wires.
At this point machine 0 is still not gone. If you force delete the container you get into the situation we observed 2 days ago.
https:/
An no matter how many times you try to force delete machine 0, even with the container gone, it will not go away.
Restart the whole container under machine 1 to see what happens. It reports success changing the replicaset, but it thinks it's machine 2.
https:/
Tried bouncing the container for machine 2 as well. No improvement.
All the while we keep reporting the same replica-set.
2023-04-20 09:29:04 DEBUG juju.replicaset replicaset.go:669 current replicaset config: {
Name: juju,
Version: 3,
Term: 11,
Protocol Version: 1,
Members: {
{1 "10.246.
{2 "10.246.
{3 "10.246.
},
}
As an added bonus in this case. Raft gets borked, and we have no singular controller lease. So running enable HA again adds a machine that can never be provisioned.
An altogether miserable state.
https:/