[CONTROLLER-1529] Operational shards on non-voting members do not resync when voting members are restarted Created: 27/Jun/16 Updated: 19/Oct/17 Resolved: 18/Jul/16 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | Beryllium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Ajay Chhabria | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 6115 |
| Description |
|
If we isolate a controller node in a clustered setup and un-isolate it back, the shards doesn't sync automatically. Following are the ip table commands to be ran on the controller node to be isolated: sudo /sbin/iptables -A INPUT -p tcp --destination-port 2550 -j DROP -s 10.18.162.83 Following are the ip table commands to be ran on the controller node to be unisolated: sudo /sbin/iptables -D INPUT -p tcp --destination-port 2550 -j DROP -s 10.18.162.83 |
| Comments |
| Comment by Tom Pantelis [ 28/Jun/16 ] |
|
I should clarify the description. This is in a special setup where you have non-voting members and persistence off for operational shards (which is the default). If you restart all the voting members, they will come up with no data as persistence is off. However the non-voting members still retain their operational data in memory and, since they can't become the leader, their lastIndex may actually be ahead of the voting leader's log. We don't currently handle this case b/c the non-voting semantics deviate a bit from raft, which doesn't allow a node to become leader if it's log is older than another node. |
| Comment by Tom Pantelis [ 18/Jul/16 ] |
|
Be: https://git.opendaylight.org/gerrit/#/c/41323/ |