MySQL复制那些事儿，安装配置难点还有常见故障和实用小技巧工具分享

（引用来源：主要基于个人运维经验、MySQL官方文档、以及社区常见问题汇总，如Percona Blog、Stack Overflow等平台上的高频讨论）

MySQL复制那些事儿，安装配置难点还有常见故障和实用小技巧工具分享

MySQL复制是啥？简单说说

你可以把MySQL复制想象成一个“照抄作业”的过程，有一台主服务器（Master），它负责写作业（处理写操作，如INSERT、UPDATE、DELETE），然后有一台或多台从服务器（Slave），它们会实时地把主服务器的作业本拿过来抄一遍（同步数据），这样做的最大好处就是：主服务器忙不过来或者突然坏掉的时候，从服务器可以顶上，保证服务不中断,同时也能分担主服务器的读数据压力。

这个过程的核心是主服务器把数据的改动记录在一个叫“二进制日志”（Binary Log）的文件里，从服务器会来读取这个日志，然后在自己身上重新执行一遍这些操作,从而达到数据一致。

安装配置中的几个头疼点

1. 版本要对得上：虽然不是严格要求主从版本完全一致，但最好让从服务器的MySQL版本高于或等于主服务器的版本，如果从服务器的版本太老，可能会不认识主服务器日志里的一些新“语法”，导致复制中断,这是最容易忽略的一点。
2. 服务器ID不能重复：在MySQL的配置文件（通常是my.cnf或my.ini）里，你需要给每一台参与复制的服务器设置一个独一无二的server-id，如果主从服务器的ID设成一样的，复制压根儿就启动不了，这个错误很低级,但新手常犯。
3. 权限要开对：从服务器需要用一个小号（账户）去连接主服务器拉取日志，你需要在主服务器上专门为从服务器创建一个用户，并且只授予REPLICATION SLAVE这个权限，权限给大了不安全，给小了复制不了，命令大概是：GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'slave_ip' IDENTIFIED BY 'password';
4. 起始位置要卡准：在配置从服务器时，你需要告诉它从主服务器的哪个日志文件的哪个位置开始“抄作业”，这个位置点（叫做binlog的坐标：文件名和位置）非常关键，如果主服务器上已经有数据了，你必须先手动把主服务器当前的数据快照导出来，恢复到从服务器上，然后从这个快照对应的日志位置开始复制，否则，从服务器会漏掉一部分数据，或者从错误的地方开始，导致数据混乱,这一步是配置中最容易出错的地方。

经常遇到的故障和解决办法

1. 复制中断，报错1062（主键冲突）或1032（找不到行）：这是最常见的问题，意思是，从服务器在应用日志时，发现要插入的数据主键已经存在，或者要更新的数据找不到了,这说明主从之间的数据已经不一致了。

   • 原因：多半是有人在从服务器上直接写了数据（比如手动修改了某条记录）,破坏了数据一致性。
   • 临时解决：如果只是一条记录出错，可以跳过这个错误，在从服务器上执行STOP SLAVE;，然后SET GLOBAL sql_slave_skip_counter = 1;（跳过1个事件），再START SLAVE;，但这只是权宜之计,数据不一致的根还在。
   • 根本解决：最好的办法是重新初始化从服务器，即，锁住主库，获取新的binlog位置，然后对主库做一份全新的数据备份，恢复到从库,再从这个新位置重新开始复制。

2. 从服务器延迟（Slave Lag）：你往主服务器插入一条数据，过好几秒才能在从服务器上查到,这就是延迟。

   • 原因：主服务器写入压力太大，从服务器只有单个SQL线程来“抄作业”，抄不过来；或者从服务器的硬件（特别是磁盘IO）比主服务器差太多。
   • 解决办法：
     • 升级从服务器硬件,尤其是换用SSD硬盘。
     • 在MySQL 5.6及以上版本，开启多线程复制（设置slave_parallel_workers），让从服务器用多个线程来抄不同数据库的作业,加快速度。
     • 优化主服务器上的慢查询SQL,减少不必要的写操作。

3. 连接不上主服务器：从服务器报错说连不上主库。

   • 原因：网络不通、主库防火墙挡住了连接端口（默认3306）、或者之前创建的那个复制用户的密码/权限不对。
   • 解决办法：一步步排查：先用telnet master_ip 3306命令测试网络和端口通不通；然后在主库上检查复制用户的权限是否正确。

几个实用小技巧和工具

1. 用pt-table-checksum检查数据一致性：这是Percona Toolkit工具包里的一个神器，它能在主从复制不停机的情况下，自动检查主从数据是否完全一致，它会发现那些隐藏的、没有报错但实际内容已经不同的数据，定期跑一下这个工具,能让你睡个安稳觉。
2. 用pt-heartbeat监控复制延迟：这个也是Percona Toolkit里的，它会在主库上创建一个心跳表，定期更新时间，从库会去读这个时间，通过计算时间差就能得到一个非常精确的复制延迟秒数，比看Seconds_Behind_Master这个状态值更准确。
3. 半同步复制（Semi-Synchronous Replication）：默认的复制是异步的，主服务器写完日志就认为成功了，不管从服务器有没有收到，这样如果主库宕机，可能会丢失数据，半同步复制要求主库至少成功收到一个从库的确认后，才告诉客户端写入成功，这大大增强了数据安全性,但会稍微降低一点写入性能。
4. 延迟复制（Delayed Replication）：你可以故意让从服务器延迟一段时间（比如1小时）再复制，这有什么用呢？万一有人在主库上误删了数据，你还有一个延迟的从库，数据在1小时前是好的，可以迅速从这个从库恢复数据，相当于一个简单的“后悔药”。

MySQL复制是个非常核心和有用的功能，但也不是配置好就一劳永逸的，需要定期检查其状态，监控延迟和一致性,并准备好应对各种突发故障的方案。