Validate short-term solution for arbiter node.

Here's how it could work with current MaxScale 25.10 (and likely older versions as well).

DC1: server1, mxs1 DC2: server2, mxs2 DC3: server3 (arbiter)

MaxScales are configured as follows:
[RWS-Service]
type=service
router=readwritesplit
servers=server1,server2
<other settings>

[MyMonitor]
type=monitor
module=mariadbmon
servers=server1,server2,server3
servers_no_promotion=server3
auto_failover=yes
auto_rejoin=yes
cooperative_monitoring_locks=majority_of_all
enforce_read_only_servers=1 (not essential but generally a good idea)
<other settings>

[server1]
type=server
<other settings>

[server2]
type=server
<other settings>

[server3]
type=server
monitoruser=basic (Needs to be able to log in, but that's it. If this causes issues, can always give more privs)
monitorpw=basic

Server3 should not have replication connections, and it should not have a gtid_current_pos. This means that both gtid_binlog_pos and gtid_slave_pos must be empty. An empty gtid_current_pos stops the monitor from trying to rejoin server3. A failed rejoin attempt would lead to an error at which point the monitor refuses to do any further cluster operations like failover, even if one is required. This can be achieved by running "reset master" and "set global gtid_slave_pos='' " on server3. If successful, "select @@gtid_current_pos,@@gtid_binlog_pos,@@gtid_slave_pos;" results in only empty strings.

If using enforce_read_only_servers or enforce_read_only_slaves, server3 should be configured to always be in read_only mode (read-only=1 in my.cnf or similar).

Tested this with just one MaxScale, but it should work with multiple MaxScales just the same. This setup is still fragile in the sense that if the arbiter goes down, failover will no longer work as 2/3 servers would be down.