mysql主从故障案例

34yhtee

1.Got fatal error 1236 from master when reading data from binary log: 'unknown error reading log event on the master; the first event '' at 4, the last event read from '/opt/3306/mysql-bin.000001' at 308, the last byte read from '/opt/3306/mysql-bin.000001' at 308.'

在source那边，执行：

flush logs;

show master status;

记下File, Position。

在target端，执行：

CHANGE MASTER TO MASTER_LOG_FILE='testdbbinlog.000008',MASTER_LOG_POS=107;

slave start;

show slave status \G

一切正常。

2.

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'

3.Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

4.MySQL master 宕机导致slave数据比master多的case

5.reset master导致主从GTID不一致的处理方法
为什么从库的GTID会比主库的小呢？应该是有同学在从库做了reset master的操作，重置了GTID导致的
由于这是从从库同步到主库的信息，而从库是只读的，只会产生备份的临时信息。因此这些事务都可以跳过。但由于从库的GTID比主库上的小，跳过了1413号事务，后面还会有更多的类似的问题。因此还需要在从库上将事务号推高到跟主库一致的水平，这样后面从库产生的事务号都不会再跟主库上的有冲突。推高事务号可以通过执行空事务达到：
set gtid_next='44d3c576-ca26-11e3-a90a-a0369f38458a:1421;
begin;commit;
set gtid_next='44d3c576-ca26-11e3-a90a-a0369f38458a:1422;
begin;commit;
…………………………………
set gtid_next='44d3c576-ca26-11e3-a90a-a0369f38458a:7383;
begin;commit;

set gtid_next='AUTOMATIC';
检查主库relaylog，发现7388、7389这两个事务主库是有获取到的，但7388看起来跳过没执行，为什么7389这次执行却没报错呢？
检查主库的binlog。
可以发现：7388的确是被跳过了，而7389这个本该是insert的却变成了空事务！
这个问题比较坑，看了下文档，mysql 在row format的情况下，对于temporary tab的处理情况如下：
1、不进行tempory table 复制（这个应该是指创建）
2、从上面的binlog中也可以看到，对于temporary tab 的dml操作，在复制的时候，用空事务代替。

6.大坑:用SQLyog连mysql的部分操作不能同步到从库
解析日志发现relaylog里面有相关的alter table的操作，但是从库就是没有执行。比较奇怪的是另外那个从库很正常。
通过这次的问题，发现用工具连数据库还是会有很多隐患，要从根本上解决这个问题只能严格控制开发权限，只给他们select权限。
dba平时操作数据库的时候尽量在命令行操作

7.GTID复制报错处理：Last_Error: Error 'Can't drop database 'test'; database doesn't exist' on query
去查看主库上的binlog日志，查找drop database test相关的日志
要理解GTID代表的是什么，每个事务的提交都代表着一个GTID的生成，正如其全名：全局事务ID(global transaction identifier)，所以如果想跳过导致错误的事务不执行的话，需要找到对应事务的gtid号，设置(set gtid_next="....")并提交空事务后重新启用自动模式后，再重启slave就可以，并不是每个导致错误的事务都是binlog中最后一个事务
理解了这个后就能明白，之前的处理还是太复杂，其实直接看show slave satus\G的结果，看这两个参数的值：
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Error: Error 'Can't drop database 'test'; database doesn't exist' on query. Default database: 'test'. Query: 'drop database test'
Retrieved_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:1-9
Executed_Gtid_Set:
能够看到，Executed_Gtid_Set是空的，而且GTID是肯定开启了的，所以，说明日志传过来后压根还没开始执行，所以，第一个事务就已经被卡住了，首先应该跳过的事务号就是1，也不必再去看日志了
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
mysql> set gtid_next="988b8684-3e21-22e6-a801-24505689c77d:1";
Query OK, 0 rows affected (0.00 sec)
mysql> begin;commit;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.01 sec)
mysql> set gtid_next="AUTOMATIC";
Query OK, 0 rows affected (0.00 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
8.Error 'Cannot add or update a child row: a foreign key constraint fails
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;        #跳过一个事务
mysql>start slave;
接下来就是主从数据不一致的问题，可以使用pt-table-checksum来检查下不一致的数据，再进行同步，具体步骤如下
在主库执行：

mysql>GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE,CREATE,DELETE,INSERT,UPDATE ON *.* TO 'USER'@'MASTER_HOST' identified  by 'PASSWORD';
注：创建用户，这些权限都是必须的，否则会报错

shell> ./pt-table-checksum --host='master_host' --user='user' --password='password' --port='port' --databases=zabbix --ignore-tables=ignore_table --recursion-method=processlist
注：(1)因为涉及到的表太多，查看后发现很多表都有外键关联，错综复杂，而且因为是监控表，即使丢失一些也没什么关系，所以查出较大的且没有外键关联的表用ignore-tables选项排除，对其他表进行比对，如果表比较少的话直接指定--TABLES
    (2)recursion-method如果不设的话，会报错：Diffs cannot be detected because no slaves were found.  其参数有四：processlist/hosts/dsn/no,用来决定查找slave的方式是show full processlist还是show slave hosts还是直接给出slave信息，具体用法在另一随笔pt-table-checksum介绍中详述

shell>./pt-table-sync --print --replicate=percona.checksums h=master_host,u=user,p=password,P=port h=slave_host,u=user,p=password,P=port --recursion-method=processlist >pt.log
注：最好使用--print，不要直接使用--execute，否则如果弄出问题，就更麻烦了，打印出直接执行的语句，去从库执行就好了
复制代码
将pt.log传到从库，直接执行，然后再次在主库上进行一致性检查，如果还有不一致的数据，记得登录mysql去把checksums表清空，然后再次进行检查同步，直到没有不一致的数据