rabbitmq链接超时_网络故障后RabbitMQ集群未重新连接

There are several occasions when Mnesia may detect that the network

has been partitioned due to a communication failure.

One is when Mnesia already is up and running and the Erlang nodes gain

contact again. Then Mnesia will try to contact Mnesia on the other

node to see if it also thinks that the network has been partitioned

for a while. If Mnesia on both nodes has logged mnesia_down entries

from each other, Mnesia generates a system event, called

{inconsistent_database, running_partitioned_network, Node} which is

sent to Mnesia's event handler and other possible subscribers. The

default event handler reports an error to the error logger.

Another occasion when Mnesia may detect that the network has been

partitioned due to a communication failure, is at start-up. If Mnesia

detects that both the local node and another node received mnesia_down

from each other it generates a {inconsistent_database,

starting_partitioned_network, Node} system event and acts as described

above.

If the application detects that there has been a communication failure

which may have caused an inconsistent database, it may use the

function mnesia:set_master_nodes(Tab, Nodes) to pinpoint from which

nodes each table may be loaded.

At start-up Mnesia's normal table load algorithm will be bypassed and

the table will be loaded from one of the master nodes defined for the

table, regardless of potential mnesia_down entries in the log. The

Nodes may only contain nodes where the table has a replica and if it

is empty, the master node recovery mechanism for the particular table

will be reset and the normal load mechanism will be used when next

restarting.

The function mnesia:set_master_nodes(Nodes) sets master nodes for all

tables. For each table it will determine its replica nodes and invoke

mnesia:set_master_nodes(Tab, TabNodes) with those replica nodes that

are included in the Nodes list (i.e. TabNodes is the intersection of

Nodes and the replica nodes of the table). If the intersection is

empty the master node recovery mechanism for the particular table will

be reset and the normal load mechanism will be used at next restart.

The functions mnesia:system_info(master_node_tables) and

mnesia:table_info(Tab, master_nodes) may be used to obtain information

about the potential master nodes.

Determining which data to keep after communication failure is outside

the scope of Mnesia. One approach would be to determine which "island"

contains a majority of the nodes. Using the {majority,true} option for

critical tables can be a way of ensuring that nodes that are not part

of a "majority island" are not able to update those tables. Note that

this constitutes a reduction in service on the minority nodes. This

would be a tradeoff in favour of higher consistency guarantees.

The function mnesia:force_load_table(Tab) may be used to force load

the table regardless of which table load mechanism is activated.