Galera garbd terminated: Group requested gcs_proto_ver: 2, max supported by this node: 0

Written by - 0 comments

Published on - Listed in Galera Database MariaDB


After upgrading data nodes of a Galera cluster from MariaDB 10.3 to 10.4 and from Galera-3 to Galera-4, an Arbitrator server was unable to sync with the cluster.

The garbd log file showed the following error:

2023-05-31 15:21:44.101  INFO: Quorum results:
    version    = 6,
    component  = PRIMARY,
    conf_id    = 6,
    members    = 2/3 (joined/total),
    act_id     = 149331040,
    last_appl. = -1,
    protocols  = 2/10/4 (gcs/repl/appl),
    group UUID = 605a037b-6d84-11e8-a172-8ff5dbd1c9b3
2023-05-31 15:21:44.101 FATAL: /home/buildbot/buildbot/build/gcs/src/gcs_group.cpp:group_check_proto_ver():258: Group requested gcs_proto_ver: 2, max supported by this node: 0.Upgrade the node before joining this group.Need to abort.
2023-05-31 15:21:44.101  INFO: /usr/bin/garbd: Terminated.
2023-05-31 15:23:15.094  INFO: CRC-32C: using 64-bit x86 acceleration.

Although the fatal error could be more helpful, it gives a hint about a protocol version mismatch.

By looking at the currently installed packages on the Arbitrator server, we can still find the older version galera-3:

root@arbitrator:~# dpkg -l|grep galera
ii  galera-3              25.3.37-bionic     amd64        Replication framework for transactional applications
ii  galera-arbitrator-3   25.3.37-bionic     amd64        Galera arbitrator daemon

However, as mentioned above, the data nodes were upgraded to use the newer galera-4. Although the Arbitrator server is not a data node and does not actually sync data, the same version must be used as other nodes in the cluster.

Installation of galera-4:

root@arbitrator:~# apt-get install galera-4 galera-arbitrator-4

Followed by a restart (using garbd process launched by /etc/rc.local):

root@arbitrator:~# cat /etc/rc.local
#!/bin/bash
/usr/bin/garbd --cfg /etc/garbd.conf &
exit 0

root@arbitrator:~# systemctl restart rc-local

And the garbd process started and synced successfully with the Galera cluster:

root@arbitrator:~# tail -f /var/log/garbd.log
2023-05-31 15:25:46.282  INFO: Sending state transfer request: 'trivial', size: 7
2023-05-31 15:25:46.285  INFO: Member 2.0 (garb) requested state transfer from '*any*'. Selected 0.0 (mysql01)(SYNCED) as donor.
2023-05-31 15:25:46.285  INFO: Shifting PRIMARY -> JOINER (TO: 149331740)
2023-05-31 15:25:46.287  INFO: 2.0 (garb): State transfer from 0.0 (mysql01) complete.
2023-05-31 15:25:46.287  INFO: Shifting JOINER -> JOINED (TO: 149331740)
2023-05-31 15:25:46.288  INFO: Member 2.0 (garb) synced with group.
2023-05-31 15:25:46.288  INFO: Shifting JOINED -> SYNCED (TO: 149331740)
2023-05-31 15:25:46.302  INFO: 0.0 (mysql01): State transfer to 2.0 (garb) complete.
2023-05-31 15:25:46.304  INFO: Member 0.0 (mysql01) synced with group.
2023-05-31 15:25:49.281  INFO: (92928494, 'tcp://0.0.0.0:4567') turning message relay requesting off



Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   OpenSearch   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder