故障分析--主从复制故障1

报错内容

2016-04-29 00:09:57 9242 [ERROR] Slave SQL: Error ‘This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)‘ on query. Default database: ‘epsp_db‘. Query: ‘CREATE DEFINER=`unionpayb2b`@`%` FUNCTION `currval`(v_seq_name VARCHAR(50)) RETURNS int(11)
BEGIN
    DECLARE val,val1 INTEGER;
    SET val = 0;
    SELECT current_val INTO val1  FROM tbl_sequence WHERE seq_name = v_seq_name;
    IF (val1 IS NULL)THEN
    INSERT INTO tbl_sequence VALUES(v_seq_name,0,1);
    ELSE
    SET val=val1;
    END IF;
    RETURN val;
END‘, Error_code: 1418
2016-04-29 00:09:57 9242 [Warning] Slave: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) Error_code: 1418
2016-04-29 00:09:57 9242 [Warning] Slave: Failed to CREATE FUNCTION currval Error_code: 1307
2016-04-29 00:09:57 9242 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log ‘mysql-bin.000002‘ position 326441
2016-04-29 00:10:01 9242 [Note] /data/mysql/base/bin/mysqld: Normal shutdown

错误分析1

根据错误信息得知由于创建的这个函数对数据的操作对于replication场景,存在不确定性,也就是说这个函数在主库和从库上执行可能产生不一样的结果。
所以该函数在从库应用时产生了错误,并导致从库sql apply中断,错误信息中也记录了中断的文件及对应的position点

错误分析2

根据错误信息给出的提示,可能需要设置log_bin_trust_function_creators这个变量来解决这个错误
通过查询官方文档,得知了该参数的含义:

    log_bin_trust_function_creators

        这是一个安全参数,针对于主从复制时对于函数和触发器的处理,默认值为0,表示不允许对数据操作存在不确定性的函数和触发器的创建,因为这类语句会导致主从数据不一致的情况发生。

    同时官方文档对这类语句产生不一致的场景进行了进一步说明:

        通常二进制日志设置为statement或mixed格式时会出现这种情况,如果是row格式则不会,因为row格式不是记录的对这个函数的调用语句,而是记录的函数调用后对行的改变的记录。
        同样对于触发器也是一样。所以在基于row格式的情况下不会发生这种不一致的情况。
        mixed格式虽然会根据不同的情况动态的使用statement或row格式,但对于函数和触发器,mixed总是使用statement方式进行记录,所以基于mixed格式也会存在这种问题。

    官方链接说明:
        https://dev.mysql.com/doc/refman/5.7/en/stored-programs-logging.html

解决办法

[master/slave]修改二进制日志格式为row格式

[master/slave]修改log_bin_trust_function_creators参数,将其设置为1
    SET GLOBAL log_bin_trust_function_creators = 1;

可以在创建主从时直接使用row格式进行复制,不会出现该问题,如果不用基于row格式的复制,则提前启用该参数,避免主从复制时函数或触发器导致从库复制中断的问题,但由于该参数开启后,如果不是基于row格式的复制,很难保证当执行相关自定义的函数时,对数据的操作在主从上是一致的,存在不确定性,这也是为什么MySQL默认是禁止这类函数和触发器的原因,目的是为了保持主从数据的一致性。所以建议可能的情况下,还是采用基于row格式的复制,避免产生相关错误。
时间: 2024-12-12 23:47:03

故障分析--主从复制故障1的相关文章

redis主从复制故障转移

Redis主从复制与故障切换 目录 目录1 一.概述1 二. 实验目的2 三.试验环境2 四. 说明2 五. 拓扑2 六. 实施步骤2 6.1.分别安装redis2.8.32 6.2.配置主从同步3 6.3.配置主从故障切换4 七. 注意事项4 一.概述 Redis是一个开源的使用ANSI C语言编写.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库,并提供多种语言的API. Redis支持主从同步.数据可以从主服务器向任意数量的从服务器上同步,同步使用的是发布/订阅机制. Re

