RabbitMQ——镜像队列Master故障后的处理

默认情况下,镜像队列的master出现故障时,最老的mirror会被提升为新的master。如果新提升为master的这个mirror与原有的master并未完成数据的同步,那么就会出现数据的丢失,而实际应用中,出现数据丢失可能会导致出现严重后果。

rabbitmq提供了ha-promote-on-shutdown,ha-promote-on-failure两个参数让用户决策是保证队列的可用性,还是保证队列的一致性;两个参数分别控制正常关闭、异常故障情况下mirror是否提升为master,其可设置的值为"when-synced"和"always"。

when-synced意味只有当mirror与master完成数据同步了,才会被提升master;而always则意味着,无论什么情况mirror都将被提升为master。

实际测试情况如下表所示:

RabbitMQ——镜像队列Master故障后的处理

这里要注意的是ha-promote-on-failure设置为always,插拔网线模拟网络异常的两个测试场景:当网络恢复后,其中一个会重新变为mirror,具体是哪个变为mirror,受cluster_partition_handling处理策略的影响。

例如两台节点A,B组成集群,并且cluster_partition_handling设置为autoheal,队列的master位于节点A上,具有全量数据,mirror位于节点B上,并且还未完成消息的同步,此时出现网络异常,网络异常后两个节点交互决策:如果节点A节点成为赢家,此时B节点内部会重启,这样数据全部保留不会丢失;相反如果B节点成为赢家,A需要重启,那么由于ha-prromote-on-failure设置为always,B节点上的mirror提升为master,这样就出现了数据丢失。

总结:

如同CAP理论只能满足其中两个,如果选择AP,即保证队列的可用性,可将两个参数均设置为"always",如果选择CP,即保证队列消息的一致性,可将两个参数均设置为"when-synced"。