1. 什么是两阶段提交 1.1 binlog 与 redolog 1.2 两阶段提交 2. 为什么需要两阶段提交 3. 小结 为什么要两阶段提交？一阶段提交不行吗？ 小伙伴们知道，MySQL 中的事务是两阶段提交，我们见到的很多分布式事务也都是两阶段提交的，例如 Seata，那么为什么要两阶段提交呢？一次直接提交了不行吗？今天我们来聊聊这个话题。 关于分布式事务 seata，不懂的小伙伴可以参考松哥之前的文章，传送门： 五分钟带你体验一把分布式事务！so easy！ 看了那么多博客，还是不懂 TCC，不妨看
假设当前 ID=2 的行，字段 c 的值是 0，再假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了 crash，会出现什么情况呢？
在 MySQL架构（二）SQL 更新语句是如何执行的？中说到了 redo log 和 binlog 日志文件，在事务执行过程中，会分两个阶段写入这两份日志文件中，这也是为了保证两份日志之间的一致性，即维护 mysql 的数据一致性。
在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。在关系型数据库中，由于存在事务机制，可以保证每个独立节点上的数据操作满足 ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况，所以在分布式的场景下，如果不添加额外的机制，多个节点之间理论上无法达到一致的状态。
● 原子性：一个事务对状态的改变是原子的，要么都发生，要么都不发生，这些改变包括数据库的改变、消息以及对转换器的操作。
他们有一个共同的字段, 叫做xid, 崩溃恢复的时候, 会按照顺序扫描redolog:
分布式事务，我们已经给小伙伴介绍了整体内容： 一文搞明白分布式事务解决方案！真的 so easy！ AT 模式的实现： 手把手带领小伙伴们写一个分布式事务案例！ AT 模式在多数据源中的应用： Spring Boot 多数据源如何处理事务？教你一招！ TCC 模式的实现： 听说 TCC 不支持 OpenFeign？这个坑松哥必须给大家填了！ 今天我们就一起来看下另一种模式，XA 模式！ 其实我觉得 seata 中的四种不同的分布式事务模式，学完 AT、TCC 以及 XA 就够了，Saga 不好玩，而且长事务
MySQL中的两阶段提交协议（Two-Phase Commit Protocol）
此篇博客主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下:
这篇文章将给大家介绍一下对分布式事务的一些见解，并讲解分布式事务处理框架 TX-LCN 的执行原理，错误之处望各位不吝指正。
爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。
明显不会，磁盘IO太慢了，如果每个请求过来 MySQL 都要写磁盘，磁盘肯定扛不住。
MySQL作为当下最流行的开源关系型数据库，有一个很关键和基本的能力，就是必须能够保证数据不会丢。那么在这个能力背后，MySQL是如何设计才能保证不管在什么时间崩溃，恢复后都能保证数据不会丢呢？有哪些关键技术支撑了这个能力？本文将为我们一一揭晓。
一条数据在更新过程当中，如果中途 mysql crash 了，mysql 是如何保证数据的一致性和持久性的？在这个过程中 mysql 的日志系统起到了至关重要的作用。本文将会介绍 mysql 中的 undo log、redo log 和 bin log 在这其中的作用。
每个访问事务表 都会启动一个statement事务。如果语句成功，则提交statement事务。如果语句失败，则回滚事务。statement事务的提交是不持久的——每个statement事务都嵌套在normal事务中，如果回滚normal事务，被包含的statement事务所影响的数据也会被撤销。在 autocommit 自动提交模式下，normal事务与statement事务等价。
松哥最近正在录制 TienChin 项目视频～采用 Spring Boot+Vue3 技术栈，里边会涉及到各种好玩的技术，小伙伴们来和松哥一起做一个完成率超 90% 的项目，戳戳戳这里-->TienChin 项目配套视频来啦。 ---- 分布式事务，咱们前边也聊过很多次了，网上其实也有不少文章在介绍分布式事务，不过里边都会涉及到不少专业名词，看的大家云里雾里，所以还是有一些小伙伴在微信上问我。 那么今天，我就再来一篇文章，和大家捋一捋这个话题。以下的内容主要围绕阿里的 seata 来和大家解释。 1. 什么
在分布式事务中，通常使用两阶段协议或三阶段协议来保障分布式事务的正常运行，它也是 X/Open 公司定义的一套分布式事务标准。
今天来聊聊InnoDB是如何保证redo log与binlog两份日志之间的逻辑一致。
下图说明了一个DTP系统的本地实例，其中AP调用TM来构造事务。这些框表示X/Open DTP模型中的软件组件。箭头指示控制流的方向。
最近行情越来越卷了，给大家整理了互联网大厂15道经典MySQL日志面试题，希望大家都能找到理想的offer
面试时候，经常会被问到什么是事务、事务的特征、事务的隔离级别这些八股文问题，凭死记硬背通常也可回答的七七八八。但是面试官一旦换个角度问这些问题，有时候可能就语塞了。
为了规范分布式事务的管理,X/OPEN 提出了分布式事务处理规范XA协议，XA规范了TM与RM之间的通信接口，在TM与多个RM之间形成一个双向通信桥梁，从而在多个数据库资源下保证ACID四个特性。目前知名的数据库，如Oracle, DB2,mysql等，都是实现了XA接口的，都可以作为RM。
大家好，我是田螺哥。金九银十已经来了，整理了15道经典MySQL日志面试题，希望对大家有帮助。
redo log包括两部分内容，分别是内存中的日志缓冲(redo log buffer)和磁盘上的日志文件(redo log file)。
参考：http://www.linuxidc.com/Linux/2015-11/124942.htm
http://www.linuxidc.com/Linux/2015-11/124942.htm
刚看见这个题目的时候还是有点懵逼的，后来才反应过来其实问的就是 redo log 的两阶段提交
上一篇：《分布式之事务解决方案》 我们对于分布式事务解决方案有了一个汇总，分布式事务产生的原因，其解决方案。上一篇还有很多知识点没有讲到，比如二段提交，三段提交等。今天我们来一起探索一下分布式事务之二段提交三段提交算法。
事务是数据库系统中非常有趣也非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全不执行；在 SOA 与微服务架构大行其道的今天，在分布式的多个服务中保证业务的一致性就需要我们实现分布式事务。
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
在DML语句执行的过程中，主要会涉及到两个日志——redo log和bin log，而这两个日志是数据库 WAL (Write Ahead Logging，先写日志再写磁盘提高效率) 技术的两大主角。下面我来介绍一下这两个日志。
事务流程的核心思想是将多个需要一起执行的操作视为一个整体，保证其在数据库中的一致性和完整性。如果在事务执行过程中发生了错误，可以通过回滚操作来保证数据的一致性，否则可以通过提交操作来永久保存修改。
我在第 2 篇文章《MySQL深入学习第二篇 － 一条SQL更新语句是如何执行的？》中，和你讲到 binlog（归档日志）和 redo log（重做日志）配合崩溃恢复的时候，用的是反证法，说明了如果没有两阶段提交，会导致 MySQL 出现主备数据不一致等问题。
我在第 2 篇文章《MySQL实战第二讲 － 一条SQL更新语句是如何执行的？》中，和你讲到 binlog（归档日志）和 redo log（重做日志）配合崩溃恢复的时候，用的是反证法，说明了如果没有两阶段提交，会导致 MySQL 出现主备数据不一致等问题。
上一篇咱们了解了MySQL 的执行过程，其中设计连接器、分析器、优化器、执行器和存储引擎，接下来我将给大家讲解一下在MySQL中一条更新语句是如何执行。我相信大家可能听公司的DBA提起过，可以将数据恢复到半个月内任意时间的状态，是不是感觉很高大上，很厉害呢，下面我就将这个谜底一步一步解开
通过上文《MySQL是如何保证数据不丢失的？》可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。
X/Open DTP(Distributed Transaction Process)是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。
Mysql cluster数据节点组内主从同步采用的是同步复制， 来保证组内节点数据的一致性 原理类似tcp的四次握手 一般通过两阶段提交 (why)协议来实现，一般工作过程如下： a)Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。 b)每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。 c)Master等待所有Slave发送OK或ABORT消息 如果Master收到所有 Slave的OK消息
数据库系统是属于既要又要的系统，既要保证数据库的正确性，又要高并发。在高并发的场景下保证数据库的正确性，关键在于保证事务的 ACID。以 ACID 的 I（Isolation） 为例，I 表示的是在并发事务的场景下，事务并发执行的效果与事务串行执行的效果完全相同，这种隔离级别就是所说的可串行化隔离级别，但是可串行化隔离级别的代价比较大，往往伴随着大量的冲突等待或者冲突失败。
我的网站上一直有好多人留言催更 MySQL 日志（undo log、redo log、binlog）的文章。
我有一个老朋友，我们叫他熊猫。发际线及将触碰到后脑勺，大框金丝眼镜也掩盖不住那黝黑的眼圈，显得格外的“程序员”；穿着也非常不拘一格，上半身是衬衣西服，下半身是牛仔裤配拖鞋~
Xa主要规定了RM与TM之间的交互，下面来看下XA规范中定义的RM 和 TM交互的接口：
陈某的《Spring Cloud Alibaba实战项目》 视频教程已经录完了，涉及到Alibaba的各种中间件、OAuth2微服务认证鉴权、全链路灰度发布、分布式事务实战，戳这里--->Spring Cloud Alibaba 实战 视频专栏 开放订阅~
还是先在粉板上记一下方便。如果掌柜没有粉板，每次记账都翻账本，效率是不是低死啦？ MySQL也有这个问题，若每次更新操作都写进磁盘，然后磁盘也要找到对应记录，然后再更新，整个过程IO成本、搜索成本都很高。 何解？采用类似酒掌柜粉板的思路。
Server层包含MySQL的大多数核心服务，和所有内置函数，所有跨存储引擎功能的实现
是在是抱歉，本来每周一都是 POSTGRESQL 的，但由于某些原因这周更换顺序，下周会恢复的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
