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
No comments yet.
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 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