mysql互为主从的环境,更新一条语句同时提交,为什么会出现数据不一致?

简介:

mysql互为主从的环境,更新一条语句同时提交,为什么会出现数据不一致?


m1:


begin;

update t1 set c2='b1' where c1=2;

commit;


m2:


begin;

update t1 set c2='b2' where c1=2;

commit;


m1和m2同时提交,复制不会报错,但是m1和m2的数据不一致,为什么?

因为sql_thread线程根据主键更新数据,不会校验行数据


如何避免这种问题:

只在单节点进行写入,如 keepalived+双主,MGR,PXC如果多节点写入都有这种问题发生。


例1:

表有主键和自增的情况:

root@localhost [testdb]>show create table t1\G

*************************** 1. row ***************************

       Table: t1

Create Table: CREATE TABLE `t1` (

  `c1` int(11) NOT NULL AUTO_INCREMENT,

  `c2` varchar(10) DEFAULT NULL,

  PRIMARY KEY (`c1`)

) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8


m1: m2:

root@localhost [testdb]>select * from t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | aaa  |

|  2 | bbb  |

|  3 | ccc  |

|  4 | ccc  |

|  6 | ddd  |

|  8 | eee  |

+----+------+

root@localhost [testdb]>select * from t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | aaa  |

|  2 | bbb  |

|  3 | ccc  |

|  4 | ccc  |

|  6 | ddd  |

|  8 | eee  |

+----+------+

root@localhost [testdb]>begin; root@localhost [testdb]>begin;
root@localhost [testdb]>update t1 set c2='b1' where c1=2; root@localhost [testdb]>update t1 set c2='b2' where c1=2;

root@localhost [testdb]>select * from t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | aaa  |

|  2 | b1   |

|  3 | ccc  |

|  4 | ccc  |

|  6 | ddd  |

|  8 | eee  |

+----+------+

root@localhost [testdb]>select * from t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | aaa  |

|  2 | b2   |

|  3 | ccc  |

|  4 | ccc  |

|  6 | ddd  |

|  8 | eee  |

+----+------+

root@localhost [testdb]>commit; root@localhost [testdb]>commit;

root@localhost [testdb]>select * from t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | aaa  |

|  2 | b2   |

|  3 | ccc  |

|  4 | ccc  |

|  6 | ddd  |

|  8 | eee  |

+----+------+

root@localhost [testdb]>select * from t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | aaa  |

|  2 | b1   |

|  3 | ccc  |

|  4 | ccc  |

|  6 | ddd  |

|  8 | eee  |

+----+------+

总结:update一条记录同时提交,有主键的情况下,sql_thread是根据主键匹配行记录,不会校验行数据,所以m1更新了m2中表的记录,m2更新了m1中表的记录。


例2:有没有主键同时更新一行数据的情况:


root@localhost [testdb]>show create table t2\G

*************************** 1. row ***************************

       Table: t2

