首页
技术小册
AIGC
面试刷题
技术文章
MAGENTO
云计算
视频课程
源码下载
PDF书籍
「涨薪秘籍」
登录
注册
01 | 基础架构:一条SQL查询语句是如何执行的?
02 | 日志系统:一条SQL更新语句是如何执行的?
03 | 事务隔离:为什么你改了我还看不见?
04 | 深入浅出索引(上)
05 | 深入浅出索引(下)
06 | 全局锁和表锁 :给表加个字段怎么有这么多阻碍?
07 | 行锁功过:怎么减少行锁对性能的影响?
08 | 事务到底是隔离的还是不隔离的?
09 | 普通索引和唯一索引,应该怎么选择?
10 | MySQL为什么有时候会选错索引?
11 | 怎么给字符串字段加索引?
12 | 为什么我的MySQL会“抖”一下?
13 | 为什么表数据删掉一半,表文件大小不变?
14 | count(*)这么慢,我该怎么办?
15 | 答疑文章(一):日志和索引相关问题
16 | “order by”是怎么工作的?
17 | 如何正确地显示随机消息?
18 | 为什么这些SQL语句逻辑相同,性能却差异巨大?
19 | 为什么我只查一行的语句,也执行这么慢?
20 | 幻读是什么,幻读有什么问题?
21 | 为什么我只改一行的语句,锁这么多?
22 | MySQL有哪些“饮鸩止渴”提高性能的方法?
23 | MySQL是怎么保证数据不丢的?
24 | MySQL是怎么保证主备一致的?
25 | MySQL是怎么保证高可用的?
26 | 备库为什么会延迟好几个小时?
27 | 主库出问题了,从库怎么办?
28 | 读写分离有哪些坑?
29 | 如何判断一个数据库是不是出问题了?
30 | 答疑文章(二):用动态的观点看加锁
31 | 误删数据后除了跑路,还能怎么办?
32 | 为什么还有kill不掉的语句?
33 | 我查这么多数据,会不会把数据库内存打爆?
34 | 到底可不可以使用join?
35 | join语句怎么优化?
36 | 为什么临时表可以重名?
37 | 什么时候会使用内部临时表?
38 | 都说InnoDB好,那还要不要使用Memory引擎?
39 | 自增主键为什么不是连续的?
40 | insert语句的锁为什么这么多?
41 | 怎么最快地复制一张表?
42 | grant之后要跟着flush privileges吗?
43 | 要不要使用分区表?
44 | 答疑文章(三):说一说这些好问题
45 | 自增id用完怎么办?
当前位置:
首页>>
技术小册>>
MySQL 实战 45 讲
小册名称:MySQL 实战 45 讲
### 23 | MySQL是怎么保证数据不丢的? 在数据库管理系统中,确保数据的完整性和持久性是所有数据库设计者和运维人员最为关心的核心问题之一。MySQL,作为最流行的开源关系型数据库管理系统之一,通过一系列复杂的机制和策略来确保即使在面对系统崩溃、硬件故障或人为错误等极端情况下,用户的数据也能得到有效保护,不会丢失。本章节将深入探讨MySQL是如何通过其内部机制来保障数据不丢失的。 #### 一、事务日志(Transaction Logs) MySQL通过事务日志来实现数据的持久性和一致性。事务日志是记录数据库所有修改操作(如INSERT、UPDATE、DELETE)的日志,它确保即使数据库系统发生故障,也能通过日志中的记录来恢复数据到某一特定状态。MySQL中主要涉及到两种类型的事务日志:重做日志(Redo Log)和二进制日志(Binary Log)。 ##### 1. 重做日志(Redo Log) 重做日志是InnoDB存储引擎特有的日志类型,用于记录事务中对数据库所做的修改操作。这些修改首先被写入到内存中(通常是InnoDB的Buffer Pool),然后异步地刷新到磁盘上的重做日志文件中。在数据库系统发生故障时,InnoDB可以利用重做日志文件中的记录来重做(Redo)那些尚未写入磁盘的修改操作,从而确保数据的持久性。 重做日志以固定大小的日志文件组形式存在,并采用循环写入的方式。当日志文件组满时,会从头开始覆盖旧的日志记录,但InnoDB会确保在覆盖之前,相关的数据修改已经持久化到数据文件中。此外,InnoDB还提供了“检查点”(Checkpoint)机制,定期将Buffer Pool中的修改同步到磁盘上,并更新重做日志的位置信息,以减少恢复时需要重做的日志量。 ##### 2. 二进制日志(Binary Log) 二进制日志记录了所有的DDL(数据定义语言)和DML(数据操作语言)语句(除了SELECT和SHOW等不修改数据的语句),以及这些语句执行时的时间戳和相关信息。与重做日志不同,二进制日志是MySQL层面上的日志,不仅限于InnoDB存储引擎,还适用于MyISAM等其他存储引擎(尽管MyISAM不依赖二进制日志进行恢复)。 二进制日志的主要用途包括复制(Replication)和数据恢复。在复制场景中,从服务器通过读取主服务器的二进制日志文件来同步数据变更。而在数据恢复时,管理员可以利用二进制日志中的记录来恢复或回滚到特定的时间点或操作点。 #### 二、崩溃恢复(Crash Recovery) MySQL的崩溃恢复机制依赖于上述的事务日志。当数据库系统意外崩溃(如电源故障、系统崩溃等)后重启时,MySQL会自动执行崩溃恢复过程,以确保数据的一致性和完整性。 ##### 1. InnoDB的崩溃恢复 对于InnoDB存储引擎,崩溃恢复主要依赖于重做日志。启动过程中,InnoDB会检查重做日志的状态,并执行以下步骤: - **回滚未提交的事务**:扫描重做日志,识别出那些在崩溃时尚未提交的事务,并通过回滚段(Undo Segments)中的信息来回滚这些事务的修改,以确保数据的一致性。 - **重做已提交但尚未写入磁盘的事务**:对于已经提交但尚未写入磁盘的数据修改,InnoDB会根据重做日志中的记录来重做这些修改,确保数据的持久性。 ##### 2. MyISAM的崩溃恢复 MyISAM存储引擎的崩溃恢复相对简单,因为它不依赖重做日志。MyISAM主要通过检查其表文件(.MYI和.MYD)的头部信息来识别损坏的表,并尝试通过表修复工具(如myisamchk)来恢复数据。然而,由于MyISAM不支持事务和行级锁定,其数据恢复能力相对较弱,因此在需要高可靠性和数据一致性的场合,InnoDB通常是更好的选择。 #### 三、双写缓冲区(Doublewrite Buffer) InnoDB存储引擎还引入了双写缓冲区机制来进一步保护数据在写入过程中的完整性。当Buffer Pool中的页面需要刷新到磁盘时,InnoDB首先会将页面的内容写入到内存中的双写缓冲区,然后再从双写缓冲区写入到磁盘的数据文件中。这样做可以确保即使在写入过程中发生系统崩溃,也不会因为部分写入而导致页面数据损坏。 在恢复过程中,InnoDB会检查双写缓冲区在磁盘上的副本,以验证数据文件页面的完整性。如果发现不一致,InnoDB会使用双写缓冲区中的完整副本来恢复损坏的页面。 #### 四、备份与恢复策略 除了上述的内部机制外,定期备份也是确保数据不丢失的重要手段。MySQL支持多种备份方式,包括物理备份(如直接复制数据文件)和逻辑备份(如使用mysqldump工具导出SQL语句)。管理员应根据实际情况选择合适的备份策略,并定期进行备份验证和恢复演练,以确保在数据丢失或损坏时能够迅速恢复。 #### 五、总结 MySQL通过事务日志(重做日志和二进制日志)、崩溃恢复机制、双写缓冲区以及定期备份等多种策略来确保数据的完整性和持久性。这些机制共同构成了MySQL强大的数据保护体系,使得MySQL能够在各种复杂和恶劣的环境下稳定运行,保障用户数据的安全和可靠。对于数据库管理员和开发者而言,深入理解这些机制并合理应用它们,是保障数据库系统稳定运行和数据安全的关键。
上一篇:
22 | MySQL有哪些“饮鸩止渴”提高性能的方法?
下一篇:
24 | MySQL是怎么保证主备一致的?
该分类下的相关小册推荐:
MySQL从入门到精通(五)
MySQL从入门到精通(三)
MySQL8.0入门与实践
MySQL从入门到精通(二)
MySQL从入门到精通(四)
MySQL必会核心问题
SQL零基础到熟练应用(增删改查)
细说MySQL(零基础到高级应用)
MySQL从入门到精通(一)