HA 代理负载平衡 + MySQL 主/主复制问题答案

【问题标题】：HA Proxy load balance + MySQL master/master replication issueHA 代理负载平衡 + MySQL 主/主复制问题
【发布时间】：2018-05-29 15:09:06
【问题描述】：

我正在将 HA 代理设置为负载平衡器，并在主/主 + 从复制上进行故障转移。我有两个 xinetd bash 脚本侦听端口 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

我使用两个脚本的原因是因为这是我发现解决复制问题的唯一方法，但它也产生了一个新问题。我选择执行两个不同的脚本，因为检查我的主-主复制上的从属状态可能会在另一个主节点出现故障时停用其中一个主节点，因为它会破坏复制。因此，我没有检查从属状态，而是在我的主节点上写入其中一个节点并在它启动时继续写入它。如果由于某种原因我的 master 宕机了，master backup 将保留请求。

我看到的问题是，如果 master1 出现故障，master2 将接收写入，并且取决于它停留多长时间，当它上升时，复制将远远落后，激活它会导致严重的数据一致性问题，直到复制被赶上。

我正在考虑在 9200 主脚本中进行两次检查，一次将检查从属状态，如果它启动，则检查它落后了多少秒，但如果从属关闭，则检查主状态。换句话说，如果从服务器损坏，请不要返回 503，因为它可能是第二个主服务器宕机并破坏了复制。但这也有一些缺陷，因为当 master1 启动时，复制将被破坏，直到 MariaDB 重新连接到另一个 master2，因此在此期间无法将写入定向到该节点。我可以将 HA 代理配置为在激活已关闭的节点之前等待几秒钟，但这对我来说似乎不是正确的解决方案。

基本上，如果我的 master1 启动并且 HA 代理将请求转发给它，同时它正在赶上从 master2 复制数据的停机时间，我基本上试图弄清楚如何管理连接。有谁知道解决这个问题的更好方法？

【问题讨论】：

标签： mysql mariadb replication haproxy

【解决方案1】：

（此答案没有解决您提出的监控问题；而是快进到下一步 - 修复复制速度减慢。）

您有多线程复制吗？如果是这样，您设置了哪些参数？（过高可能和过低一样糟糕。）
您是否在从站中打开了慢日志？ long_query_time 和 log_slow_slave_statements = ON 的值较低？
最慢的查询是什么？让我们看看他们，加上SHOW CREATE TABLE 和EXPLAIN SELECT ...。

也就是说，加速从站上的SELECTs，或复制到从站的写入，可能会“消除”问题。

【讨论】：