温州网站升级,重庆营销型网站随做的好处,无锡建网站价格,wordpress 手动摘要今有运维同学反应#xff0c;某业务主从复制#xff08;一主两从#xff09;延迟较大#xff1b;MySQL master#xff1a;5.0.82 Slave#xff1a;5.0.88首先指出DB的数据量还是几十G的大小#xff0c;网络没有问题#xff0c;OS系统负载小#xff0c;IO没有吃紧某业务主从复制一主两从延迟较大 MySQL master5.0.82 Slave5.0.88 首先指出DB的数据量还是几十G的大小网络没有问题OS系统负载小IO没有吃紧 现象1、slave A 出现relay_log 产生上千个且大小均为几KB错误日志中无其他错误显示 现象2、slave B show slave status\G 显示正常但error log 产生上G的错误文件报错信息为slave io error 无法读取master binlog 重启slave B 无法解决 停止slave A复制slaveB 不在产生错误日志Aserver的错误信息 记录在B server上 以上现象根本找不到线索更不要说去监控是不是锁问题原因导致主从复制延迟大 唯一能看的还是看 slave A 、slave B的 server_id 两者的server_id 竟然一样 从此公司的DB安装部分也由运维转移到的DBA这边。。。 转载于:https://blog.51cto.com/weipengfei/1208792
