rabbit_maintenance: Replicate rabbit_node_maintenance_states Mnesia table
#9005
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dumbbell
force-pushed
the
replicate-rabbit_node_maintenance_states-table
branch
2 times, most recently
from
6ba5596
to
31d8bfe
Compare
… table
[Why]
So far, the code only ensured the table existed. Because it is a
non-local Mnesia table, its presence on a single node was enough. This
is not what we want here: we want the table to be replicated to all
nodes across the cluster.
This was detected while working on the integration of Khepri. In our
work in progress, the Mnesia table was declared differently and
replicated. This caused mixed-version testing to fail because nodes were
hanging forever while trying to force-load that Mnesia table. The hang
was explained by the fact that the node having that single table copy
was stopped or restarted and thus was unavailable, preventing the load
of the table.
[How]
After the table is declare, we use `rabbit_table:ensure_table_copy/3` to
make sure the table is replicated to the local node. Because all nodes
call that boot step, each of them takes care of configuring its copy. In
the end, the table is replicated everywhere.
V2: We also try to add replicas on remote nodes that don't have one yet.
This reduces the risk of having a node waiting forever that the
table becomes available on another node. Failures to add remote
replicas are ignored as they should not be fatal and prevent the
current node from starting.
dumbbell
force-pushed
the
replicate-rabbit_node_maintenance_states-table
branch
from
31d8bfe
to
b82ff37
Compare
dumbbell
added a commit
that referenced
this pull request
Aug 7, 2023
…plicated See #9005 for an explanation of the bug.
acogoluegnes
added a commit
that referenced
this pull request
Apr 25, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. References #9005
acogoluegnes
added a commit
that referenced
this pull request
Apr 25, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. References #9005
mergify bot
pushed a commit
that referenced
this pull request
Apr 25, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. References #9005 (cherry picked from commit df9fec8)
mergify bot
pushed a commit
that referenced
this pull request
Apr 25, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. References #9005 (cherry picked from commit df9fec8)
mergify bot
pushed a commit
that referenced
this pull request
Apr 25, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. References #9005 (cherry picked from commit df9fec8) # Conflicts: # deps/rabbitmq_jms_topic_exchange/src/rabbit_db_jms_exchange.erl
This was referenced Apr 25, 2024
acogoluegnes
added a commit
that referenced
this pull request
Apr 26, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. Inspired by a similar change for the node maintenance status table in #9005.
acogoluegnes
added a commit
that referenced
this pull request
Apr 26, 2024
The x_jms_topic_table Mnesia table must be on all nodes for messages to be published to JMS topic exchanges and routed to topic subscribers. The table used to be only in RAM on one node, so it would be unavailable when the node was down and empty when it came back up, losing the state for subscribers still online because connected to other nodes. Inspired by a similar change for the node maintenance status table in #9005.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
So far, the code only ensured the table existed. Because it is a non-local Mnesia table, its presence on a single node was enough. This is not what we want here: we want the table to be replicated to all nodes across the cluster.
This was detected while working on the integration of Khepri. In our work in progress, the Mnesia table was declared differently and replicated. This caused mixed-version testing to fail because nodes were hanging forever while trying to force-load that Mnesia table. The hang was explained by the fact that the node having that single table copy was stopped or restarted and thus was unavailable, preventing the load of the table.
How
After the table is declared, we use
rabbit_table:ensure_table_copy/3to make sure the table is replicated to the local node. Because all nodes call that boot step, each of them takes care of configuring its copy. In the end, the table is replicated everywhere.We also try to add replicas on remote nodes that don't have one yet. This reduces the risk of having a node waiting forever that the table becomes available on another node. Failures to add remote replicas are ignored as they should not be fatal and prevent the current node from starting.