Blame SOURCES/bz1656492-1-totem-Increase-ring_id-seq-after-load.patch

8690b7
From 1061804d09565363aba73e369faf310a7d2c4d86 Mon Sep 17 00:00:00 2001
8690b7
From: Jan Friesse <jfriesse@redhat.com>
8690b7
Date: Mon, 15 Jul 2019 14:08:39 +0200
8690b7
Subject: [PATCH] totem: Increase ring_id seq after load
8690b7
8690b7
This patch handles the situation where the leader
8690b7
node (the node with lowest node_id) crashes and is started again
8690b7
before token timeout of the rest of the cluster.
8690b7
The newly restarted node restores the ringid of the old ring from
8690b7
stable storage, so it has the same ringid as rest of the nodes,
8690b7
but ARU is zero. If the node is able to create a singleton membership
8690b7
before receiving the joinlist from rest of the cluster,
8690b7
everything works as expected, because the ring id gets increased
8690b7
correctly.
8690b7
8690b7
But if the node receives a joinlist from another cluster node before
8690b7
its own joinlist, then it continues as it would had it never left
8690b7
the cluster. This is not correct, because the new node should always
8690b7
create a singleton configuration first.
8690b7
8690b7
During the recovery phase, ARUs are compared and because they differ
8690b7
(the ARU of the old leader node is 0), the other nodes
8690b7
try to sent all of their previous messages. This is impossible
8690b7
(even if it was correct), because other nodes have already freed most
8690b7
of those messages. The implementation uses an assert to limit maximum
8690b7
number of messages sent during recovery (we could fix this,
8690b7
but it's not really the point).
8690b7
8690b7
The solution here is to increase the ring_id sequence number by 1 after
8690b7
loading it from storage. During creation of the commit token it is
8690b7
always increased by 4, so it will not collide with an existing
8690b7
sequence.
8690b7
8690b7
Thanks Christine Caulfield <ccaulfie@redhat.com> for clarify commit
8690b7
message.
8690b7
8690b7
Signed-off-by: Jan Friesse <jfriesse@redhat.com>
8690b7
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>
8690b7
---
8690b7
 exec/totemsrp.c | 8 ++++++++
8690b7
 1 file changed, 8 insertions(+)
8690b7
8690b7
diff --git a/exec/totemsrp.c b/exec/totemsrp.c
8690b7
index 0410ed9..c07bd43 100644
8690b7
--- a/exec/totemsrp.c
8690b7
+++ b/exec/totemsrp.c
8690b7
@@ -5094,6 +5094,14 @@ void main_iface_change_fn (
8690b7
 	if (instance->iface_changes++ == 0) {
8690b7
 		instance->memb_ring_id_create_or_load (&instance->my_ring_id,
8690b7
 		    &instance->my_id.addr[0]);
8690b7
+		/*
8690b7
+		 * Increase the ring_id sequence number. This doesn't follow specification.
8690b7
+		 * Solves problem with restarted leader node (node with lowest nodeid) before
8690b7
+		 * rest of the cluster forms new membership and guarantees unique ring_id for
8690b7
+		 * new singleton configuration.
8690b7
+		 */
8690b7
+		instance->my_ring_id.seq++;
8690b7
+
8690b7
 		instance->token_ring_id_seq = instance->my_ring_id.seq;
8690b7
 		log_printf (
8690b7
 			instance->totemsrp_log_level_debug,
8690b7
-- 
8690b7
1.8.3.1
8690b7