mysql复制关系

一旦建立好主从复制关系后就不要在从库上执行任何dml和ddl操作，包括创建用户也不行。

那么万一在从库上执行了dml或者ddl操作了，会有何影响，以及如何恢复？

slave同步状态中出现Slave_SQL_Running: No ，即slave不同步！
解决办法：
第一种方法：忽略错误后，继续同步。
该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况（下面均为在slave机器上的操作）
mysql> stop slave;
mysql> set global sql_slave_skip_counter =1;   //表示跳过一步错误，后面的数字可变；或者在my.cnf里添加slave-skip-errors = all（上面已在配置中添加）
mysql> start slave;
mysql> show slave status\G      //查看：
第二种方法：重新做主从，完全同步
该方法适用于主从库数据相差较大，或者要求数据完全统一的情况
1--master主库上操作
mysql> flush tables with read lock;  //进行锁表，防止数据写入。注意该处是锁定为只读状态，语句不区分大小写
#mysqldump --lock-all-tables --all-databases --flush-logs
--master-data=2 > /root/allsql.sql  
//主库完全备份(如果是指定库同步，就备份指定库)，注意数据库备份一定要定期进行，确保数据万无一失
mysql> show master status;      //查看master状态，注意log file和pos节点，slave同步会用到
# scp mysql.bak.sql root@192.168.1.102:/tmp/        //把备份文件传到slave从库机器，进行数据恢复
2--slave从库操作
mysql> stop slave;
mysql> source /tmp/mysql.bak.sql
mysql> change master to master_host = '192.168.1.101', master_user = 'slave', master_port=3306.......；
mysql> start slave;
mysql> show slave status\G 
.......
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
此种方法中最为关键主要有两步：
①主服务器上锁表做完全备份，并滚动日志；
②从服务器上进行半道恢复.

5）slave中继日志relay-log损坏？
什么是中继日志？
relay-log存放在从服务器上，从服务器将主服务器的二进制日志文件拷贝到自己的主机上放在中继日志中，然后调用SQL线程按照拷中继日志文件中的二进制日志文件执行以便就可达到数据的同步 。
如何中继日志避免：
mysql 5.6版本后，在my.cnf文件中开启relay_log_recover=1即可避免。

6）slave连接超时且重新连接频繁
若有多少slave，且没有设置server_id或两个slave设置相同的server_id，将有可能会出现服务器的ID冲突。这种情况下，其中一台slave可能会频繁超时或丢失后重新连接序列。
所以一定要确保每台slave及master在my.cnf中都要设置不一样的server_id。

7）主库与从库使用不同的存储引擎造成不同步

8）从库同步时，提示表不存在
错误：Last_Error: Error executing row event: 'Table 'test.t1' doesn't exist'
解决方法：在从库重建这张表。

9）max_allowed_packet设置过小导致slave报错
max_allowed_packet默认是16M，主从库的max_allowed_packet值和备库上的不匹配。
在这情况下，主库可能会记录一个备库认为过大的包。当备库获取到该二进制日志事件时，可能会碰到各种问题，如无限报错和重试、中继日志损坏等。
具体表现：
从库的Slave_IO_Thread死掉了，查看后，出现以下错误提示：
Got a packet bigger than 'max_allowed_packet' bytes
很明显是由于max_allowed_packet的设置太小导致的，然后查检主从库上的设置，主库的设置大于从库，因为max_allowed_packet是动态参数，先调整从库上的max_allowed_packet
与主库相同，重新单独启动I/O线程就正常了。
原理说明：binlog的事件以RBR格式记录，且当前的事件长度大于了从库的max_allowed_packet, 导致无法Slave IO不能正常读取master binlog event.

10）在master上删除一条记录时出现的故障
在master上删除一条记录后，slave上因找不到这条记录而报错。
解决方法：
由于主库上已经对这条语句进行了删除操作，故可以跳过。
在这种情况下，说明主从同步可能数据会有不一致的情况发生，所以需要使用pt-table-checksum进行数据库一致性比对。
（参考：mysql主从同步(3)-percona-toolkit工具（数据一致性监测、延迟监控）使用梳理）

11）在master更新一条记录，而slave却找不到。
主从数据不致时，master有某条记录，但在salve上没有这条记录，若在master上进行更新这条记录，则在slave中可能报错。
解决方法：
   1--根据从库发生异常的位置，查主库上的二进制日志。
   2--根据主库二进制日志信息，找到更新后的整条记录。
   3--在从库上执行在主库上找到的记录信息，进行insert操作。
   4--跳过这条语句，再同步slave。
   5--使用pt-table-checksum查看主从库表数据否一致