我将ha代理设置为一个负载平衡器，并在主/主+从复制上进行故障切换。我有两个xinetdbash脚本监听端口9200和9201。端口9200处的一个检查主机状态，端口9201处的一个检查从机状态及其在主机后面的位置。
我的ha代理配置文件如下所示：

global
    log 127.0.0.1 local0 notice

defaults
    log global
    retries 2
    timeout connect 10000
    timeout server 28800000
    timeout client 28800000

// writes and critical reads goes here
// critical reads are the ones we can't afford any latency at all
listen mariadb-writes
    bind 0.0.0.0:3307
    mode tcp
    option allbackups
    option httpchk
    balance roundrobin

    // 9200 check master status
    server mariadb1 1.1.1.1:3306 check port 9200 // master1
    server mariadb2 2.2.2.2:3306 check port 9200 backup // master2

// heavy reads that we can afford some latency
listen mariadb-reads
    bind 0.0.0.0:3308
    mode tcp
    option allbackups
    option httpchk
    balance roundrobin

    // 9201 check slave status and seconds behind
    server mariadb1 1.1.1.1:3306 check port 9201
    server mariadb2 2.2.2.2:3306 check port 9201
    server mariadb3 3.3.3.3:3306 check port 9201

    // 9200 on backups check the master status
    server mariadb1b 1.1.1.1:3306 check port 9200 backup
    server mariadb2b 2.2.2.2:3306 check port 9200 backup

我使用两个脚本的原因是，这是我发现的解决复制中断问题的唯一方法，但它也会产生一个新问题。我选择执行两个不同的脚本，因为检查主-主复制上的从属状态可能会在另一个主复制失败时停用其中一个主复制，因为这样会破坏复制。因此，在我的主节点上，我没有检查从节点的状态，而是直接写入其中一个节点，如果它启动了，就继续写入。如果由于某种原因我的主服务器宕机了，主备份将保留请求。
我看到的问题是，如果master1停止运行，master2将接收写操作，并且取决于它停止运行的时间，当它停止运行时，复制将远远落后，激活它将导致严重的数据一致性问题，直到复制被捕获为止。
我在考虑在9200主脚本中做两个检查，一个检查从机状态，如果它启动，检查它落后多少秒，但是如果从机关闭，检查主机状态。换句话说，不要返回503以防从机损坏，因为它可能是第二个主机发生故障并破坏复制。但这也有一些缺陷，因为当master1启动时，复制将被中断，直到mariadb重新连接到另一个master2，所以在这段时间内写操作无法定向到该节点。我可以将ha代理配置为在激活关闭的节点之前等待几秒钟，但对我来说这似乎不是合适的解决方案。
基本上，我正在试图弄清楚，如果我的master1启动，ha代理将请求转发给它，而它正在赶上从master2复制数据的停机时间，如何管理连接。有人知道解决这个问题的更好方法吗？