mysql 主备复制停止问题定位以及状态监控

本文介绍了一种常见的MySQL主从复制故障场景,详细解释了如何通过日志定位问题原因,修复函数创建失败的错误,并提供了在主库上重新定位从库同步位置的方法。此外,还分享了一个用于监控从库状态的Python脚本,确保线上环境的稳定运行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1 主备复制停止定位

配置好主从复制后,没有进行主备复制。通过日志查看,发现从库在同步的时候跑错了。
在从库上查看日志:

vim /var/log/mysqld.log

提示error信息是函数创建失败,缺少DETERMINISTIC。并给出了修改建议:

Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000003' position 25395

在这里插入图片描述
查看slave的状态:

show slave status\G;

返回结果中明确表示,slave sql不再运行。其中的错误提示,和log中看到的一致。
在这里插入图片描述

2 计划修复的方案

越过此条log,继续之后的执行。
在主库的机器上,查看主库的log:

show binlog events IN 'mysql-bin.000003' FROM 54911 LIMIT 50;#需要指定哪个文件(上面的log中有),起始position(依旧在上面的log中)

结果:
在这里插入图片描述
从log看到,下一条的position是多少。
在从库中重新定位同步的起始位置,position就是上面找到的信息。

stop slave;
change master to master_log_file='mysql-bin.000003',master_log_pos=47245;
start slave;

查看状态,确认启动同步成功:

show slave status\G;

在这里插入图片描述

3 线上监控脚本

如果是线上环境,需要监控slave库的状态,及时告警。这里写了一个python的脚本,很简陋。
安装python:我的环境还有py2,所以这里指定的名字中都带“3”

yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gcc make
wget https://www.python.org/ftp/python/3.6.2/Python-3.6.2.tar.xz
tar -xvJf  Python-3.6.2.tar.xz
./configure prefix=/usr/local/python3
make && make install
ln -s /usr/local/python3/bin/python3 /usr/bin/python3
export PATH=$PATH:/usr/local/python3/bin

安装setuptools:

wget https://pypi.python.org/packages/source/s/setuptools/setuptools.zip --no-check-certificate
unzip setuptools.zip
cd setuptools
python3 setup.py build
python3 setup.py install

安装pip:

wget wget https://pypi.python.org/packages/source/p/pip/pip.tar.gz
tar xvf pip.tar.gz
cd pip
python3 setup.py install

注意:各个软件的版本下载最新的就好
安装python的依赖包:

pip install PyMySQL
pip install schedule

监控脚本分为三个文件,一个main以及mysql监控和发送邮件:

发送邮件
'''
Created on 2018-3-21

@author: yunzhong
'''

import smtplib
from email.mime.text import MIMEText
from email.header import Header

class MailSender(object):
    '''
    classdocs
    '''
    mailHost="smtp.exmail.qq.com"
    mailPort=465
    mailProtocol="smtp"
    mailUsername="service@mail.cn"
    mailPassword="mail"
    receivers = ['wangyunzhong@mail.cn']

    def __init__(self):
        '''
        Constructor
        '''
    
    def sendEmail(self, headFrom, headTo, subject,content):
        message = MIMEText(content, 'plain', 'utf-8')
        message['From'] = Header(headFrom, 'utf-8')
        message['To'] =  Header(headTo, 'utf-8')
        
        subject = subject
        message['Subject'] = Header(subject, 'utf-8')
        
        
        try:
            smtpObj = smtplib.SMTP_SSL()
            smtpObj.connect(self.mailHost, self.mailPort)
            smtpObj.login(self.mailUsername,self.mailPassword)
            smtpObj.sendmail(self.mailUsername, self.receivers, message.as_string())
            print ("错误,发送电子邮件")
        except smtplib.SMTPException as err:
            print ("Error: 不能发送邮件",err)
mysql监控
'''
Created on 2018-3-21

@author: yunzhong
'''
import pymysql

class MysqlMonitor(object):
    '''
    classdocs
    '''
    mysqlHost = 'host.com'
    user = 'user'
    password = 'root+-*/'
    database = ''
   
    def monitor(self):
        db = pymysql.connect(self.mysqlHost,self.user,self.password,self.database )
        cursor = db.cursor()
        cursor.execute("SHOW SLAVE STATUS")
        results = cursor.fetchall()
        print(results)
        slaveIO = 0
        slaveSql = 0
        for result in results:
            print("host:",result[1])
            print("host:",result[5])
            print("host:",result[10])
            print("host:",result[11])
            if result[10].lower() == 'no' :
                slaveIO = 1
            if result[11].lower() == 'no':
                slaveSql = 10
        db.close()
        return slaveIO + slaveSql
main文件
'''
Created on 2018-3-21

@author: yunzhong
'''
import schedule
import time
from mysqlMonitor import MysqlMonitor
from mailSender import MailSender

if __name__ == '__main__':
    pass

