建设网站推广广告图,阿里云可以做几个网站,中国做的电脑系统下载网站好,前端网站开发实例视频每次数据库复制冲突之后#xff0c;经常使用的一个命令如下。
SET GLOBAL SQL_SLAVE_SKIP_COUNTER 1;一般会认为#xff0c;现在出现冲突错误#xff0c;那就将上面参数值设置为1#xff0c;跳过出错的这个event就可以解决了。重新启动复制#xff0c;发现问题果然解决经常使用的一个命令如下。
SET GLOBAL SQL_SLAVE_SKIP_COUNTER 1;一般会认为现在出现冲突错误那就将上面参数值设置为1跳过出错的这个event就可以解决了。重新启动复制发现问题果然解决我们以为这样理解是正确的。其实不然。
这需要从Binlog的内容说起。在Binlog中所有的Binlog是按照组来分的每一个组是其主库生成的一个事务Binlog都以BEGIN开始并以COMMIT结束。还有一些特殊事件比如用户变量的设置、随机数的设置等。
那么设置参数SQL_SLAVE_SKIP_COUNTER之后对复制的影响是什么呢?从库遇到这个参数时它的skip算法又是什么呢?
这需要根据不同类型的事件分别做介绍如下。 BEGIN语句对于一个Binlog组肯定会有一个BEGIN语句作为开始的标志。执行到BEGIN时说明从这个位置开始到后面出现的第一个提交事件结束中间这一段Binlog是属于一个组的那么此时会因为不同的SQL_SLAVE_SKIP_COUNTER有不同的处理方式。如果参数SQL_SLAVE_SKIP_COUNTER值为1则此时这个组中的所有事件都会被算作不计数事件也就是说这个1代表一个事务而不是一个事件。只有遇到COMMIT语句时才会将计数1减为0那么下一个事务组会正常执行。如果参数SQL_SLAVE_SKIP_COUNTER的值大于1那么这个组中的事件就会被认为是一个个的事件处理一个事件参数SQL_SLAVE_SKIP_COUNTER的值就减去1。当减到1的时候如果这个事务组还没有结束则回到上面跳过值为1的情况如果结束了但还没有减为0那么下一个事务组会继续重新处理。 COMMIT或ROLLBACK语句上面已经提到遇到这个语句时不管任何情况参数SQL_SLAVE_SKIP_COUNTER的值都会减1。如果SQL_SLAVE_SKIP_COUNTER的值为 1就像上面说的COMMIT之前所有的事件都会被算为不计数事件这里减1之后就完成了一个事务的skip。 其他Query语句上面已经说过当SQL_SLAVE_SKIP_COUNTER为1的时候会将组内事件都跳过否则它会被减1。 Rows事件这种类型是在行模式下一个行的事件类型。针对一条sql语句产生的若干个事件分别计数。如果设置的SQL_SLAVE_SKIP_COUNTER大于1则针对每一个事 件都会递减1如果减到了1或设置为1了则直到COMMIT事件之后才会计数之前所有的操作都不会被计数。 不计数事件这种类型的意思是只要遇到这种事件并且设置了参数SQL_SLAVE_SKIP_COUNTER为1或递减之后值为1那么就跳过并且不会影响SQL_SLAVE_SKIP_COUN-TER的值。而如果设置的SQL_SLAVE_SKIP_COUNTER值大于1则计数递减1直到递减到1时这类事件才不会算入计数。这种类型的事件包括Table_map、Intvar、Rand、User_var、BEGIN_load这五个事件所以在Binlog中如果有这五个事件则在计数中不做计数直接忽略。
需要注意的是在每次复制中断后看上去中断的位置是出错的事件但实际上那只是一个执行错误的位置。因为在复制时是以组(事务)为单位的事务中执行出错了则这个事务会回滚这个组就没有完成。实际上此时Binlog停止的位置是这个组的开始位置所以在设置好之后开始的位置肯定是BEGIN或BEGIN之前的一些设置命令的位置此时设置SQL_SLAVE_SKIP_COUNTER为1之后后面跳过的就是一个完整的事务而不是一个事件而已。
对于设置SQL_SLAVE_SKIP_COUNTER为其他值的情况这是比较危险的。因为它的跳过算法在上面已经讲清楚了它会把每一个query语句(包括BEGIN及COMMIT)都计入跳过计数的情况也就是说假设一个组至少存在3个事件那么如果设置跳过为4、5、6实际上结果有可能只跳过1个事务也有可能跳过2个事务但这是没有办法预期的。除非你自己已经很清楚当前点之后有多少个事件及对应事件的类型否则不会知道具体跳过了几个事务。
此时可以再回到开头所说的问题上来。在skip的时候看到的是在哪一个位置出错了但实际上此时是停在了一个事务的开始位置而出错的位置有可能是在事务中的某一个语句或者行上面那么此时做skip实际上是跳过了当前中断位置所在的整个事务。可想而知事务中如果有其他操作也就都跳过了。而从表象上看好像是跳过了这个事件。所以说看到的和真实发生的其实不太一样。
当然通过设置参数SQL_SLAVE_SKIP_COUNTER来跳过复制错误的操作只有在MySQL 5.5版本或者是5.6及以上的版本中没有开GTID的情况下才能使用。在处理问题时有时候确实很方便但也是比较危险的最好确认清楚是不是可以跳过跳过之后是不是要处理数据丢失的问题等。最好在跳过之前记录一下相关Binlog的位置在恢复之后看一下从出错位置开始的一个Binlog事务有没有需要特殊处理的操作。
关于这个问题其实很容易做一些测试研究一下参数SQL_SLAVE_SKIP_COUNTER设置为不同的值时复制是什么表现。不过个人建议永远不要将这个参数的值设置为非1否则会非常难控制。假设跳过的值太多可以分开多次每次跳过最多一个事务这样也能做到心中有数并且是只有出错的时候才去跳。
下面是一段每次跳过一个事务的脚本只有在复制中断的情况下才会跳过并且自动开始复制。
#!/usr/bin
MySQL_userusername
MySQL_passwordpassword
MysoL_host127.0.0.1
MysQL_port3306
sleep_interval100
while:
dodatemysql -u${MySQL_user} -p${MysQl_password} -h ${MysaL_host} -P ${MySQL_port} -e set global sql_slave_skip_counter1;start slave;usleep ${sleep_interval}echo
done当然可以对这段代码稍微做一点改造加上一行可以记录一下中断时的位置。每跳过一个事务都打印一下这个事务的开始位置这样可以了解跳过的事务量并且方便事后查找跳过了哪些事务。但这样大批量的跳过一般是在处理故障或是明知道影响不大时才这样做的。还是那句话请谨慎使用。