MySQL主从复制故障案例一

  案例一: 在M-S 一主一从 状态下,从库不小心写入,导致主从同步出现故障 故障模拟: in slave : 先创建一个数据库 crate database  buttongbu; in master 同样创建数据库, crate database  buttongbu; 此时在从库查看 in slave show slave status\G ,发现error出现,错误代码1007 解决方法: 方法一: stop slave; set global sql_slave_skip_count

Mysql DBA 高级运维学习笔记-MySQL主从复制故障解决

1.MySQL从库数据冲突导致同步停止 Show slave status报错且show slave status\G Slave_IO_Running: Yes Slave_SQL_Running: NO Seconds_Behind_Master: NULL Last_Error:Error 'Can't create database 'linzhongniao';database exists'on query. Default database:'linzhongniao'.Query

MySQL主从复制故障案例二

案例二: 一主多从的架构下,主库master宕机 解决思路: 1,登录从库 show processlist: 查看两个线程的更新状态 结果说明: 之前主从同步正常 分别登录其余2个从库32,33查看: cat   /data/3306/data/master.info cat   /data/3307/data/master.info 比较,那个POS最大,说明更接近主库,那么我们就选举此slave作为新的master. 或者利用半同步技术,直接选举实时同步了的这个库为新的master 如果,

mysql主从复制-故障案例一

1.从库上看到如下错误 mysql> show slave status\G; *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 172.18.10.11                   Master_User: rep     

centos7下mysql5.6的主从复制

一.mysql主从复制介绍 mysql的主从复制并不是数据库磁盘上的文件直接拷贝,而是通过逻辑的binlog日志复制到要同步的服务器本地,然后由本地的线程读取日志里面的sql语句,重新应用到mysql数据库中. mysql数据库支持单向,双向,链式级联,环状等不同业务场景的复制,一台服务器充当主服务器master,接收来自用户的更新,而一个或多个其他服务器充当从服务器slave,接收来自主服务器binlog文件的日志内容,解析出sql,更新到从服务器. 一主一从 (A -> B, A为主,B为从

解决虚拟机或物理机ping不通网关故障的方法与思路

基本思路: 确定问题缩小范围.先外部后内部,利用排除法.类比法.替换法(隔离法)将故障范围逐渐缩小到某一点. 谨慎做出结论.下结论前先三思,想到所有可能存在问题的点,特别是与别人讨论和描述问题时更应该注意. 记录问题.做好文档备案工作,如记录故障现象.故障分析.故障原因.处理流程.处理结果.结论与经验等. 相对于虚拟机,物理机ping不通网关的故障更好排查一些,因为虚拟机在于物理交换机通信的过程中存在一个中间层,中间层可能为宿主主机上的标准交换机或者某个分布式交换机.但无论是标准交换机还是分布式

MySQL Replication 主从复制全方位解决方案

原文:MySQL Replication 主从复制全方位解决方案 1.1 主从复制基础概念 在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行,二进制日志相关信息参考:http://www.cnblogs.com/clsn/p/8087678.html#_label6 1.1.1 二进制日志管理说明 二进制日志在哪?如何设置位置和命名? 在my.cnf文件中使用 log-bin = 指定:命名规则为 mysql-bin.000000 (后为6

MySQL主从复制原理及实践

第1章 MySQL的主从复制介绍 MySQL的主从复制方案,和上述文件及文件系统级别同步是类似的,都是数据的传输.只不过MySQL无需借助第三方工具,而是其自带的同步复制功能.另外一点,MySQL的主从复制并不是磁盘上文件直接同步,而是逻辑的binlog日志同步到本地再应用执行的过程. 复制可以单向:M=>S,也可以是双向M<==>M,也可以是多M换装同步等.如果设置了链式级联复制,那么,从(slave)服务器本身除了充当从服务器外,也会同时充当其下面从服务器的主服务器.链式级联复制类似