def mo():
    print(time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time())),"开始获取数据库slave信息")
    monitor = MysqlMonitor()
    mResult = monitor.monitor()
    print(time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time())),"数据库slave监控信息",mResult)
    if mResult == 1:
        sender = MailSender()
        sender.sendEmail('mysql告警邮件', '管理员', '数据库同步监控', '主从数据库运行异常,请核查。数据库slave IO异常')
    elif mResult == 10:
        sender = MailSender()
        sender.sendEmail('mysql告警邮件', '管理员', '数据库同步监控', '主从数据库运行异常,请核查。数据库slave SQL异常')
    elif mResult > 0:
        sender = MailSender()
        sender.sendEmail('mysql告警邮件', '管理员', '数据库同步监控', '主从数据库运行异常,请核查。数据库slave SQL异常')
    else:
        print(time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time())),"数据库slave运行正常")

try:
    print(time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time())),"数据库slave监控程序开始执行")
    schedule.every(1).minutes.do(mo)
except BaseException as err:
    print ("Error: 不能发送邮件",err)
while True:
    try:
        schedule.run_pending()
        time.sleep(1)
    except BaseException as err:
        print ("Error: 不能发送邮件",err)

python脚本启动命令:-u参数,是为了print无缓存,直接输出到console

nohup python3 -u monitor.py > ./monitor.log 2>&1 &
<think>嗯,用户的问题是关于MySQL失效的解决方案。首先需要梳理用户提供的线索——虽然用户引用了"索引失效"的材料(引用1和2),但实际需求是主备复制失效的解决方案。这两个题属于不同技术范畴,可能是用户混淆了术语。先确认失效的常见类型:用户可能遇到从同步延迟、复制完全中断、数据不一致等问题。解决方案需要分层处理:首先检查基础状态。要确认复制线程是否运行(SHOWSLAVESTATUS),验证IO_THREAD和SQL_THREAD状态。如果Slave_IO_Running或Slave_SQL_Running显示No,说明复制已停止。此时需查看Last_IO_Error/Last_SQL_Error字段定位错误源。针对典型错误场景:-网络连接问题会导致IO线程中断,需要用telnet测试库3306端口连通性,同时检查防火墙规则-常见错误如键冲突:如果库插入重复数据会使SQL线程停止。这时要人工选择保留数据(跳过错误或删除冲突行),再用SQL_SLAVE_SKIP_COUNTER跳过错误事务-数据不一致的情况,需重建库:在库用mysqldump导出数据,在库重新初始化-大事务引起的同步延迟需要拆分事务,或调整innodb_flush_log_at_trx_commit参数减轻IO压力-binlog损坏时要重启库复制:清除库relaylog,重新changemaster指定新binlog位置预防措施方面:定期监控Seconds_Behind_Master值设置报警,配置时间同步避免timestamp冲突,升级到基于GTID的复制提高容错性。注意到用户引用的索引失效材料(涉及隐式类型转换和联合索引范围查询)并不适用当前场景,但可以在相关问题中补充这个知识点作为延伸。最后生成的问题要涵盖主备复制监控、切换机制等扩展方向。</think> MySQL主备复制失效是严重的高可用故障,以下是常见原因及解决方案,请根据具体场景排查: ### 一、复制中断核心解决方案 1. **检查复制状态** ```sql SHOW SLAVE STATUS\G ``` 关注以下关键字段: - `Slave_IO_Running`/`Slave_SQL_Running`:若为`No`则线程停止 - `Last_IO_Error`/`Last_SQL_Error`:定位具体错误(如键冲突、权限问题) - `Seconds_Behind_Master`:大于0表示延迟 2. **自动修复流程** ```sql STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; -- 跳过1个错误事件 START SLAVE; ``` ### 二、高频故障场景及处理 | 故障类型 | 现象特征 | 解决方案 | |---------------------------|------------------------------|--------------------------------------------------------------------------| | **数据冲突** | 1062键重复/1032行不存在 | ```SET GLOBAL read_only=ON; ``` 暂停库写入<br>```pt-table-checksum```校验数据一致性 | | **网络中断** | `Last_IO_Error: Reconnecting` | 检查防火墙端口(3306)<br>库执行`SHOW MASTER STATUS`核对binlog位置 | | **大事务阻塞** | `Seconds_Behind_Master`飙升 | 库拆分事务:```split -l 1000 big_transaction.sql```<br>库调整```slave_parallel_workers``` | | **版本不兼容** | `Unsupported event type` | 版本需兼容()<br>升级方案:库先升级 -> 切换 -> 原升级 | | **磁盘空间不足** | `No space left on device` | 清理relay log:```PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;``` | ### 三、高可用架构强化方案 1. **GTID模式**(推荐) ```ini [mysqld] gtid_mode=ON enforce_gtid_consistency=ON ``` - 优点:自动故障定位,无需binlog文件名/位置 - 切换命令:```CHANGE MASTER TO MASTER_AUTO_POSITION=1;``` 2. **半同步复制** ```sql INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; SET GLOBAL rpl_semi_sync_master_enabled=1; ``` 3. **监控体系** 必监控项: - 复制延迟:`SHOW SLAVE STATUS` - 线程状态:`SELECT * FROM performance_schema.replication_applier_status` - 自动告警工具:Percona Monitoring and Management (PMM) > **重要原则**:失效后**切勿直接修改库数据**,需通过库同步。如遇无法跳过的错误,建议重建库: > ```shell > mysqldump --single-transaction --master-data=2 -h库IP | mysql -h库IP > ``` ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值