商务网站模板下载,怎么创建一个自己的网站,域名注册之后怎么建设网站,建设网络文化网站的请示在使用Mysql的主从复制架构中#xff0c;有两个比较头疼的问题#xff1a;1、主从数据不同步后如何处理2、主从同步延迟问题如何解决本文将根据实际案例来分析下问题1#xff0c;至于问题2多数文档介绍的办法是启用多线程复制来解决#xff0c;言归正传#xff0c;这里的问…在使用Mysql的主从复制架构中有两个比较头疼的问题1、主从数据不同步后如何处理2、主从同步延迟问题如何解决本文将根据实际案例来分析下问题1至于问题2多数文档介绍的办法是启用多线程复制来解决言归正传这里的问题1还可以细分成两种情况。1、Slave_IO_Running和Slave_SQL_Running在YES情况下主从数据不同步如何处理2、Slave_SQL_Running在NO情况下主从数据不同步如何处理出现第一种情况通常原因是手工去修改了从库的数据导致主从数据不一致这种情况如果不及时处理当主库也更新了对应的数据的时候就会演变为第二种情况。举个例子在一主一从的条件下当前主从的数据是同步的。人为去操作从库的某张表数据,本例中以asm_user表为演示其中id字段为主键mysql insert into test.asm_user (id,name,salary) values (1,a,10000);当主库的这条数据未变动的时候当前主从同步进程中Slave_IO_Running和Slave_SQL_Running还是为YES目前只是asm_user这张表的数据不同步而已对应其他schema上的数据还是会保持主从同步但如果这个情况主库执行相同的SQL语句mysql insert into test.asm_user (id,name,salary) values (1,a,10000);对应的SQL apply到从库的时候就会发现duplicate key,这个时候主从的同步就会停止掉。# tail -f /home/mydata/localhost.localdomain.err这种情况下一般我们采用maatkit工具来校验主从数据库的数据差异情况。这个办法其实回答了前面的问题1Slave_IO_Running和Slave_SQL_Running在YES情况下主从数据不同步如何处理# yum -y install perl-TermReadKey# wget ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/maatkit-7540.tar.gz# tar -zxvpf maatkit-7540.tar.gz# cd maatkit-7540# perl Makefile.PL# make make install# mk-table-checksum h192.168.115.6,uroot,p123456,P3306 \h192.168.115.7,uroot,p123456,P3306 -d test | mk-checksum-filter# mk-table-checksum h192.168.115.6,uroot,p123456,P3306 \h192.168.115.7,uroot,p123456,P3306 -d test如果主从数据不一致则采用mk-table-sync进行数据同步# mk-table-sync --execute --print --no-check-slave --transaction --databases test \h192.168.115.6,uroot,p123456 h192.168.115.7,uroot,p123456很明显当前test库数据是一致的目前主从同步这个错误是可以忽略的因此我们采用跳过这个事务的办法来处理主从数据库不同步问题。通常在生产环境中主库的数据是不断的更新的这里我们在主从数据不同步的情况下在主库继续插入一条数据方便后续验证。下面我们开始处理主从不同步问题在未启用GTID复制的情况下采用下面的方法跳过事务mysqlslave stop;mysqlSET GLOBAL SQL_SLAVE_SKIP_COUNTER 1; //跳过一个事务mysqlslave start;Mysql5.6之后支持GTID复制开启GTID复制的好处很多具体可以百度一下但当开启gtid后就不能采用前面那种办法来跳过事务。在show slave status \G;输出中的最后几条里面Retrieved_Gtid_Set项记录了relay日志从Master获取了binlog日志的位置Executed_Gtid_Set项记录本机执行的binlog日志位置(如果是从机包括Master的binlog日志位置和slave本身的binlog日志位置)我们要跳过事务的GTID在错误日志中有记录# tail -f /home/mydata/localhost.localdomain.errmysql set session gtid_nextbd9e9912-2bc7-11e6-bade-000c29b8871c:1440;mysql begin;commit;mysql set session gtid_nextautomatic;mysql start slave;mysql show slave status \G;验证从库数据是否和主库一致mysql select * from test.asm_user;前面模拟了Slave_SQL_Running在NO情况下主从数据不同步情况的处理过程在现实的环境中往往情况要复杂的多下面分享一则内存开发库因为断电导致主从数据不一致的故障处理1、因为电源故障导致主从数据库全部宕机电源恢复后主库启动正常从库无法启动通过分析日志发现可能是电源故障导致从库的固态盘异常许多的binlog文件权限出现这些文件甚至无法正常查看1、通过fsck -y进行文件系统校验修复坏块修复完成后从库数据库可以启动但开启复制进程的时候报中继日志丢失2、在没有办法的情况下采用主库dump数据从库重新source的办法在线重做主从数据同步。整个操作过程中主库的数据不断的写入。下面是大致的步骤3.1、主库导出全库数据注意一定要使用--single-transaction参数# /usr/local/mysql/bin/mysqldump --all-databases --single-transaction --triggers --routines /tmp/1.sql3.2、将备份文件拷贝到从库进行source3.3、开启从库的复制进程mysqlchange master to master_host192.168.1.15,master_userrep1,master_password123456,MASTER_AUTO_POSITION1;mysqlstart slave;
