复制中断处理

• 1677错误
  • 第一种将主库改成statement格式
  • 第二种在从库设置slave_type_conversions
• 从库出现写入数据,把自增ID占用:1062错误
  • 将从库该条数据删除
  • 能确定数据一致也可以跳过该错误
• 从库上出现少数据,delete,update操作时,找不到相应的记录,出现1032错误
  • delete可以跳过错误
  • update只能补数据,在master的binlog中解析出哪个位置出错了,将这条数据插入,主要是主键个非空列,开启复制sql_thread,查看status
• 从库gtid值大于主库gtid值
  • 有可能主库被reset了
  • 新回复的从库将auto.cnf也恢复了,binlog还删除了,也有可能会出现这种场景

复制延迟排查

• 搞明白当前的数据库在干什么
  • show processlist;
  • show slave status\G定位到sql_thread执行到位置
    • io_tread同步到主库的binlog位置:Master_Log_File;Read_Master_Log_Pos
    • sql_thread重放到对应主库的binlog位置:Relay_Master_Log_File;Exec_Master_Log_Pos
    • Seconds_Behind_Master:这个值是怎么计算的?
      • io_thread.event.timestamp-sql_thread.event.timestamp 单位秒
• 查看当前的SQL状态
  • 机器负载很高
    • 索引不合理!!!
    • Statement索引不合理,造成同步延迟
      • mysql>pager more
      • mysql>show processlist;
        • 可以直接用select * from information_schema.processlist where 1=1 order by TIME desc limit 10;
        • USER不是sys的,感觉没什么问题的,时间太长快死掉的连接都可以杀掉
      • 在从库上能看到执行的SQL都有问题的!!!
• 利用perf top 查看MySQL的调度情况
  • perf top -p `pidof mysqld`
  • 利用Google
  • 利用源码定位出问题的地方
• 延迟现象一
  • Seconds_Behind_Master一直在增大,但Exec_master_log_pos就是卡着不动
  • 解析sql_thread执行的binlog
  • mysqlbinlog -v --base64-output=decode=rows --start-position=xxx mysql-bin.xxxx
  • 去主库上面找
    • Relay_Master_Log_File,Exec_Master_Log_Pos这两个参数定位
  • 在从库上面找
    • Relay_Log_File,Relay_Log_Pos这两个参数
  • 大事务卡的两个原因
    • 真的是大事务等待,一次更新50W行以上,坐等
    • 更新这个表可能没有索引
      • stop slave不了可以mysqladmin -S/mysql3306.sock shutdown
      • 关闭都关闭不了,只能kill -9,从库这么干,主库还是不要这么干
      • 重启mysql,重建索引,之后start slave

如何避免延迟

• 从库的配置适当高一点
• 使用MySQL5.7开启并行复制
• 表结构设计时,一定要有主键,而且主键要短小
• 使用新型硬件:PCI-E&SSD类设备
• 程序端适当的Cache,减少数据库的压力

复制结构调整Tips

• 场景

• 将下图中的机器加内存,并修改buffer pool,业务暂停时间小于1分钟

  
  
• 凌晨读写压力不大的情况下,可以考虑将读写都放在M上
• 将s1->stop slave;
• s1,s11,s12,s13全部shutdown,加内存,修改buffer pool
• 在s1和M上装keepalived,vip先指到M上,之后停掉M,查看vip是否指到s1上
• 如果是gtid复制,M启动后直接change master指到s1就可以
  • 在将s11,s13,M都指向s12就ok了
• 如果是传统复制,要经过一下几步
  • 在vip指过去之前在s1上执行show master status;
  • sleep 1;
  • show master status;结果没变化可以将结果保存到一个文件中
  • show master status>/tmp/1.log
  • M启动后change master to指s1就可以
  • 将s11,s13,M指向s12有两种办法
  • 第一种
    • 可以手工制造个错误,使s11,s12,s13,M都停在同一个位置
    • 在s12上执行show master status>/tmp/1.log
    • 在将s11,s13,M都指向s12就ok了
    • 之后再s12上跳过错误或者将错误修复
  • 第二种
    • 将s11,s12,s13,M全部停掉sql_thread
    • 在s1上执行show master status;
    • s11,s12,s13,M执行start slave sql_thread until master_log_file='xxx',master_log_pos=xxx;
    • 使s11,s12,s13,M机器都停在s1执行的show master status节点上
    • 在s12上执行show master status>/tmp/1.log
    • 在将s11,s13,M都指向s12就ok了

• 将级联复制改成正常的一级复制

  
  
• gtid可以直接change过去
• 传统复制
  • 在s1上执行stop slave;
  • 在s1上查看show slave status;
  • 在s11上的change master语句,host,port指定到M上
  • master_log_file='Relay_Master_Log_File' #在s1上执行show slave status查看出来的
  • master_log_pos=Exec_Master_Log_Pos #在s1上执行show slave status查看出来的
  • s2,s21同上
  • 将所有的从库开启复制start slave
• 假设s1机器电源坏了,不能登录,将s11机器挂到M下或者挂到s2下,怎么搞定?
  • gtid可以直接change master过去
  • 传统复制
    • 一种是将s21机器复制一份数据将s11机器还原,挂到s2下
    • 另一种是不需要重新备份
      • 解析s21机器的mysql-binlog,找到最后一个M库的server_id对应的事务,在这个事务上面找到它对应的timestamp,开启中继日志情况下server_id和timestamp具有传递性
      • 解析出timestamp对应的时间,去M机器上面找到对应的mysql-binlog,大概找到这个时间是写入的哪个binlog,可以用ls查看
      • 解析这个binlog,在这个binlog中查找上述的timestamp,找到对应的事务,要和从库上的那个事务语句一样才可以,查看一下从库的这个事物执行完没有(commit还是没commit),如果没执行完就要记录这个事物begin之前的log_pos,执行完了就记录下一个事务开始的log_pos
      • 将上述的binlog和log_pos写入到从库的change master to上面,开启复制,就可以将机器挂到M下面了