关于MySQL主从复制中UUID的警告信息

日期: 2014年5月23日

博客: 铁锚

最近在查看MariaDB主从复制服务器 Master 的错误日志时看到很多条警告信息,都是提示 UUID()函数不安全,可能 Slave 产生的值和 Master不一致, 警告信息大致如下:

140522 15:11:10 [Warning]
Unsafe statement written to the binary log
using statement format since BINLOG_FORMAT = STATEMENT.
Statement is unsafe because it uses a system function
that may return a different value on the slave.
Statement:
insert into t_user(userId,userName) values(uuid(),'FunYoung')

大致翻译为中文如下所示:

140522 15:11:10 [警告]
因为使用的格式是 BINLOG_FORMAT = STATEMENT,
所以写入到二进制日志中的语句可能是不安全的.
语句不安全是因为使用了一个系统函数,
在 slave从服务器上执行可能会生成不一致的数值.
语句如下:
insert into t_user(userId,userName) values(uuid(),'FunYoung')

看样子是说,因为slave的 UUID() 函数产生的值可能和Master的不一致,所以使用 BINLOG_FORMAT = STATEMENT这种日志格式是不安全的。

在网上找了一些资料,显示 5.0 版本是绝对有问题的,怎么办呢? 要么修改实现,比如在应用层生成 UUID,要么就采用基于行,而不是基于语句的二进制日志格式。

据说 5.0 以后是不一定的,翻看了一些官方文档,好像 5.6 版本修正了这个问题。 参考链接: 22 Changes in MySQL 5.6.0

还有个是09年的文档,说是当时有这个问题
https://drupal.org/node/502622

还有一个更详细的文章: Beware
of MySQL 5.6 server UUID when cloning slaves

我们使用的是MariaDB5.5,应该是兼容 MySQL5.5吧,经排查这个问题系统已经自己解决了。

MariaDB [(none)]> select version();
+--------------------+
| version()          |
+--------------------+
| 5.5.34-MariaDB-log |
+--------------------+
1 row in set (0.00 sec)

如果你遇到这个问题,假如还可以升级数据库系统,那就升级到最新版那就没事了。

如果不能升级DMBS,那么就需要在应用层,或者采用 基于行的复制方式 了。

关于MySQL主从复制中UUID的警告信息,布布扣,bubuko.com

时间: 2024-10-06 01:31:47

关于MySQL主从复制中UUID的警告信息的相关文章

MySQL主库复制中Slave_SQL_Running_State参数详解

查看命令: show slave status\G 其他相关参数: Seconds_Behind_Master: 1287 Slave_SQL_Running_State常见状态值: Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it 同步日志也已全部执行完毕,最常见的状态. Slave_SQL_Running_State: updating 正在

2-18,19 搭建MySQL主从服务器并并通过mysql-proxy实现读写分离

MySQL主从服务器 实现方式: MySQL  REPLICATION Replication可以实现将数据从一台数据库服务器(master)复制到一台或多台数据库服务器(slave) 默认情况下这种情况属于异步复制,无需维持长连接 通过配置,可以复制所有库或者几个库,甚至库中的一些表 它是MySQL内建的,自带 Replication的原理 主服务器master将数据库的改变写入二进制日志文件,从服务器slave同步这些二进制日志,并生成中继日志,从服务器根据中继日志,执行这些改变 DML:S

mysql 主从配置uuid相同错误解决

配置mysql主从时,由于是拷贝的mysql目录,导致主从mysql uuid相同, Slave_IO无法启动,报错信息如下: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. 解决办法:修改mysql data 目录下auto.cnf 文件中uuid的值,使两台mysql

Mysql主从同步(复制)

目录: mysql主从同步定义      主从同步机制 配置主从同步      配置主服务器      配置从服务器 使用主从同步来备份      使用mysqldump来备份      备份原始文件 主从同步的小技巧 排错      Slave_IO_Running: NO      Slave_SQL_Running: No   mysql主从同步定义 主从同步使得数据可以从一个数据库服务器复制到其他服务器上,在复制数据时,一个服务器充当主服务器(master),其余的服务器充当从服务器(s

shell监控MySQL主从状态脚本两则

内容为自己的一点总结,如有不对欢迎狠劲儿拍砖 本文来自http://yijiu.blog.51cto.com/转载请经博主同意,翻版可耻 监控主从复制正常与否 相比各位都应该知道,监控主从是否工作正常,涉及命令如下: show slave status\G; 那么,我们需要关注的参数如下: 1. 首先查看SQL和IO线程是否为YES状态(想必各位都明白了) 2. 是否有延迟 是否大于0   #一般生成环境延迟是否大于500秒,如果大于500则报警,如大于1000则严重报警 #比如传递一个sql到

Mysql主从同步(复制)(转)

文章转自:https://www.cnblogs.com/kylinlin/p/5258719.html 目录: mysql主从同步定义 主从同步机制 配置主从同步 配置主服务器 配置从服务器 使用主从同步来备份 使用mysqldump来备份 备份原始文件 主从同步的小技巧 排错 Slave_IO_Running: NO Slave_SQL_Running: No mysql主从同步定义 主从同步使得数据可以从一个数据库服务器复制到其他服务器上,在复制数据时,一个服务器充当主服务器(master

Mysql主从配置,实现读写分离

大型网站为了软解大量的并发访问,除了在网站实现分布式负载均衡,远远不够.到了数据业务层.数据访问层,如果还是传统的数据结构,或者只是单单靠一台服务器扛,如此多的数据库连接操作,数据库必然会崩溃,数据丢失的话,后果更是 不堪设想.这时候,我们会考虑如何减少数据库的联接,一方面采用优秀的代码框架,进行代码的优化,采用优秀的数据缓存技术如:memcached,如果资金丰厚的话,必然会想到假设服务器群,来分担主数据库的压力.Ok切入今天微博主题,利用MySQL主从配置,实现读写分离,减轻数据库压力.这种

mysql-poxy 实现mysql主从架构读写分离

在高并发系统设计中,后端数据库的性能往往会成为系统的瓶颈,这时候就需要进行合理的设计,以分摊后端数据库的压力,比如在数据层前面构建缓存层.数据文件存放在RAID这样的设备.对数据进行分库分表分区存放.合理利用索引.进行数据的读写分离等.mysql-proxy提供了mysql数据库的读写分离能力,mysql-proxy通过Lua脚本能分析得出用户的sql请求,如果发现在是read请求,则会转化到master-slave模型的slave中,如果是write请求,则会转发到master中,以达到读写分

mysql主从出现问题 如何诊断故障点   如何恢复数据

1 主从问题原因 一般导致主从问题的因素一般有以下几种:一个主库的从库太多,从库硬件比主库差,慢SQL语句过多主从复制单线程,主库写并发太大来不及传送到从库.主从库之间的网络延迟.因为机器配置的问题,包括磁盘IO,CPU,内存等各方面因素造成复制的延迟 2 主从问题 主从问题很多,错误代码也不一样,可以在从库上执行show slave status\G查看是否主从同步了,如果sql和lo线程状态不是yes,说明主从同步出现问题了. 实例1-1      从库写入数据冲突 例如:show slav