主从同步很多时候会因为从库设置没有跳过错误而卡停或者其他原因, 导致同步数据丢失. 实际生产中常常有人会直接停到掉从库二进制日志功能, 再手动去添加最新的主库Position值和MASTER_LOG_FILE值. 但是人为判断,还是会损失掉部分数据. 如果涉及到多表时, 就很难恢复.
其实,修复全部数据的方法是 : 重新跑动最新的备份,更改从库拿到最新binlog日志值,这样就可以了. 这个方法的前提是,已经搞好了主从错误的产生bug. 目的是挽回从库丢失的数据.。
1.登录主库服务器, mysqldump下来需要同步的数据库 ( --single-transaction 防止表锁 )
mysqldump -uroot -p'123456' --databases database_name --single-transaction >/opt/database_name.sql;
2.在主库压缩 mysqldump下来的文件
tar -zcvf database_name.sql.tar.gz database_name.sql;
3.在主库把压缩文件传输到从库(注:实际公司生产中 scp 文件传输是有专门账号或者权限的)
scp -r database_name.sql.tar.gz root@187.100.100.101:/opt/
4.在从库解压缩备份的文件到当前文件夹
tar -zxvf database_name.sql.tar.gz
5.在从库执行SQL文件,替换更新从库的数据库(指定从库的数据库)
mysql -uroot -p'654321' -f database_name</opt/database_name.sql;
6.进入主库 获取日志文件夹和日志方位点值
master status\G;
显示如下:
File: mysql-bin.000093
Position: 186179018
7.在从库, 修改从库的日志文件夹和日志方位点(把上面的最新值放入到这里)
CHANGE MASTER TO MASTER_HOST='187.100.100.101', MASTER_USER='xiaoming', MASTER_PASSWORD='xiaoming123', MASTER_LOG_FILE='mysql-bin.000093', MASTER_LOG_POS=186179018;
8.从库开启服务器(相当于重新开启了binlog同步)
start salve;
9.查看二进制同步功能是否成功. 在从库
show slave status\G;
如果显示
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
就说明同步已经开启.