MySQL 5.7增强了半同步复制,rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值,由该参数AFTER_SYNC/AFTER_COMMIT两个值选择是否启用增强半同步。
在学习《MySQL技术内幕:SQL编程》一书,并做了笔记。本博客内容是自己学了《MySQL技术内幕:SQL编程》事务编程一章之后,根据自己的理解做的笔记,内容和书本并不一致,不过书本实验都经过自己验证,基于MySQL5.7版本。做笔记的目的是方便自己复习,同时分享出来或许对其他人或许有点帮助
事务(Transaction) 是访问和更新数据库的基本执行单元,一个事务中可能会包含多个 SQL 语句,事务中的这些 SQL 语句要么都执行,要么都不执行,而 MySQL 它是一个关系型数据库,它自然也是支持事务的。事务同时也是区分关系型数据库和非关系型数据库的一个重要的方面。
通俗来讲事务就是多步操作要么全部成功要么全部失败,保证最终状态一致。为了简化应用程序,使其可以忽略一些潜在错误和并发问题,数据库层对事务的ACID特性做了统一支持。
在数据修改的时候,不仅记录了redo,还记录了相对应的undo,如果因为某些原因导致事务失败或回滚了,可以借助该undo进行回滚。
事务是数据库区别于文件系统的重要特性之一,提到事务肯定会想到事务的4个特性ACID,要保证业务的正常使用,必须保证ACID,ACID表示原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability),一个运行良好的事务系统也是要求具备这些特征
REPEATABLE READ是InnoDB的默认隔离级别。MySQL对它有如下的支持:
innodb_flush_log_at_trx_commit 是 MySQL 的一个系统变量,运行环境是 InnoDB 引擎。该变量定义了 InnoDB 在每次事务提交时,如何处理未刷入(flush)的重做日志信息(redo log)。它是 InnoDB 确保 ACID 属性中的持久性(Durability)的关键因素。当数据库发生故障,如崩溃或者断电,这项设置可以保护您的数据不会丢失。
在事务的ACID特性中,原子性(A)、一致性(C)、持久性(D)由undo log和redo log实现,隔离性(I)由锁+MVCC实现
一般Mysql主从复制有三个线程参与,都是单线程:Binlog Dump(主) -> IO Thread (从) -> SQL Thread(从)。
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式,这样从节点不用一直访问主服务器来更新自己的数据,数据的更新可以在远程连接上进行,从节点可以复制主数据库中的所有数据库或者特定的数据库,或者特定的表。
MySQL通过复制(Replication)实现存储系统的高可用。目前,MySQL支持的复制方式有:
Redo log的刷盘操作将会是最终影响MySQL TPS的瓶颈所在。为了缓解这一问题,MySQL使用了组提交,将多个刷盘操作合并成一个,如果说10个事务依次排队刷盘的时间成本是10,那么将这10个事务一次性一起刷盘的时间成本则近似于1。
本文是由爱可生研发团队出品的「图解MySQL」系列文章,不定期更新,但篇篇精品。欢迎大家持续关注~
在MySQL的主从复制架构中,主库上经常会并发的执行很多SQL,只要这些SQL没有产生锁等待,那么同一时间并发好几个SQL线程是没有问题的。
MySQL 事务主要用于处理操作量大,复杂度高的数据。比如说,在人员管理系统中,你删除一个人员,你即需要删除人员的基本资料,也要删除和该人员相关的信息,如信箱,文章等等,这样,这些数据库操作语句就构成一个事务.
数据库中的事务是指对数据库执行一批操作,这些操作最终要么全部执行成功,要么全部失败,不会存在部分成功的情况。
参考:http://www.linuxidc.com/Linux/2015-11/124942.htm
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败,本质上来说,分布式事务就是为了保证不同数据库的数据一致性。
1. 简介 MySQL 5.6引入了基于schema的并行复制,即如果binlog events操作的是不同schema的对象,不是DDL,且操作的对象没有对其他schema的foreign key关联,则这些binlog events在slave上做重放的时候可以并行。slave上依然还是有一条IO线程负责从master拉取binlog并写入relay log,之前负责重放relay log的SQL线程现在作为coordinator线程,根据读取到的relay log里的binlog event,决定是
当客户端A检查还有一张票时,将票卖掉,还没有执行更新数据库的时候,客户端B检查了票数,发现大于0,于是又买了一次票。然后客户端A将票数更新回数据库。于是就出现了同一张票被卖了两次的情况。
数据库如下图所示,所有字段都是int(方便测试),id为主键索引,name为普通索引(唯一索引),age没有索引
前言 这段时间自己会把之前学的东西都总结一遍,希望对自己以后的工作中有帮助。其实现在每天的状态都是很累的,但是我要坚持! 进入我们今天的正题: 为什么MySQL要 有事务呢?事务到底是用来干什么的?我们通过一个例子来说明: 事务广泛的运用于订单系统、银行系统等多种场景。如果有以下一个场景:A用户和B用户是银行的储户。现在A要给B转账500元。那么需要做以下几件事: 1)检查A的账户余额>500元; 2)A账户扣除500元; 3)账户增加500元; 正常的流程走下来
爱可生 DBA 团队成员,负责客户的数据库故障处理以及调优。擅长故障排查及性能优化。对数据库相关技术有浓厚的兴趣,喜欢分析各种逻辑。
MySQL5.6版本支持了并行复制,只是支持的粒度是按库并行。用于决定分发策略的hash表里,key是数据库名
在默认情况下,用户执行的每一条SQL语句都会被当成单独的事务自动提交。如果要将一组SQL语句作为一个事务,则需要先执行以下语句显式地开启一个事务。
爱可生 DBA 团队成员,主要负责 MySQL 故障处理和 SQL 审核优化。对技术执着,为客户负责。
如果回滚到上面设置的保存点s1,那么account表中的数据自然就没有了。这就是回滚事务。
本文介绍了MySQL中的binlog组提交及其在MySQL Replication中的作用。binlog是MySQL中一种二进制日志,用于记录数据库的更改历史。在MySQL Replication中,通过binlog实现主从复制。当主库发生更改时,binlog会记录所有更改,并将更改发送到从库。从库根据binlog中的更改来更新自己的数据,从而保持与主库一致。在MySQL中,使用binlog可以实现多种功能,如灾难恢复、数据迁移、只读实例等。
初次接触二阶段提交,源于想以事务的方式实现对 MongoDB 中多个集合数据的修改,而 MongoDB 本身不支持事务,官方推荐的方案就是使用二阶段提交。
http://www.linuxidc.com/Linux/2015-11/124942.htm
他们有一个共同的字段, 叫做xid, 崩溃恢复的时候, 会按照顺序扫描redolog:
MySQL 为我们提供了分布式事务解决方案,在前面的内容中 聊一聊分布式事务的解决方案 提到过 binlog 的同步,其实是 MySQL XA 规范的一个应用,那么 XA 规范是如何定义的,具体又是如何应用的呢?
在日常开发中,我们常用的存储引擎有 InnoDB 和 MyISAM 两种存储引擎。然而 MyISAM 是不支持事务操作的。
前面一篇,我们学习到了MySQL多版本并发控制(MVCC)实现原理,这一篇我们接着学习MySQL主从复制模式下的延迟解决方案。
MySQL5.7并行复制初理解 我们知道MySQL5.7并行复制引入了两个值last_committed和sequence_number。last_committed表示事务提交的时候,上次事务提交的编号,在主库上同时提交的事务设置成相同的last_committed。如果事务具有相同的last_committed,表示这些事务都在一组内,可以进行并行的回放。这个机制也是Commit-Parent-Based SchemeWL#6314中的实现方式。不过之后,官方对这种模式做了改进,所以最新的并行回放机制
2PC全称是Two-PhaseCommit,翻译过来是二阶段提交,是分布式事务XA规范(XA规范是X/Open DTP定义的交易中间件与数据库之间的接口规范)的实现思路,满足CAP理论的CP,是强一致性事务。
在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴,Buffer Pool是MySQL内存结构中十分核心的一个组成,你可以先把它想象成一个黑盒子。
Mycat 目前没有出来跨分片的事务强一致性支持,目前单库内部可以保证事务的完整性,如果跨库事务,在执行的时候任何分片出错,可以保证所有分片回滚,但是一旦应用发起 commit 指令,无法保证所有分片都成功考虑到某个分片挂的可能性不大所以称为弱 xa。
对这个问题的思考起源于一篇文字,文字中针对 MYSQL的隔离级别中的实现的问题进行了说明 MySQL Repeatable-Read 隔离级别一些误解 - 知乎 (zhihu.com) ,里面写的很详细,这里就不在详述了,感兴趣的同学可以去看,很涨知识,例如我,因为读了这篇文字,对于 PG MYSQL 在MVCC 的实现的问题,有了更深的认知。顺便说一句,写这篇文字的同学是阿里云POLARDB 的数据库开发者。https://zhuanlan.zhihu.com/p/402008512
MySQL作为当下最流行的开源关系型数据库,有一个很关键和基本的能力,就是必须能够保证数据不会丢。那么在这个能力背后,MySQL是如何设计才能保证不管在什么时间崩溃,恢复后都能保证数据不会丢呢?有哪些关键技术支撑了这个能力?本文将为我们一一揭晓。
在之前的文章中,我对MySQL并行复制做过一个简单的介绍,有兴趣可以翻看5月19日的文章《MySQL并行复制解析》。今天针对这个问题,补充一些知识点。
该同学的回答是 “配置禁用事务”。 还有些同学说,可以“关闭 undo log 和 redo log”。
当用户AA向用户BB转账,就需要执行两个SQL语句,一个是用户AA减少100,另一个是用户BB增加100,SQL如下:
InnoDB存储引擎层产生,物理日志,记录的是对页的修改,innodb1.2版本后,最大512GB
提示:公众号展示代码会自动折行,建议横屏阅读 「第一部分 GTID简介」 在MySQL5.6引入了GTID(Global Transaction Identifier)特性,它可以在集群中唯一标识一个事务,在MySQL主从复制时,从节点可以使用GTID来确定复制位点,用于取代使用binlog文件偏移量的传统方式,在发生主备切换时从节点可以自动在新主上找到正确的复制位置,大大简化了复杂复制拓扑下集群的维护,也减少了人为设置复制位点发生误操作的风险,另外,基于GTID的复制可以跳过已经执行过的事务,减少了数据发
事务是数据库最为重要的机制之一,凡是使用过数据库的人,都了解数据库的事务机制,也对ACID四个基本特性如数家珍。但是聊起事务或者ACID的底层实现原理,往往言之不详,不明所以。所以,今天我们就一起来分析和探讨InnoDB的事务机制,希望能建立起对事务底层实现原理的具体了解。
START TRANSACTION 或者 BEGIN ,作用是显式开启一个事务。
首先,InnoDB会判读缓冲池里是否存在 id = 1 这条数据,如果不存在则从磁盘中加载到缓冲池中,而且还会对这行数据加独占锁,防止多个sql同时修改这行数据。
领取专属 10元无门槛券
手把手带您无忧上云