现在主流的数据库系统的故障恢复逻辑都是基于经典的ARIES协议，也就是基于undo日志+redo日志的来进行故障恢复。redo日志是物理日志，一般采用WAL(Write-Ahead-Logging)机制，所以也称redo日志为wal日志，redo日志记录了所有数据的变更，undo日志是逻辑日志，记录了所有操作的前镜像，方便异常时进行回滚。用户在提交事务时，只要确保写redo日志成功即可，并不需要对应的数据页也实时落盘，这套机制的基本思想是利用空间换时间，用户事务的更新实际上在数据页和redo日志中记录了两份，传统的数据库存储引擎都是基于B+Tree来组织数据页，因此刷数据页是离散小块IO，而写redo是顺序IO，对磁盘介质更友好，而且OLTP场景下，业务对RT(ResponseTime)也比较敏感，所以这套机制非常流行。
针对现状,写一个主库,挂着多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗？
今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种：
原子性是数据库事务的核心特性之一，它要求事务中的所有操作要么全部完成，要么全部不完成。这种“全或无”的特性确保了数据库在事务处理过程中的一致性。在MySQL中，原子性的实现主要依赖于事务日志，特别是redo log（重做日志）和undo log（撤销日志）。
MySQL事务是什么，它就是一组数据库的操作，是访问数据库的程序单元，事务中可能包含一个或者多个 SQL 语句。这些SQL 语句要么都执行、要么都不执行。我们知道，在MySQL 中，有不同的存储引擎，有的存储引擎比如MyISAM 是不支持事务的，所以说MySQL 事务实际上是发生在 存储引擎部分。
canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了MySQL（也支持mariaDB）。 canal 就是一个同步增量数据的一个工具。
你们有没有做 MySQL 读写分离？如何实现 MySQL 的读写分离？MySQL 主从复制原理的是啥？如何解决 MySQL 主从同步的延时问题？
MySQL中有两个重要的日志模块，分别是redo log（重做日志）和binlog（归档日志）。当我们学习MySQL的时候，这两部分内容是绕不开的，本文我将来详细的介绍一下这两个日志模块，它们在设计上有很多好玩的地方，一些思想也可以在我们工作中使用。
昨天的内容中，我们介绍了MySQL中的MTR的概念，它是指最小的原子事务操作。当redo log以MTR为单位提交时，需要借助mutex这个轻量的锁，在该锁的保护下，MySQL做了2件事情：
Bbuffer 与 Cache 非常类似，因为它们都用于存储数据数据，被应用层读取字节数据。在很多场合它们有着相同的概念:
看过我之前文章《一条Update语句的执行过程是怎样的？》的朋友都基本知道【点击文章传送门~🙌】，在整个Update更新语句中会涉及到三种日志，分别是undo log(回滚日志）、redo log (重做日志) 、binlog (归档日志)，也有两阶段提交，没看过的不要紧，可以结合本篇文章一起看，会有1+1>2的效果。
之前几周有幸被京东智联云的市场同事推荐参与麦思博的一个视频课程的录制，题目是与MongoDB相关的内容。在ppt里也写到了推荐学员可以对比参照其他数据的原理和特点，来学习和理解MongoDB的一些原理和特点，而自己最近在学习的时候，正好发现了一处MongoDB与MySQL设计非常相似的地方，即今天要介绍的写确认相关的内容。
数据的一致性和完整性对于在线业务的重要性不言而喻，如何保证数据不丢呢？今天我们就探讨下关于数据的完整性和强一致性，MySQL做了哪些改进。
MySQL作为当下最流行的开源关系型数据库，有一个很关键和基本的能力，就是必须能够保证数据不会丢。那么在这个能力背后，MySQL是如何设计才能保证不管在什么时间崩溃，恢复后都能保证数据不会丢呢？有哪些关键技术支撑了这个能力？本文将为我们一一揭晓。
今天想和大家聊一聊 MySQL 中的 redo log，其实最早我是想聊两阶段提交的，后来想想可能有小伙伴还不了解 binlog，所以就先整了一篇 binlog： 手把手教你玩 MySQL 删库不跑路，直接把 MySQL 的 binlog 玩溜！ MySQL删库不跑路（视频版） binlog 大家懂了之后，接下来还差个 redo log，redo log 大家也懂了，那么再讲两阶段提交相信小伙伴们就很容易懂了，咱们一步一步来。 1. 谁的 redo log 学习 redo log，我觉得首先要搞明白一个问
在上一篇文章中，我们从一个查询语句的执行流程知道了 MySQL 架构可分为 Server 层和存储引擎层，以及各个层级的具体部件。
这是一条很简单的更新SQL，从MySQL服务端接收到SQL到落盘，先后经过了MySQL Server层和InnoDB存储引擎。
MySQL 中的日志比较重要的有 binlog（归档日志）、redo log（重做日志）以及 undo log，那么跟我们本文相关的主要是 binlog，另外两个日志松哥将来有空了再和大家详细介绍。 1. binlog binlog 我们中文一般称作归档日志，如果大家看过松哥之前发的 MySQL 主从搭建，应该对这个日志有印象，当我们搭建 MySQL 主从的时候就离不开 binlog（传送门：MySQL8 主从复制踩坑指南）。 binlog 是 MySQL Server 层的日志，而不是存储引擎自带的日志，
其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。
谁也不能保证计算机系统能够永远无故障的执行下去。网络波动、磁盘损坏等现网高频故障，机房掉电、服务器硬件失效等低频却又致命的故障，时刻考验着我们的系统。
今天给大家分享MySQL中的三种核心日志——Redo Log、Undo Log和Binlog，涵盖它们的介绍、作用、存储位置、写入机制、记录格式、特点以及如何管理这些日志。
MySQL 为我们提供了分布式事务解决方案，在前面的内容中 聊一聊分布式事务的解决方案 提到过 binlog 的同步，其实是 MySQL XA 规范的一个应用，那么 XA 规范是如何定义的，具体又是如何应用的呢？
SQL 语句执行慢的原因是面试中经常会被问到的，对于服务端开发来说也是必须要关注的问题。
mysql的"双1验证"指的是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置，这两个是是控制MySQL 磁盘写入策略以及数据安全性的关键参数。下面从参数含义，性能，安全角度阐述两个参数为不同的值时对db 性能,数据的影响。
当我们需要修改一个记录时，数据库会先根据条件找到要修改的数据，然后执行修改写入操作，因此我们再分析写操作的执行过程时，其实是包含读语句的执行过程的。
1. 什么是两阶段提交 1.1 binlog 与 redolog 1.2 两阶段提交 2. 为什么需要两阶段提交 3. 小结 为什么要两阶段提交？一阶段提交不行吗？ 小伙伴们知道，MySQL 中的事务是两阶段提交，我们见到的很多分布式事务也都是两阶段提交的，例如 Seata，那么为什么要两阶段提交呢？一次直接提交了不行吗？今天我们来聊聊这个话题。 关于分布式事务 seata，不懂的小伙伴可以参考松哥之前的文章，传送门： 五分钟带你体验一把分布式事务！so easy！ 看了那么多博客，还是不懂 TCC，不妨看
2023 年某一天周末，新手程序员小明因为领导安排的一个活来到公司加班，小明三下五除二，按照领导要求写了一个跑批的数据落库任务在测试环境执行 ，突然间公司停电了，小明大惊，“糟了，MySQL 还在跑任务，会不会因为突然断电，导致数据库崩了”。
MySQL的最新版本8.0.20正式发行。与之前8.0的系列版本一样，这次的发行版，除了包含缺陷修复，也同样包扩新功能。让我们快速浏览一下。
在多个MySQL实例之间进行数据同步和复制是一项关键的任务，它可以确保数据的一致性和可靠性。下面将详细介绍如何实现MySQL实例之间的数据同步和复制。
根据云厂商Benchmark结果，4核8G机器运行 MySQL 5.7 时，可支撑TPS 500，QPS 10000。 但随着数据量的增大，读写并发的增加，系统可用性要求的提升，单机 MySQL 出现危机：
上一篇咱们了解了MySQL 的执行过程，其中设计连接器、分析器、优化器、执行器和存储引擎，接下来我将给大家讲解一下在MySQL中一条更新语句是如何执行。我相信大家可能听公司的DBA提起过，可以将数据恢复到半个月内任意时间的状态，是不是感觉很高大上，很厉害呢，下面我就将这个谜底一步一步解开
我们常常听人说，只要你愿意，MySQL 可以恢复至半个月甚至一个月以内的任何一个状态。网上也有很多删库跑路的段子。。。
有个水友提问： 沈老师，我们有一次MySQL崩溃，重启后发现有些已经提交的事务对数据的修改丢失了，不是说事务能保证ACID特性么，想问下什么情况下可能导致“事务已经提交，数据却丢失”呢？ 这个问题有点复杂，得先从redo log说起。 为什么要有redo log？ 事务提交后，必须将事务对数据页的修改刷(fsync)到磁盘上，才能保证事务的ACID特性。 这个刷盘，是一个随机写，随机写性能较低，如果每次事务提交都刷盘，会极大影响数据库的性能。 随机写性能差，有什么优化方法呢？ 架构设计中有两个常见的优化方法
MySQL 的最新版本 8.0.20 正式发行。与之前 8.0 的系列版本一样，这次的发行版，除了包含缺陷修复，也同样包括新功能。让我们快速浏览一下。
当每一个线程开启一个事务时，MySQL会自动分配一个大小为 binlog_cache_siz的缓存。
随着数据量的增大，读写并发的增加，系统可用性要求的提升，单机 MySQL 出现危机：
这是图解MySQL的第2篇文章，这篇文章会通过一条SQL更新语句的执行流程让大家清楚地明白：
update语句是如何执行 , 如何将执行后的新数据持久化在磁盘中 可以假设两种情境：
数据库服务器压力增大，增加多台mysql数据库服务器，需要建立主从复制机制保证数据一致同步。
作为后端开发，日常操作数据库最常用的是写操作和读操作。读操作我们下边会讲，这个分类里我们主要来看看写操作时为什么会导致 SQL 变慢。
表空间(Tablespace)：一个mysql实例，及一个数据库实例，可以对应多个表空间(ibd文件)，用于存储记录，索引等数据。
请读者注意：本文基于 GreatSQL 8.0.25 & MySQL 5.7.7-RC版本，在 MySQL8.0.30 Redo 发生变化，详情见： MySQL 8.0.30动态redo log初探
MySQL WAL（Write-Ahead Logging）技术：是 MySQL 数据库的一种重要机制，主要关于数据库系统中的事务处理和日志管理。
事情是这样的，我负责我司的报表系统，小胖是我小弟。某天他手贱误删了一条生产的数据。被用户在群里疯狂投诉质问，火急火燎的跑来问我怎么办。我特么冷汗都出来了，训斥了他一顿：蠢，蠢得都可以进博物馆了，生产的数据能随便动？
概述 不怕出问题，就怕出问题找不到原因 运维团队一般会有个需求就是记录运维或者开发同事在服务器上的操作记录，比如进行一些常规审核或者是服务器被黑了、服务器日志被删的情况需要知道发生过什么事情，今天和大家分享下我们现在的服务器的shell和mysql操作日志记录的DIY方案。 团队内部之前有测试过一些堡垒机硬件，但终端操作方面不够人性化，不够灵活，而且价格昂贵，硬件容易形成单点故障。当然也接触过一些开源的方案，比如可以直接用ttyrec对终端进行录制，并且支持文本匹配，但是在实际使用中发现过严重bug，
今天简单写写MySQL中跟数据安全相关的两个关键参数吧，一个是innodb_flush_log_at_trx_commit，另外一个是sync_binlog，首先我们来看看这两个参数分别是什么意思吧：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
