mysql主从同步配置及故障定位

一、mysql主从配置过程

主节点:
    1) 启动二进制日志;
        vim /etc/my.cnf | vim /etc/my.cnf.d/server.cnf
            [mysqld]
            log-bin=master-bin
            server-id=1
            innodb_file_per_table=ON
            skip_name_resolve=ON
        systemctl restart mysqld
    2) 为当前节点设置一个全局唯一的id号;
    3) 创建有复制权限REPLICATION SLAVE, REPLICATION CLIENT的用户账号;
        grant replication slave,replication client on *.* to 'repluser'@'172.18.%.%' identified by 'replpass';
        flush privileges;

从节点:
    1) 启动中继日志;
        vim /etc/my.cnf
            relay-log=relay-log
            server-id=2
            innodb_file_per_table=ON
            skip_name_resolve=ON
        systemctl restart mysqld
    2) 为当前节点设置一个全局唯一的id号并且和主节点不同;
    3) 使用有复制权限的账号连接至主服务器，并启动复制线程;
        change master to master_host='$ip',master_user='repluser',master_password='replpass',master_log_file='master-bin.000003',master_log_pos=245;
        start slave;

二、mysql主从同步故障定位

1.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-id option must be used on slave but this does not always make sense; please check the manual before using it

问题原因：mysql主库和从库server_id相同

更改从库id既可

2.error executing row event: 'table doesn't exist'

问题原因：主库中有数据，从库是空库无法直接同步

需先导入一次主库备份的全量备份数据，再进行主从同步

3.could not execute update_rows event on table super_pms.issue_cli_queue; can't find record in 'issue_cli_queue', error_code: 1032; handler error ha_err_key_not_found; the event's master log mysql-bin-log.001793, end_log_pos 336631
解决办法:

mysql> stop slave ;
mysql> set global sql_slave_skip_counter=1;
mysql> start slave;

 4.ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

解决办法：

mysql> stop slave;
mysql> set global gtid_mode=ON_PERMISSIVE; 
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql> START SLAVE; 
mysql> SHOW SLAVE STATUS\G;

mysql> set global gtid_mode=ON;
mysql> show variables like 'gtid_mode';

5.error 1236 报错

5.1 logevent超过max_allowed_packet 大小

1. Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the start event position from 'mysql-bin.006730' at 290066246, the last event was read from '/u01/my3309/log/mysql-bin.006730

【原因】
   此类报错和max_allowed_packet相关。首先max_allowed_packet控制着主从复制过程中，一个语句产生的二进制binlog event大小，它的值必须是1024的倍数 。出现此类错误的常见原因是
 1 该参数在主备库的配置大小不一样，主库的配置值大于从库的配置值。 从主库传递到备库的binlog event大小超过了主库或者备库的max_allowed_packet大小。
 2 主库有大量数据写入时，比如在主库上执行 laod data，insert into .... select 语句，产生大事务。
当主库向从库传递一个比从库的max_allowed_packet 大的packet ，从库接收该packet失败，并报 “log event entry exceeded max_allowed_packet“。
【如何解决】
 需要确保主备配置一样，然后尝试调大该参数的值。

mysql> set global max_allowed_packet =1*1024*1024*1024;
mysql> stop slave;
mysql> start slave

另外，5.6 版本中的 slave_max_allowed_packet_size 参数控制slave 可以接收的最大的packet 大小，该值通常大于而且可以覆盖 max_allowed_packet 的配置, 进而减少由于上面的问题导致主从复制中断。

5.2 slave 在主库找不到binlog文件 

1. Got fatal error 1236 from master when reading data from binary log:

【原因】
 该错误发生在从库的io进程从主库拉取日志时，发现主库的mysql_bin.index文件中第一个文件不存在。出现此类报错可能是由于你的slave 由于某种原因停止了好长一段是时间，当你重启slave 复制的时候，在主库上找不到相应的binlog ,会报此类错误。或者是由于某些设置主库上的binlog被删除了，导致从库获取不到对应的binglog file。
【如何解决】
 1 为了避免数据丢失，需要重新搭建slave 。
 2 注意主库binlog的清理策略，选择基于时间过期的删除方式还是基于空间利用率的删除方式。
  不要使用rm -fr 命令删除binlog file，这样不会同步修改mysql_bin.index 记录的binlog 条目。在删除binlog的时候确保主库保留了从库 show slave status 的Relay_Master_Log_File对应的binlog file。

5.3 主库空间问题，日志被截断

1. Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the start event position from 'mysql-bin.006730' at 290066434, the last event was read from '/u01/my3309/log/mysql-bin.006730

【原因】
 该错误和主库的空间问题和sync_binlog配置有关，当主库 sync_binlog=N不等于1且磁盘空间满时,MySQL每写N次binary log，系统才会同步到磁盘，但是由于存储日志的磁盘空间满而导致MySQL 没有将日志完全写入磁盘，binlog event被截断。slave 读取该binlog file时就会报错"binlog truncated in the middle of event;"
 当sync_binlog 的默认值是0，像操作系统刷其他文件的机制一样，MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。
 当sync_binlog =N (N>0) ，MySQL 在每写 N次 二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。
【如何解决】
 在从库重新指向到主库下一个可用的binlog file 并且从binlog file初始化的位置开始

mysql> stop slave;
mysql> change master to master_log_file='mysql-bin.006731', master_log_pos=4;
mysql> start slave;

5.4 主库异常断电,从库读取错误的position

1. 120611 20:39:38 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 
2. 120611 20:39:38 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236
3. 120611 20:39:38 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000143', position 664526789

【原因】
 该问题也是和sync_binlog=N不等于1有关，多出现在主机异常crash ，比如磁盘损坏，raid 卡损坏，或者主机异常掉电导致binlog 未及时同步到磁盘。从库读取了主库binlog file中的不存在的binlog position ，一般比binlogfile 的end position 的值还要大。
【如何解决】
1 在从库重新指向到主库下一个可用的binlog file 并且从binlog file初始化的位置开始

mysql> stop slave;
mysql> change master to master_log_file='mysql-bin.000144', master_log_pos=4;
mysql> start slave;

2 主备库设置 sync_binlog=1，但是设置为1的时候，会带来性能下降。