资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/一种修复MySQL主从数据差异的思路

一种修复MySQL主从数据差异的思路

IT那活儿 / 2476人阅读
一种修复MySQL主从数据差异的思路
点击上方蓝字关注我们


 背 景 概 述 


MySQL主从复制技术应用非常广泛，M-S复制架构、keepalived＋M-M复制架构、MHA等高可用架构都基于MySQL主从复制技术。主从复制是基于binlog的逻辑复制，实际应中,可能会因为各种原因出现主从数据不一致的情况,因此我们需要定期或不定期地开展主从复制数据一致性的校验和修复工作;

如果发生了mysql主从数据不一致的情况,我们应该怎样修复呢?本次分享一种不影响主库业务的修复思路。


 环 境 准 备 


  • Master节点

创建测试表t1和t2

CREATE TABLE `t1` (

`id` int NOT NULL AUTO_INCREMENT,

`username` varchar(20)  NOT NULL,

`phone` int(11)   NOT NULL,

`create_time` varchar(20)   NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=innodb DEFAULT CHARSET=utf8mb4;

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("李四","0123456789",now());

insert into t1(username,phone,create_time) values("李四","0123456789",now());

insert into t1(username,phone,create_time) values("李四","0123456789",now());



 CREATE TABLE `t2` (

`id` int NOT NULL AUTO_INCREMENT,

`username` varchar(20)  NOT NULL,

`phone` int(11)   NOT NULL,

`create_time` varchar(20)   NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=innodb DEFAULT CHARSET=utf8mb4;


insert into t2(username,phone,create_time) values("张三","0123456789",now());

insert into t2(username,phone,create_time) values("张三","0123456789",now());

insert into t2(username,phone,create_time) values("张三","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());


  • Slave节点

检查复制是否正常,确保复制正常


 错 误 模 拟 


  • Salve节点执行以下操作

set sql_log_bin=0;

delete from t1 where id=3;

  • Master节点执行

delete from t1 where id=3;

  • Slave节点检查复制状态

此时slave复制已发生异常,无法应用主库操作

  • Master持续操作,模拟业务

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("李四","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());


 数 据 修 复 


  • Master节点导出slave异常的数据表


mysqldump  -uxxx-pxxxx -P3306 -S  3306.sock --single-transaction --master-data=2 test t1    > t1.sql

查看gtid信息并记录

grep -A10 GLOBAL.GTID_PURGED t1.sql

SET @@GLOBAL.GTID_PURGED=fdc161ff-5aea-11eb-ab62-000c29e9d0c1:1-81;

  • Master持续模拟业务

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("张三","0123456789",now());

insert into t1(username,phone,create_time) values("李四","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());

insert into t2(username,phone,create_time) values("李四","0123456789",now());


  • Slave节点导入数据

检查gtid信息

导入数据

导入数据时发生报错,无法更新gtid信息,该错误不需理会,千万不能为了解决该错误执行resetmaster;

再次检查gtid信息,未发生变化

设置复制过滤并应用日志

此处设置的SQL_AFTER_GTIDS为备份文件中gtid,复制应用日志到该gtid后停止应用日志,此时异常的表数据已修复,清除复制过滤规则后启动sql应用即可

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ();

start slave sql_thread;


 数 据 验 证 


  • master节点

  • slave节点

演示中数据较少使用count(*)和select* 即可进行比较,生产中数据量大,环境复杂建议使用pt-table-checksum进行一致性校验.

演示环境为启用GTID的主从复制,同样适用于非GTID复制环境,根据情况选用合适的startslave选项,参考官方文档STARTSLAVE Statement部分:


START SLAVE [thread_types] [until_option] [connection_options] [channel_option]


thread_types:

    [thread_type [, thread_type] ... ]


thread_type:

    IO_THREAD | SQL_THREAD


until_option:

    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set

          |   MASTER_LOG_FILE = log_name, MASTER_LOG_POS = log_pos

          |   RELAY_LOG_FILE = log_name, RELAY_LOG_POS = log_pos

          |   SQL_AFTER_MTS_GAPS  }



END




云服务器 GPU云服务器 mysql 主从复制的种类 mysql主从数据 mysql数据库主从 mysql主从数据一致性

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/130013.html

相关文章

  • MySQL非主从环境下数据一致性校验及修复程序

    摘要：简介项目地址主从环境下数据一致性校验经常会用工具，它的原理及实施过程之前写过一篇文章生产环境使用检查数据一致性。上面的配置文件可以认为是用于控制程序的，这个配置文件是指定要校验的源库和目标库信息，以及要检验哪些表。 1. 简介 项目地址：https://github.com/seanlook/p... 主从环境下数据一致性校验经常会用 pt-table-checksum 工具，它的原理...

    104828720 评论0 收藏0

  • 跨云迁移过程中的数据同步及一致性校验实践（一）

    摘要：通过对一些客户的跨云迁移过程进行总结，发现普遍存在的挑战有三点数据完整性和一致性挑战。简而言之，跨云迁移过程中的数据一致性主要就集中在存量数据的迁移如何保证一致。前言随着互联网业务发展对容灾以及对访问加速、多供应商成本控制等需求的产生，互联网公司的多云部署和跨云迁移逐渐成为刚需，而在此过程中，最困扰运维和研发人员的就是数据的迁移和同步。俗语说 上屋搬下屋，搬洒一箩谷 ，在业务的迁移过程中一旦...

    Tecode 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<