Create Table: CREATE TABLE `t2` (

  `c1` int(11) DEFAULT NULL,

  `c2` varchar(20) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8


m1 m2

root@localhost [testdb]>select * from t2;

+------+------+

| c1   | c2   |

+------+------+

|    1 | aaa  |

|    2 | bbb  |

+------+------+

root@localhost [testdb]>select * from t2;

+------+------+

| c1   | c2   |

+------+------+

|    1 | aaa  |

|    2 | bbb  |

+------+------+

root@localhost [testdb]>begin; root@localhost [testdb]>begin;
root@localhost [testdb]>update t2 set c2='b1' where c1=2; root@localhost [testdb]>update t2 set c2='b2' where c1=2;

root@localhost [testdb]>select * from t2;

+------+------+

| c1   | c2   |

+------+------+

|    1 | aaa  |

|    2 | b1   |

+------+------+

root@localhost [testdb]>select * from t2;

+------+------+

| c1   | c2   |

+------+------+

|    1 | aaa  |

|    2 | b2   |

+------+------+

root@localhost [testdb]>commit; root@localhost [testdb]>commit;

root@localhost [testdb]>select * from t2;

+------+------+

| c1   | c2   |

+------+------+

|    1 | aaa  |

|    2 | b1   |

+------+------+

root@localhost [testdb]>select * from t2;

+------+------+

| c1   | c2   |

+------+------+

|    1 | aaa  |

|    2 | b2   |

+------+------+

root@localhost [testdb]>show slave status\G

Last_Errno: 1032

                   Last_Error: Could not execute Update_rows event on table testdb.t2; Can't find record in 't2', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log mysql-bin.000013, end_log_pos 759

root@localhost [testdb]>show slave status\G 

Last_Errno: 1032

                   Last_Error: Could not execute Update_rows event on table testdb.t2; Can't find record in 't2', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log mysql-bin.000026, end_log_pos 3064

总结:update一条记录同时提交,有没有主键的情况下,sql_thread是根据全表扫描匹配行记录,所以m1更新在m2中找不到需要更新的行,报1032错误,m2更新在m1中找不到需要更新的行,也报1032错误。




本文转自 Darren_Chen 51CTO博客,原文链接:http://blog.51cto.com/darrenmemos/1924073,如需转载请自行联系原作者

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
|
SQL 人工智能 关系型数据库
如何实现MySQL百万级数据的查询?
本文探讨了在MySQL中对百万级数据进行排序分页查询的优化策略。面对五百万条数据,传统的浅分页和深分页查询效率较低,尤其深分页因偏移量大导致性能显著下降。通过为排序字段添加索引、使用联合索引、手动回表等方法,有效提升了查询速度。最终建议根据业务需求选择合适方案:浅分页可加单列索引,深分页推荐联合索引或子查询优化,同时结合前端传递最后一条数据ID的方式实现高效翻页。
676 0
|
存储 关系型数据库 MySQL
在CentOS 8.x上安装Percona Xtrabackup工具备份MySQL数据步骤。
以上就是在CentOS8.x上通过Perconaxtabbackup工具对Mysql进行高效率、高可靠性、无锁定影响地实现在线快速全量及增加式数据库资料保存与恢复流程。通过以上流程可以有效地将Mysql相关资料按需求完成定期或不定期地保存与灾难恢复需求。
958 10
|
关系型数据库 MySQL Java
安装和配置JDK、Tomcat、MySQL环境,以及如何在Linux下更改后端端口。
遵循这些步骤,你可以顺利完成JDK、Tomcat、MySQL环境的安装和配置,并在Linux下更改后端端口。祝你顺利!
845 11
|
SQL 存储 缓存
MySQL 如何高效可靠处理持久化数据
本文详细解析了 MySQL 的 SQL 执行流程、crash-safe 机制及性能优化策略。内容涵盖连接器、分析器、优化器、执行器与存储引擎的工作原理,深入探讨 redolog 与 binlog 的两阶段提交机制,并分析日志策略、组提交、脏页刷盘等关键性能优化手段,帮助提升数据库稳定性与执行效率。
399 0
|
存储 SQL 缓存
mysql数据引擎有哪些
MySQL 提供了多种存储引擎,每种引擎都有其独特的特点和适用场景。以下是一些常见的 MySQL 存储引擎及其特点:
419 0
|
运维 算法 机器人
阿里云AnalyticDB具身智能方案:破解机器人仿真数据、算力与运维之困
本文将介绍阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL推出的全托管云上仿真解决方案,方案采用云原生架构,为开发者提供从开发环境、仿真计算到数据管理的全链路支持。
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
1468 1
|
存储 人工智能 OLAP
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
AI上下文工程是优化大模型交互的系统化框架,通过管理指令、记忆、知识库等上下文要素,解决信息缺失、长度溢出与上下文失效等问题。依托AnalyticDB等技术,实现上下文的采集、存储、组装与调度,提升AI Agent的准确性与协同效率,助力企业构建高效、稳定的智能应用。

推荐镜像

更多