![MySQL 复制过期](https://linux22.com/image/804192/MySQL%20%E5%A4%8D%E5%88%B6%E8%BF%87%E6%9C%9F.png)
我在使用 Maria DB 时遇到了一些有趣的问题。
首先,我在 [mysqld] 部分下的配置中设置了 max_connections,但重启后该值始终为 214(默认值)。所以问题是我无法在配置中定义该值(服务器版本 5.5.32-MariaDB-log)
第二个与 mysql 复制直接相关:因此我有简单的复制设置主 - 从主 mysql 5.1.62-0ubuntu0.11.10.1-log 从 5.5.32-MariaDB-log
所以我第二次遇到这个问题,我不知道如何调试这个问题,也不知道是什么原因造成的
Exec_Master_Log_Pos: 101702714
Relay_Log_Space: 1591329
因此,在我运行 show slave status; 之后,它显示了上述值,并且比主服务器少 0,大约 2 - 3 分钟后,我再次运行 show slave status; ,结果仍然是相同的值,并且比主服务器少 0。我检查了其他两个从服务器是否正常工作。此外,服务器 ID 没有问题,每个服务器都有不同的 ID。所以大家有什么想法吗?
谢谢
答案1
好的,我找到了第一个问题的答案:打开文件的限制存在问题,因此为了解决该问题,我将这些值添加到了 my.cnf 中
max-connections = 950
open-files-limit = 65535
谢谢
好的,我也解决了第二个问题。一般来说,复制的 IO 线程存在问题。由于某些网络问题或网络延迟。
简而言之,所有情况都是这样的,从服务器连接到主服务器,主服务器将 binlog 事件发送到从服务器。由于这些数据是从主服务器推送的,而不是从服务器拉取的,因此复制通道可能会中断。因此,从服务器直到发生 slave_net_timeout(默认值为 3600)才会注意到。问题开始于 21:50 左右,由自己在 22:50 左右修复。(查看二进制/中继日志图)。就我而言。此外,当我运行 processlist 并搜索负责复制的进程(例如用户“repl”)时,您会发现
290659 repl hostname:56896 NULL Binlog Dump 1215563 Has sent all binlog to slave; waiting for binlog to be updated NULL
这类信息意味着系统是健康的,在非健康系统中,我们应该看到
"Writing to net NULL"
我看到了那些东西。我还发现,大约在那个时候,我们在主数据库上出现了“close_waits”,这可能表明复制通道已损坏。mysql 有一个称为slave_compressed_protocol(默认关闭)的参数。
因此,将这些默认值更改为 120 秒并启用压缩后,除非网络存在更大的问题,否则我不会看到这些问题。
通过改变
master-retry-count=0
你的从属设备将继续尝试重新连接到主设备,直到成功