读取顺序：/etc/mysql/my.cnf>/etc/my.cnf>~/.my.cnf
资深数据库专家，专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。
有客户反映有 3 套 MGR 环境全备失败，MySQL 版本为 8.0.18 ，xtrabackup 版本为 8.0.9 。报错信息如下：
墨墨导读：数据是以表空间来维护和存放的。在表空间中包含数据，结构，索引等信息，如何有效使用表空间对于MySQL来说非常重要。
「mysql数据库中日志是重要组成部分，记录着数据库运行期间各种状态信息」。主要有6类：
MySQL中的undo截断还是一个很不错的特性。这让我想起了很久以前看到一个诺大的ibdata,但是却拿它无能为力，想把它收缩唯一的办法就是重建或者重构数据。 Oracle用得久了，总会有一些想法，看起来很平常的技术怎么在MySQL中却无能为力。当然这个念头也有些日子了。 MySQL 5.6中把undo做了剥离，可以指定单独的undo表空间，但是要收缩阶段还是无能为力，这个也算是一个过渡的特性吧，到了MySQL 5.7中，这个功能就可以说是上了正道了，我们可以截断，化被动为主动，这种方式
摘录自：http://gfsunny.blog.51cto.com/990565/1566683
有用户在使用 MySQL 5.7 的数据库时，遇到 undo 暴涨情况，经排查存在一条慢 SQL 执行了上万秒仍没有结束，导致后续事务产生的 undo 不能清理，越来越多。
本文是微信公众号【Java技术江湖】的《重新学习MySQL数据库》其中一篇，本文部分内容来源于网络，为了把本文主题讲得清晰透彻，也整合了很多我认为不错的技术博客内容，引用其中了一些比较好的博客文章，如有侵权，请联系作者。
MySQL几乎成为互联网行业使用的最多的开源关系型数据库，正因如此，MySQL也成为各大互联网公司面试中必问的数据库，尤其是MySQL中的事务实现机制和三大核心日志的实现原理。
undo log是逻辑日志，不是物理日志，如果事务是insert，undo log就是delete的逻辑日志。 所以当一个数据页被事务修改后，再被回滚，逻辑数据是一样的，但是物理数据页已经不一样了。而且数据页中的其他记录可能被其他事务修改，所以也不能物理地回滚整个数据页
大家有没有想过为什么MySQL数据库可以实现主从复制，实现持久化，实现回滚的呢？其实关键在于MySQL里的三种log，分别是：
有用户在使用 MySQL5.7 的数据库时，遇到 undo 暴涨情况，经排查存在一条慢 SQL 执行了上万秒仍没有结束，导致后续事务产生的 undo 不能清理，越来越多
MVCC mulit version concurrency control , 在每个传统数据库上基本上都有实现，最近突然问了自己一句，MYSQL 是怎么实现的这个功能，好像明白又说不清，那自己就来复习一下，MYSQL 到底是怎么来完成这个功能的。
同大多数关系型数据库一样，日志文件是 MySQL 数据库的重要组成部分。MySQL 有几种不同的日志文件，通常包括错误日志文件，二进制日志，通用日志，慢查询日志，等等。这些日志可以帮助我们定位 mysqld 内部发生的事件，数据库性能故障，记录数据的变更历史，用户恢复数据库等等。本文主要描述错误日志文件。
经常看到有人写关于锁的事情，但常常感觉给人一个感觉，数据库的ACID 是通过锁来控制的，实际上数据库的ACID 控制是复杂的，MVCC 就是一个对资源并发访问时的提高并发访问的有效的方法
通过上文《MySQL是如何保证数据不丢失的？》可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。
UNDO LOG 的主要目的是完成事务回滚和MVCC 多版本控制中的读取过去事务的问题。
昨天写了些 MYSQL MVCC ，今天就的搞搞 PostgresQL 的MVCC ，最近从某些网站上获得的信息，PostgresQL的 相关人员的需求量在国内开始增加，但和需求相比，会的人少，所以你懂得。
执行INSTALL PLUGIN命令后，会注册到mysql.plugins表中，所以下次重启该实例会自动加载插件，无需再依赖plugin-load-add
MySQL支持对InnoDB单表空间、通用表空间、系统表空间和Redo、Undo文件进行静态加密。从8.0.16开始支持对Schema和通用表空间设置加密默认值，这就允许对在这些Schema和表空间中的表是否加密进行统一控制；静态加密功能依赖于Keyring组件或插件，MySQL社区版提供的Keyring file插件会将Keyring数据存储在服务器主机的本地文件系统中。
我们知道，MySQL中的redo日志记录了事务的行为，在服务器宕机的时候，可以通过重做事务来达到恢复数据的目的，然而，有的时候，事务还有回滚的需求，也就是说，我们需要知道某条在变成当前情况之前的样子，这种情况下，undo日志就派上用场了。也就是说，undo日志是为了将数据恢复到修改之前的样子，因此在对数据库进行修改的时候，我们需要知道，这个过程中会产生redo日志和undo日志。
MySQL 5.6中开始支持把undo log分离到独立的表空间，并放到单独的文件目录下；这给我们部署不同IO类型的文件位置带来便利，对于并发写入型负载，我们可以把undo文件部署到单独的高速存储设备上。增加了如下几个参数来控制该行为。
事务是MySQL等关系型数据库区别于NoSQL的重要方面，是保证数据一致性的重要手段。本文将首先介绍MySQL事务相关的基础概念，然后介绍事务的ACID特性，并分析其实现原理。
事务是 MySQL 等关系型数据库区别于 NoSQL 的重要方面，是保证数据一致性的重要手段。
来源:https://www.cnblogs.com/kismetv/p/10331633.html
在上篇博客，我们知道了undo log，继续上篇博客，学习另外一种重要的InnoDB事务日志redo log
类型：ext2 3 4 ，xfs 数据。 不管使用什么文件系统，数据内容不会变化，不同的是，存储空间、大小、速度。
这个问题是我当初在面天猫的时候，2面的面试官问我的，我之前已经写过mvcc的文章了，但是在看到我笔记的里的这个问题的时候我准备单独理一遍，所以就有了这个文章。
公司原有的架构：一个展示型的网站，LAMT，MySQL5.1.77版本（MYISAM），50M数据量。
InnoDB存储引擎层产生，物理日志，记录的是对页的修改，innodb1.2版本后，最大512GB
前面我们说了undo日志写入undo页面链表时，先需要把undo page header、undo segment header、undo log header等。每个事务都会有相应的undo链表，如果只存储一点数据不是很浪费吗，于是有了可重用，满足当前链表只有一个页，并且小于总空间的3/4。还介绍了回滚段，默认128个回滚段，每个段有1024个undo slot，每个slot分配给不同的事务，对应一个单独的undo页面链表。Undo日志也会记录redo日志，但临时表的undo日志写入不会记录redo日志，他的记录过程是先修改了数据，则会在系统表空间申请一个rollback segment header页面地址，循环获取，从第0号，第33~127号。分配了回滚段后，在段里查看cache是否存在undo slot，不存在就去rollback_segment_header找到一个undo slot分配该事务，如果没找到，则需要去undo log segment申请一个first undo page
innodb 为了提高磁盘I/O读写性能，存在一个 buffer pool 的内存空间，数据页读入会缓存到 buffer pool，事务的提交则实时更新到 buffer pool，而不实时同步到磁盘（innodb 是按 16KB 一页同步的，一事务可涉及多个数据页，实时同步会造成浪费，随机I/O）。事务暂存在内存，则存在一致性问题，为了解决系统崩溃，保证事务的持久性，我们只需把事务对应的 redo 日志持久化到磁盘即可（redo 日志占用空间小，顺序写入磁盘，顺序I/O）
mysql 数据库作为现在互联网企业首选的数据库，我们程序员就应该对它多一些了解，我在拉勾训练营学到第五阶段啦，了解了mysql 整体架构，记录下来。
如何控制并发是数据库领域中非常重要的问题之一，MySQL为了解决并发带来的问题，设计了事务隔离机制、锁机制、MVCC机制等等，用一整套机制来解决并发问题，本文主要介绍MySQL5.7版本的MVCC机制。
InnoDB的性能和自动崩溃恢复特性，使得它在非事务性存储的需求中也有广泛的应用。
MySQL事务特性之一就是要保证原子性，一组SQL要么全部成功、要么全部失败。当事务进行过程中，如果出现失败或者异常情况要进行回滚，回到之前最初的样子，要这样实现就要需要把之前的数据记录下来。
说来和MySQL倒是有缘，毕业的第一份工作就被分配到了RDS团队，主要负责把MySQL弄到云上做成数据库服务。虽说整天和MySQL打交道，但说实话那段时间并没有很深入的理解MySQL内核，做的事情基本都是围绕着MySQL做管控系统，比较上层。好在周边都是MySQL内核神级人物，在他们的熏陶下多多少少对MySQL的一些基本知识有一些零碎的记录和模糊的认识，这些基础对于今天整理理解MySQL跨行事务模型非常重要。更重要的，有很多不解的地方也可以向大神请教。
MySQL 为我们提供了分布式事务解决方案，在前面的内容中 聊一聊分布式事务的解决方案 提到过 binlog 的同步，其实是 MySQL XA 规范的一个应用，那么 XA 规范是如何定义的，具体又是如何应用的呢？
日志的存在，为数据库的很多功能提供了保障。像用于回滚数据的 undo log，用于恢复数据的 redo log， 以及用于主从备份的 binlog。本文将会大致介绍下数据库里的日志类别，以及重点分析下事务日志的相关知识点。
ACSR（Auto Crash Safey Recovery）自动的故障安全恢复 更新操作 在一行数据被更新时： 1、在使用BEGIN开启事务时，会先给.ibd文件中分配一个TXID号和LSN号，假设为tx_01与lsn1001； 2、在UPDATE执行时，MySQL会找到需更新数据的数据页，并将其内容加载到data buffer pool中，由DBWR（double write）线程记录变更数据页的内容，并且记录好TXID和更新LSN号，此时将产生脏页与脏数据； 3、使用LOGBWR（log doubl
MYSQL 8 发布也是有些日子了，但使用的人数和单位都不多，原因大部分大企业，银行已经开始使用国内的自研的MYSQL 作为主力，同时MYSQL 5.7 在目前使用中并未出现什么重大的缺陷，并且周边的生态都是基于 5.6 5.7 的，所以更换MYSQL 8 是不是吃力不讨好的一件事情，另外网传，并且自己也测试了一些东西，发现MYSQL8 在某些方面尤其是查询的速度来说，并没有快到哪里去，反倒是有可能更慢。
在开始排错之前我们需要知道 Update 在 MySQL 中的生命周期是什么，MySQL 如何执行一个事务的。
记住！ 记住！ 记住！ 上边这张图，她是MySQL更新数据的基础流程，其中包括redo log、bin log、undo log三种日志间的大致关系，好了闲话少说直奔主题。
大部分朋友估计都只知道写sql然后执行，但是并不知道MySQL背后到底是怎么实现的。
我在之前的文章中(【MySQL入门】之MySQL数据库的锁机制（一），【MySQL入门】之MySQL数据库的锁机制（二）)介绍了MySQL的全局锁、表锁和行锁，今天我在来介绍下MySQL的一致性非锁定读、一致性锁定读。再说之前我们先思考个问题，当我们用mysqldump进行逻辑备份时，如果有事务对表进行修改操作，那么我们备份出来的数据是否包含修改后的数据呢？如果mysqldump备份出的数据不包含之后修改的数据，那么他又是怎么保存之前的数据的呢？
在Innodb存储引擎中，后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。此外它会将已经修改的数据文件刷新到磁盘文件中，保证数据库在发生异常的情况下，Innodb能够恢复到正常的运行状态。上一节中我们讲到了redo log的刷盘操作，其实就是后台线程帮忙完成的。
隔离性的实现原理就是锁，因而隔离性也可以称为并发控制、锁等。事务的隔离性要求每个读写事务的对象对其他事务的操作对象能互相分离。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
