windows搭建MySQL主从补充说明
这3种情况是在HA切换时，由于是异步复制，且sync_binlog=0，会造成一小部分binlog没接收完导致同步报错。
第一种：在master上删除一条记录，而slave上找不到。
第二种：主键重复。在slave已经有该记录，又在master上插入了同一条记录。
第三种：在master上更新一条记录，而slave上找不到，丢失了数据。
此类报错和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“。
一、尝试了断网之后的接入 也就是主机在进行数据录入 然后 备机下线了 模拟的是网断了 这个时候数据是可以进行同步的
#max_allowed_packet是 MySQL 中的一个设定参数，用于设定所接受的包的大小
二、max_allowed_packet经过检查发现这个值偏大了 主机上与备机上的binlog日志不一致 然后主机先关机了 导致的binlog日志不完整 不一致 主机binlog日志写入过快 造成的主从不一致 这个时候会特别考验io 也就是笔记本的性能
三、主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。 这个时候可能就需要同步到定制的备份 这个时候能不能换成一个备选方案 也就是说要定期备份data下的数据 这个下周 准备在跟樊伟确认一下
其中备选方案 备机优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql --slave 内存中完成，减少备机磁盘写操作 因为备机更多的是读操作
innodb_buffer_pool_size默认大小为128M。大小大于1G时，将innodb_buffer_pool_instances设置大于1的值可以提高服务器的可扩展性。
同时可以减小多次磁盘I/O访问相同的表数据。
四、确认 加入开机自启动配置 这样在现场确保电脑接入后就可以直接使用
使用如下的方式可以确认当前设定值
select @@max_allowed_packet;
show variables like 'max_allowed_packet';
CHANGE MASTER TO master_host ='192.168.31.33',
master_port=3306,
master_user='slave',
master_password ='123456',
master_log_file='mysql-bin.00039',
master_log_pos=156;
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
该错误发生在从库的io进程从主库拉取日志时，发现主库的mysql_bin.index文件中第一个文件不存在。出现此类报错可能是由于你的slave 由于某种原因停止了好长一段是时间，当你重启slave 复制的时候，在主库上找不到相应的binlog ,会报此类错误。或者是由于某些设置主库上的binlog被删除了，导致从库获取不到对应的binglog file。
ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000040',MASTER_LOG_POS=156;
could not execute Write_rows event on table corr.t_user_eye; Duplicate entry '130922199711251613' for key 't_user_eye.PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000022, end_log_pos 1060638