mariadb galera :会员数量在5到3之间不断变化。

Question

我有一个5节点的集群，每个DC有2个节点，在第3个DC上有一个仲裁器。

集群运行良好，因为数据是同步的，DBs没有任何错误。网络也很好。

然而，在日志中，galera显示成员每隔几个小时离开并重新加入集群。同样的行为也被观察到了，最好不要再坚持下去了。

2022-10-10 11:33:39 2 [Note] WSREP: Non-primary view
2022-10-10 11:33:39 2 [Note] WSREP: Server status change synced -> connected
2022-10-10 11:33:39 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2022-10-10 11:33:39 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2022-10-10 11:33:39 0 [Note] WSREP: view(view_id(NON_PRIM,599bc3d2-b9fe,13720) memb {
        599bc3d2-b9fe,0
} joined {
} left {
} partitioned {
        37d9a4cb-997b,0
        47b6cf8d-9d2a,0
        5de8a52e-aa58,0
        d5464472-acc7,0
})
2022-10-10 11:33:39 0 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
2022-10-10 11:33:39 0 [Note] WSREP: Flow-control interval: [16, 16]
2022-10-10 11:33:39 0 [Note] WSREP: Received NON-PRIMARY.
2022-10-10 11:33:39 2 [Note] WSREP: ================================================
View:
  id: 2e8c4b3d-3d2c-11e9-ba33-9f9156834d83:50217575
  status: non-primary
  protocol_version: 4
  capabilities: MULTI-MASTER, CERTIFICATION, PARALLEL_APPLYING, REPLAY, ISOLATION, PAUSE, CAUSAL_READ, INCREMENTAL_WS, UNORDERED, PREORDERE
D, STREAMING, NBO
  final: no
  own_index: 0
  members(1):
        0: 599bc3d2-444c-11ed-b9fe-93ddbbf65238, p1mariadb1a
=================================================
2022-10-10 11:33:39 2 [Note] WSREP: Non-primary view
2022-10-10 11:33:39 2 [Note] WSREP: Server status change connected -> connected

5节点聚集在一起

2022-10-10 11:33:40 0 [Note] WSREP: re-bootstrapping prim from partitioned components
2022-10-10 11:33:40 0 [Note] WSREP: view(view_id(PRIM,37d9a4cb-997b,13721) memb {
        37d9a4cb-997b,0
        47b6cf8d-9d2a,0
        599bc3d2-b9fe,0
        5de8a52e-aa58,0
        d5464472-acc7,0
} joined {
} left {
} partitioned {
})

2022-10-10 11:33:40 警告 WSREP:仲裁:无完全状态的节点：.

集群再次确定：

2022-10-10 11:33:40 0 [Note] WSREP: Full re-merge of primary xx found: 5 of 5.
2022-10-10 11:33:40 0 [Note] WSREP: Quorum results:
        version    = 6,
        component  = PRIMARY,
        conf_id    = 7760,
        members    = 5/5 (joined/total),

sudo "members =“/var/log/mysql/error.log-202210*

/var/log/mysql/error.log-20221009.gz:   members    = 4/4 (joined/total),
/var/log/mysql/error.log-20221009.gz:   members    = 4/5 (joined/total),
/var/log/mysql/error.log-20221011.gz:   members    = 5/5 (joined/total),
/var/log/mysql/error.log-20221011.gz:   members    = 5/5 (joined/total),
/var/log/mysql/error.log-20221011.gz:   members    = 3/5 (joined/total),

显示variable_name中的状态(“wsrep_群集_size”、“wsrep_群集_ status”、“wsrep_control_paused”、“wsrep”、“wsrep_paused”、“wsrep_local_state_comment”)中的状态；

| Variable_name             | Value      |
| wsrep_flow_control_paused | 0.00954013 |
| wsrep_local_state_comment | Synced     |
| wsrep_cluster_size        | 5          |
| wsrep_cluster_status      | Primary    |
| wsrep_connected           | ON         |
| wsrep_ready               | ON         |

Answer 1

我认为"gmcast.peer_timeout PT3S“是关键的场景，在过去的两周里，这使事情平静下来。它也需要为仲裁者设定。

片段=1/2/3现在也为每个站点设置，这可能也有帮助。

不相信触摸evs.suspect_timeout或evs.inactive_timeout是个好主意。捐献者只用于最初的状态转移，所以除了避免交通用地的主要主人之外，我建议不要碰。