一个DDL导致MySQL主从停止问题及解决

DBA同学报一个bug,线上一个DDL语句导致主从停止,问题简化描述如下。

 

描述:

         简化的操作步骤如下:

 

Create table tb(c varchar(1000))engine=innodb; 

Create table tc as select cast(c as signed integer) from tb; 

Show create table tc; 

CREATE TABLE `tc`
( `cast(c as signed integer)` bigint(1000) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=gbk

 

 

从上面的结果看出,tc表中的这个字段定义为bigint(1000)。这个操作在主库上没有问题,但是当binlog在从库上apply时,就会发现同步停止,errno 1439.

 

分析

         其实我们发现,在Master中单独执行这个语句

CREATE TABLE `tc` (

  `cast(c as signed integer)` bigint(1000) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=gbk,

是执行不了的, 原因就是MySQL中定义bigint和int的显示宽度不能超过255.但是这个限制是在解析时判断的。

         而例子中的情况,tc这个表并没有明确表示bigint的显示宽度,只是在内部转换的时候,算出来这么长。而binlog记录的是这个算出来后的结果,导致从库直接执行这个语句时,就报错了。

 

简单解决

         实际上显示宽度也确实没有必要用到1000这么多,所以MySQL做这个限制并无不妥。因此我们只需要在真正执行语句的时候(而不只是解析的时候)多做一个判断,当整型字段的显示宽度超过255时,统一设置为255即可。

         这样从库上执行的语句中就是bigint(255)了,这个语句能够被正确执行。

         当然这个错误信息我们提示在warning中。

 

patch 下载 (基于Percona 5.5.18)

 

注:此问题只在Row based的binlog 时存在

时间: 2024-09-29 17:16:33

一个DDL导致MySQL主从停止问题及解决的相关文章

mysql主从同步复制错误解决一例_Mysql

蚊子今天下午搭了一主三从的mysql复制,结果所有服务器都配置好后,发现从上报如下的错误 复制代码 代码如下: Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-i

分享一个shell,它能自动恢复mysql主从错误

本shell的功能是自动恢复mysql主从错误,是不是感觉非常强大?好吧,直接上代码.  代码如下 复制代码 #!/bin/sh # check_mysql_slave status ip=eth0 mysql_command=/home/server/mysql/bin/mysql mysql_user=root mysql_pass=123456 mysql_sockfile=/tmp/mysql.sock datetime=`date +"%Y-%m-%d_%H:%M:%S"`

MySQL主从数据库同步延迟问题解决

MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力;②在从主服务器进行备份,避免备份期间影响主服务器服务;③当主服务器出现问题时,可以切换到从服务器. 相信大家对于这些好处已经非常了解了,在项目的部署中也采用这种方案.但是MySQL的主从同步一直有从库延迟的问题,那么为什么会有这种问题.这种问题如何解决呢? 1. MySQL数据库主从同步延迟原理. 2. MySQL数据库主从同步延迟是怎么产生的. 3. MySQL数据库主从同步延

怎样重配 重置mysql主从同步

重置mysql主从同步(MySQL Reset Master-Slave Replication) 在mysql主从同步的过程中,可能会因为各种原因出现主库与从库不同步的情况,网上虽然有一些解决办法,但是有时很难彻底解决,重置主从服务器也许不是最快的办法,但却是最安全有效的. 下面将自己重置主从同步的步骤总结一下,以备不时之需. master与slave均使用:centos6.0+mysql 5.1.61 ,假设有db1,db2两个数据库需要热备. 文中shell与mysql均使用root账号,

semi-sync插件崩溃导致MySQL重启故障详析

本文讲的是semi-sync插件崩溃导致MySQL重启故障详析 导读 semi-sync插件崩溃导致MySQL重启的故障分析全过程~ 作者:刘安 现为爱可生高级测试工程师,拥有丰富的自动测试开发经验:曾先后在文思海辉.Splunk担任测试工程师. 一.起因: 在公司测试MySQL高可用组件时发现一个异常.如下: 停止从库,高可用组件将从库自动启动后,主库发生了重启.然而,正常情况下,主库不应发生重启. 二.环境: 1.OS: CentOS release 6.7 (Final): 2.MySQL

使用innobackupex基于从库搭建mysql主从架构

        MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用Xtrabackup可以快速轻松的构建或修复mysql主从架构.本文描述了基于现有的从库来快速搭建主从,即作为原主库的一个新从库.该方式的好处是对主库无需备份期间导致的相关性能压力.搭建过程中使用了快速流备份方式来加速主从构建以及描述了加速流式备份的几个参数,供大家参考.     有关流式备份可以参考:Xtrabackup 流备份与恢复 1.备份

如何恢复MySQL主从数据一致性_Mysql

最近被告知,MySQL主从数据库的数据不一致,猜测备库在同步过程中出现了问题,于是,登上备库,使用 mysql> show slave status\G查看,果然,备库在insert语句中因违反主键约束,导致备库停止了同步.现在的问题很明确,就是如何恢复主从库数据的一致性. 可选方案如下: 一.查看Master最新的Position,将其作为Slave复制的起点. 这种思路体现的是过去的不一致既往不咎,现在保持同步即可.看起来,这个思路和恢复主从库数据的一致性的初衷有所违背,但这种方法,简单,高

MYSQL主从不同步延迟原理分析及解决方案_Mysql

1. MySQL数据库主从同步延迟原理.要说延时原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作,主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高,slave的Slave_IO_Running线程到主库取日志,效率很比较高,下一步,问题来了,slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施.DML和DDL的IO操作是随即的,不是顺序的,成本高很多,还可能可slave上的其他查询产生lock争

完整的mysql主从配置方法

  mysql主从分两个角色 1.主服务器 master 2.从服务器 slave mysql主从复制就是两个服务器之间数据库的同步,也可以理解成对主服务器的一个备份,当主服务器的数据进行了变更,那么从服务器也会自动更新,其实是通过bin-log日志实现的,也就说他们中间是传输binlog日志的.这样我们就可以对数据进行多个节点进行冗余从而保证可用性! 公司现在有三台服务器,一台阿里云,两台VPS,现在需要把阿里云上的数据库同步到其他两台VPS上.阿里云做主服务器其他两台服务器做从服务器 操作如