13518219792
MySQL复制技术指部署中遇到的问题
A. 复制中断
mysql主从复制，经常会遇到错误而导致slave端复制中断，这个时候一般就需要人工干预，跳过错误才能继续
跳过错误有两种方式：
1.跳过指定数量的事务：
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务
mysql>slave start
2.修改mysql的配置文件，通过slave_skip_errors参数来跳所有错误或指定类型的错误
vi /etc/my.cnf
[mysqld]
#slave-skip-errors=1062,1053,1146 #跳过指定error no类型的错误
#slave-skip-errors=all #跳过所有错误
B. 冷备份恢复的UUID问题
本次的slave是通过关闭master后，直接复制datadir目录下的所有文件到slave服务器；然后启动slave，则会报错
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
分析问题:
上面报错说的是replication架构中需要保证每个mysql实例UUID(UUID保存在datadir目录下的auto.cnf文件中)唯一，就跟server_id一样需要保证主从架构中所有mysql实例server_id唯一。
之所以出现会出现这样的问题，是因为我的从库主机是克隆的主库所在的主机，所以auto.cnf文件中保存的UUID会出现重复(server_id已经在my.cnf文件中修改过)
解决问题：
关于该问题的解决方案其实很简单，停掉备库实例，删除备库的auto.cnf文件，启动备库实例，此时备库就会产生一个新的auto.cnf文件(产生新的UUID)。网上也有人说直接修改auto.cnf里面的uuid值，然后重启从库实例，该种方案没有测试过。
C. Last_SQL_Errno: 1677
Last_SQL_Errno: 1677
Last_SQL_Error: Column 0 of table ‘aa.heartbeat’ cannot be converted from type ‘smallint’ to type ‘int(11)’
@Shane Bester 建议slave_type_conversions=ALL_NON_LOSSY，能解决这个问题。以前没有关注过这个参数，我们线上环境都没有设置。
slave_type_conversions:在slave上进行字段类型转化的，因为主备之间可能在某些情况下，有相同的表名，但字段多少、字段类型、字段顺序不一样，可能导致1677错误，这时需要设置相应参数来进行处理。
MySQL 5.5.3版本开始，支持属性提升特性，包括有损转化和无损转换
参数支持值：
1、ALL_LOSSY:可以将int型转化成tinyint,存在截断的情况，有损转化
2、ALL_NON_LOSSY：不允许出现截断情况，slave的类型范围大于master方可转化。设置这个参数后，如果存在截断情况，slave会报错
3、以后两个参数都设置，就存在截断的情况
4、未设置，主备之间必须一致
在slave上类型转化需要注意：
Whether you use statement-based or row-based replication, the slave’s copy of the table cannot contain more columns than the master’s copy if you wish to employ attribute promotion.
参考:
/tupian/20230522/replication-features-differing-tables.html
在一台主机上增加一个slave，启动的时候报
[ERROR] Slave SQL: Slave failed to initialize relay
log info structure from the repository, Error_code: 1872
原因可能是：1、my.cnf没指定relay_log，2、没有reset slave
