MySQL Server
架构自顶向下大致可以分网络连接层
、服务层
、存储引擎层
和系统文件层
。
1、网络连接层
客户端连接器(Client Connectors)
:提供与MySQL
服务器建立的支持。目前几乎支持所有主流的服务端编程技术,例如常见的 Java、C、Python、.NET
等,它们通过各自API
技术与MySQL
建立连接。
2、服务层(MySQL Server)
服务层是MySQL Server
的核心,主要包含系统管理和控制工具、连接池、SQL接口、解析器、查询优
化器和缓存六个部分。
连接池(Connection Pool)
:负责存储和管理客户端与数据库的连接,一个线程负责管理一个连接。系统管理和控制工具(Management Services & Utilities)
:例如备份恢复、安全管理、集群管理等。SQL接口(SQL Interface)
:用于接受客户端发送的各种SQL命令,并且返回用户需要查询的结 果。比如DML、DDL、存储过程、视图、触发器等。解析器(Parser)
:负责将请求的SQL解析生成一个"解析树"。然后根据一些MySQL规则进一步 检查解析树是否合法。查询优化器(Optimizer)
:当“解析树”通过解析器语法检查后,将交由优化器将其转化成执行计 划,然后与存储引擎交互。在这里插入代码片
3、存储引擎层(Pluggable Storage Engines)
存储引擎负责MySQL
中数据的存储与提取,与底层系统文件进行交互。MySQL
存储引擎是插件式的, 服务器中的查询执行引擎通过接口与存储引擎进行通信,接口屏蔽了不同存储引擎之间的差异 。现在有 很多种存储引擎,各有各的特点,最常见的是MyISAM
和InnoDB
。
4、系统文件层(File System)
该层负责将数据库的数据和日志存储在文件系统之上,并完成与存储引擎的交互,是文件的物理存储
层。主要包含日志文件,数据文件,配置文件,pid 文件,socket 文件等。
4.1 日志文件
错误日志(Error log)
默认开启,show variables like '%log_error%'
通用查询日志(General query log)
记录一般查询语句,show variables like '%general%';
二进制日志(binary log)
记录了对MySQL
数据库执行的更改操作,并且记录了语句的发生时间、执行时长;但是它不记录select
、show
等不修改数据库的SQL
。主要用于数据库恢复和主从复制。
show variables like '%log_bin%';
//是否开启
show variables like '%binlog%';
//参数查看
show binary logs;
//查看日志文件
慢查询日志(Slow query log)
记录所有执行时间超时的查询SQL
,默认是10
秒。
show variables like '%slow_query%';
//是否开启
show variables like '%long_query_time%';
//时长
配置文件
用于存放MySQL
所有的配置信息文件,比如my.cnf
、my.ini
等。
数据文件
db.opt
文件:记录这个库的默认使用的字符集和校验规则。
frm
文件:存储与表相关的元数据(meta
)信息,包括表结构的定义信息等,每一张表都会 有一个frm
文件。
MYD
文件:MyISAM
存储引擎专用,存放 MyISAM
表的数据(data
),每一张表都会有一个 .MYD
文件。
MYI
文件:MyISAM
存储引擎专用,存放 MyISAM
表的索引相关信息,每一张 MyISAM
表对应一个 .MYI
文件。
ibd
文件和 IBDATA
文件:存放 InnoDB
的数据文件(包括索引)。InnoDB
存储引擎有两种表空间方式:独享表空间
和共享表空间
。独享表空间使用 .ibd
文件来存放数据,且每一张 InnoDB
表对应一个 .ibd
文件。共享表空间使用 .ibdata
文件,所有表共同使用一个(或多个,自行配置).ibdata
文件。
ibdata1
文件:系统表空间数据文件,存储表元数据、Undo
日志等 。
ib_logfile0
、ib_logfile1
文件:Redo log
日志文件。
pid 文件
pid
文件是 mysqld
应用程序在 Unix/Linux
环境下的一个进程文件,和许多其他 Unix/Linux
服务端程序一样,它存放着自己的进程 id
。
socket 文件
socket
文件也是在 Unix/Linux
环境下才有的,用户在 Unix/Linux
环境下客户端连接可以不通过 TCP/IP
网络而直接使用 Unix Socket
来连接 MySQL
。
1、建立连接(Connectors&Connection Pool)
,通过客户端/服务器通信协议与MySQL
建立连接。MySQL
客户端与服务端的通信方式是 “ 半双工 ”。对于每一个 MySQL
的连接,时刻都有一个 线程状态来标识这个连接正在做什么。
通讯机制
:
全双工
:能同时发送和接收数据,例如平时打电话。半双工
:指的某一时刻,要么发送数据,要么接收数据,不能同时。例如早期对讲机。单工
:只能发送数据或只能接收数据。例如单行道。线程状态
:
show processlist;
//查看用户正在运行的线程信息,root
用户能查看所有线程,其他用户只能看自己的
2、查询缓存(Cache&Buffer)
,这是MySQL
的一个可优化查询的地方,如果开启了查询缓存且在 查询缓存过程中查询到完全相同的SQL
语句,则将查询结果直接返回给客户端;如果没有开启查询缓存或者没有查询到完全相同的 SQL
语句则会由解析器进行语法语义解析,并生成“解析树”。
Select
查询的结果和SQL
语句。Select
查询时,先查询缓存,判断是否存在可用的记录集,要求是否完全相同(包括参SQL
也不能缓存。SQL_NO_CACHE
query_cache_limit
设置now()
show variables like '%query_cache%';
//查看查询缓存是否启用,空间大小,限制等show status like 'Qcache%';
//查看更详细的缓存参数,可用缓存空间,缓存块,缓存多少等3、解析器(Parser)
将客户端发送的SQL
进行语法解析,生成"解析树"。预处理器根据一些MySQL
规则进一步检查“解析树”是否合法,例如这里将检查数据表和数据列是否存在,还会解析名字和别名,看看它们是否有歧义,最后生成新的“解析树”。
4、查询优化器(Optimizer)
根据“解析树”生成最优的执行计划。MySQL
使用很多优化策略生成最优的执行计划,可以分为两类:静态优化(编译时优化)
、动态优化(运行时优化)
。
5、查询执行引擎负责执行 SQL 语句
,此时查询执行引擎会根据 SQL
语句中表的存储引擎类型,以及对应的API
接口与底层存储引擎缓存或者物理文件的交互,得到查询结果并返回给客户端。若开启用查询缓存,这时会将SQL
语句和结果完整地保存到查询缓存(Cache&Buffer
)中,以后若有相同的 SQL
语句执行则直接返回结果。
存储引擎在MySQL
的体系架构中位于第三
层,负责MySQL
中的数据的存储和提取,是与文件打交道的 子系统,它是根据MySQL
提供的文件访问层抽象接口定制的一种文件访问机制,这种机制就叫作存储引 擎
。
使用show engines
命令,就可以查看当前数据库支持的引擎信息。
在5.5
版本之前默认采用MyISAM
存储引擎,从5.5
开始采用InnoDB
存储引擎。
InnoDB
:支持事务,具有提交,回滚和崩溃恢复能力,事务安全MyISAM
:不支持事务和外键,访问速度快Memory
:利用内存创建表,访问速度非常快,因为数据在内存,而且默认使用Hash索引,但是 一旦关闭,数据就会丢失Archive
:归档类型引擎,仅能支持insert和select语句Csv
:以CSV文件进行数据存储,由于文件限制,所有列必须强制指定not null,另外CSV引擎也不 支持索引和分区,适合做数据交换的中间表BlackHole
::黑洞,只进不出,进来消失,所有插入数据都不会保存Federated
:可以访问远端MySQL数据库中的表。一个本地表,不保存数据,访问远程表内容。MRG_MyISA
::一组MyISAM表的组合,这些MyISAM表必须结构相同,Merge表本身没有数据, 对Merge操作可以对一组MyISAM表进行操作。1、InnoDB和MyISAM对比
InnoDB和MyISAM是使用MySQL时最常用的两种引擎类型,我们重点来看下两者区别。
行级锁
,锁定指定记录。基于索引来加锁实现。表级锁
,锁定整张表。聚集索引(聚簇索引)
,索引和记录在一起存储,既缓存索引,也缓存记录。非聚集索引(非聚簇索引)
,索引和记录分开。写操作并发率低
,读之间并不阻塞,读写阻塞。读写阻塞可以与隔离级别有关
,可以采用多版本并发控制(MVCC)来支持高并发。64TB
;256TB
。2、InnoDB存储结构
从MySQL 5.5
版本开始默认使用InnoDB
作为引擎,它擅长处理事务,具有自动崩溃恢复的特性,在日
常开发中使用非常广泛。下面是官方的InnoDB
引擎架构图,主要分为内存结构
和磁盘结构
两大部分。
2.1 InnoDB内存结构
内存结构主要包括Buffer Pool
、Change Buffer
、Adaptive Hash
Index
和Log Buffer
四大组件。
2.1.1 Buffer Pool:缓冲池
,简称BP。BP以Page
页为单位,默认大小16K
,BP的底层采用链表数 据结构管理Page。在InnoDB访问表记录和索引时会在Page页中缓存,以后使用可以减少磁盘IO操作,提升效率。
Page管理机制
Page根据状态可以分为三种类型
:
free page
: 空闲page,未被使用
clean page
:被使用page,数据没有被修改过
dirty page
:脏页,被使用page,数据被修改过,页中数据和磁盘的数据产生了不 一致
针对上述三种page类型,InnoDB通过三种链表结构
来维护和管理
free list
:表示空闲缓冲区,管理free page
flush list
:表示需要刷新到磁盘的缓冲区,管理dirty page,内部page按修改时间 排序。脏页即存在于flush链表,也在LRU链表中,但是两种互不影响,LRU链表负 责管理page的可用性和释放,而flush链表负责管理脏页的刷盘操作。
lru list
:表示正在使用的缓冲区,管理clean page和dirty page,缓冲区以 midpoint为基点,前面链表称为new列表区,存放经常访问的数据,占63%;后 面的链表称为old列表区,存放使用较少数据,占37%。
改进型LRU算法维护
普通LRU
:末尾淘汰法,新数据从链表头部加入,释放空间时从末尾淘汰。
改性LRU
:链表分为new和old两个部分,加入元素时并不是从表头插入,而是从中间 midpoint位置插入,如果数据很快被访问,那么page就会向new列表头部移动,如果 数据没有被访问,会逐步向old尾部移动,等待淘汰。
每当有新的page数据读取到buffer pool时
,InnoDb引擎会判断是否有空闲页,是否足够,如果有就将free page从free list列表删除,放入到LRU列表中。没有空闲页,就会根据LRU算法淘汰LRU链表默认的页,将内存空间释放分配给新的页。
Buffer Pool配置参数
show variables like '%innodb_page_size%';
//查看page页大小
show variables like '%innodb_old%';
//查看lru list中old列表参数
show variables like '%innodb_buffer%';
//查看buffer pool参数
建议:将innodb_buffer_pool_size
设置为总内存大小的60%-80%
, innodb_buffer_pool_instances
可以设置多个,这样可以避免缓存争夺。
2.1.2 Change Buffer:写缓冲区
,简称CB。在进行DML操作时,如果BP没有其相应的Page数据, 并不会立刻将磁盘页加载到缓冲池,而是在CB记录缓冲变更,等未来数据被读取时,再将数据合并恢复到BP中。
ChangeBuffer
占用BufferPool
空间,默认占25%
,最大允许占50%
,可以根据读写业务量来进行调整。参数innodb_change_buffer_max_size
;
当更新一条记录时,该记录在BufferPool
存在,直接在BufferPool
修改,一次内存操作。如果该记录在BufferPool
不存在(没有命中),会直接在ChangeBuffer
进行一次内存操作,不用再去磁盘查询数据,避免一次磁盘IO
。当下次查询记录时,会先进性磁盘读取,然后再从 ChangeBuffer
中读取信息合并,最终载入BufferPool
中。
写缓冲区,仅适用于非唯一普通索引页,为什么?
如果在索引设置唯一性,在进行修改时,InnoDB
必须要做唯一性校验,因此必须查询磁盘, 做一次IO
操作。会直接将记录查询到BufferPool
中,然后在缓冲池修改,不会在 ChangeBuffer
操作。
2.1.3 Adaptive Hash Index:自适应哈希索引
,用于优化对BP数据的查询。InnoDB存储引擎会监控对表索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引,所以称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。
2.1.4 Log Buffer:日志缓冲区
,用来保存要写入磁盘上log文件(Redo/Undo)的数据,日志缓冲 区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘,当遇到BLOB 或多行更新的大事务操作时,增加日志缓冲区可以节省磁盘I/O。
LogBuffer主要是用于记录InnoDB引擎日志,在DML操作时会产生Redo和Undo日志。
LogBuffer空间满了,会自动写入磁盘。可以通过将innodb_log_buffer_size
参数调大,减少
磁盘IO频率。
innodb_flush_log_at_trx_commit
参数控制日志刷新行为,默认为1
。
0
: 每隔1秒写日志文件和刷盘操作(写日志文件LogBuffer–>OS cache,刷盘OS cache–>磁盘文件),最多丢失1秒数据1
:事务提交,立刻写日志文件和刷盘,数据不丢失,但是会频繁IO操作2
:事务提交,立刻写日志文件,每隔1秒钟进行刷盘操作2.2 InnoDB磁盘结构
InnoDB磁盘
主要包含Tablespaces
,InnoDB Data Dictionary
,Doublewrite Buffer
、Redo Log
和Undo Logs
。
2.2.1 表空间(Tablespaces)
:用于存储表结构和数据。表空间又分为系统表空间、独立表空间、通用表空间、临时表空间、Undo表空间等多种类型;
2.2.2 数据字典(InnoDB Data Dictionary)
InnoDB数据字典由内部系统表组成,这些表包含用于查找表、索引和表字段等对象的元数 据。元数据物理上位于InnoDB系统表空间中。由于历史原因,数据字典元数据在一定程度上 与InnoDB表元数据文件(.frm文件)中存储的信息重叠。
2.2.3 双写缓冲区(Doublewrite Buffer)
位于系统表空间,是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置前,会先 将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存储子系统或 mysqld进程崩溃,InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找到页面的一个好 备份。在大多数情况下,默认情况下启用双写缓冲区,要禁用Doublewrite 缓冲区,可以将 innodb_doublewrite设置为0。使用Doublewrite 缓冲区时建议将innodb_flush_method设 置为O_DIRECT。
2.2.4 重做日志(Redo Log)
重做日志是一种基于磁盘的数据结构,用于在崩溃恢复期间更正不完整事务写入的数据。 MySQL以循环方式写入重做日志文件,记录InnoDB中所有对Buffer Pool修改的日志。当出 现实例故障(像断电),导致数据未能更新到数据文件,则数据库重启时须redo,重新把数 据更新到数据文件。读写事务在执行的过程中,都会不断的产生redo log。默认情况下,重 做日志在磁盘上由两个名为ib_logfile0和ib_logfile1的文件物理表示。
2.2.5 撤销日志(Undo Logs)
撤消日志是在事务开始之前保存的被修改数据的备份,用于例外情况时回滚事务。撤消日志 属于逻辑日志,根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表 空间中。
2.3 新版本结构演变
2.3.1 MySQL 5.7 版本
2.3.2 MySQL 8.0 版本
3、InnoDB线程模型
3.1 IO Thread
在InnoDB中使用了大量的AIO(Async IO)来做读写处理,这样可以极大提高数据库的性能。在 InnoDB1.0版本之前共有4个IO Thread,分别是write,read,insert buffer和log thread,后来 版本将read thread和write thread分别增大到了4个,一共有10个了。
3.2 Purge Thread
事务提交之后,其使用的undo日志将不再需要,因此需要Purge Thread回收已经分配的undo 页。
show variables like '%innodb_purge_threads%';
3.3 Page Cleaner Thread
作用是将脏数据刷新到磁盘,脏数据刷盘后相应的redo log也就可以覆盖,即可以同步数据,又能 达到redo log循环使用的目的。会调用write thread线程处理。
show variables like '%innodb_page_cleaners%';
3.4 Master Thread
Master thread是InnoDB的主线程,负责调度其他各线程,优先级最高。作用是将缓冲池中的数 据异步刷新到磁盘 ,保证数据的一致性。包含:脏页的刷新(page cleaner thread)、undo页 回收(purge thread)、redo日志刷新(log thread)、合并写缓冲等。内部有两个主处理,分别 是每隔1秒和10秒处理。
每1秒的操作:
每10秒的操作:
4、InnoDB数据文件
4.1 InnoDB文件存储结构
分为一个ibd数据文件-->Segment(段)-->Extent(区)-->Page(页)-->Row(行)
Tablesapce
表空间,用于存储多个ibd数据文件,用于存储表的记录和索引。一个文件包含多个段。
Segment
段,用于管理多个Extent,分为数据段(Leaf node segment)、索引段(Non-leaf node segment)、回滚段(Rollback segment)。一个表至少会有两个segment,一个管理数 据,一个管理索引。每多创建一个索引,会多两个segment。
Extent
区,一个区固定包含64个连续的页,大小为1M。当表空间不足,需要分配新的页资源,不会一页一页分,直接分配一个区。
Page
页,用于存储多个Row行记录,大小为16K。包含很多种页类型,比如数据页,undo页,系统页,事务数据页,大的BLOB对象页。
Row
行,包含了记录的字段值,事务ID(Trx id)、滚动指针(Roll pointer)、字段指针(Field
pointers)等信息。
Page是文件最基本的单位,无论何种类型的page,都是由page header,page trailer和page
body组成。如下图所示,
4.2 InnoDB文件存储格式
通过 SHOW TABLE STATUS
命令
一般情况下,如果row_format为REDUNDANT、COMPACT,文件格式为Antelope;如果 row_format为DYNAMIC和COMPRESSED,文件格式为Barracuda。
通过 information_schema
查看指定表的文件格式
select * from information_schema.innodb_sys_tables;
4.3 File文件格式(File-Format)
在早期的InnoDB版本中,文件格式只有一种,随着InnoDB引擎的发展,出现了新文件格式,用于
支持新的功能。目前InnoDB只支持两种文件格式:Antelope 和 Barracuda。
通过innodb_file_format 配置参数可以设置InnoDB文件格式,之前默认值为Antelope,5.7版本 开始改为Barracuda。
4.4 Row行格式(Row_format)
表的行格式决定了它的行是如何物理存储的,这反过来又会影响查询和DML操作的性能。如果在 单个page页中容纳更多行,查询和索引查找可以更快地工作,缓冲池中所需的内存更少,写入更 新时所需的I/O更少。
InnoDB存储引擎支持四种行格式:REDUNDANT、COMPACT、DYNAMIC和COMPRESSED。
DYNAMIC和COMPRESSED新格式引入的功能有:数据压缩、增强型长列数据的页外存储和大索引 前缀。
每个表的数据分成若干页来存储,每个页中采用B树结构存储;
如果某些字段信息过长,无法存储在B树节点中,这时候会被单独分配空间,此时被称为溢出页,
该字段被称为页外列。
REDUNDANT
行格式在创建表和索引时,文件格式都被用于每个InnoDB表数据文件(其名称与*.ibd匹配)。修改文件 格式的方法是重新创建表及其索引,最简单方法是对要修改的每个表使用以下命令:
ALTER TABLE 表名 ROW_FORMAT=格式类型;
5、Undo Log
5.1 Undo Log介绍
Undo
:意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作。
Undo Log
:数据库事务开始之前,会将要修改的记录存放到 Undo 日志里,当事务回滚时或者数 据库崩溃时,可以利用 Undo 日志,撤销未提交事务对数据库产生的影响。
Undo Log产生和销毁
:Undo Log在事务开始前产生;事务在提交时,并不会立刻删除undo log,innodb会将该事务对应的undo log放入到删除列表中,后面会通过后台线程purge thread进 行回收处理。Undo Log属于逻辑日志,记录一个变化过程。例如执行一个delete,undolog会记 录一个insert;执行一个update,undolog会记录一个相反的update。
Undo Log存储
:undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollback segment回滚段,内部包含1024个undo log segment。可以通过下面一组参数来控制Undo log存 储。
show variables like '%innodb_undo%';
5.2 Undo Log作用
实现事务的原子性
实现多版本并发控制(MVCC)
事务A手动开启事务,执行更新操作,首先会把更新命中的数据备份到 Undo Buffer 中。
事务B手动开启事务,执行查询操作,会读取 Undo 日志数据返回,进行快照读。
6、Redo Log 和 Binlog
Redo Log和Binlog是MySQL日志系统中非常重要的两种机制,也有很多相似之处,下面介绍下两者细
节和区别。
6.1 Redo Log日志
6.1.1 Redo Log介绍
Redo
:顾名思义就是重做。以恢复操作为目的,在数据库发生意外时重现操作。
Redo Log
:指事务中修改的任何数据,将最新的数据备份存储的位置(Redo Log),被称为重做 日志。
Redo Log 的生成和释放
:随着事务操作的执行,就会生成Redo Log,在事务提交时会将产生 Redo Log写入Log Buffer,并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后,Redo Log 的使命也就完成了,Redo Log占用的空间就可以重用(被覆盖写入)。
6.1.2 Redo Log工作原理
Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点,尚有脏页未写入表的 IBD 文件中,在重启 MySQL 服务的时候,根据 Redo Log 进行重做,从而达到事务的未入磁盘数据进行持久化这一特性。
6.1.3 Redo Log写入机制
Redo Log 文件内容是以顺序循环的方式写入文件,写满时则回溯到第一个文件,进行覆盖写。
write pos 和 checkpoint 之间还空着的部分,可以用来记录新的操作。如果 write pos 追上 checkpoint,表示写满,这时候不能再执行新的更新,得停下来先擦掉一些记录,把 checkpoint 推进一下。
6.1.4 Redo Log相关配置参数
每个InnoDB存储引擎至少有1个重做日志文件组(group),每个文件组至少有2个重做日志文
件,默认为ib_logfile0和ib_logfile1。可以通过下面一组参数控制Redo Log存储:
show variables like '%innodb_log%';
Redo Buffer 持久化到 Redo Log 的策略,可通过 Innodb_flush_log_at_trx_commit
设置:
一般建议选择取值2,因为 MySQL 挂了数据没有损失,整个服务器挂了才会损失1秒的事务提交数据。
6.2 Binlog日志
6.2.1 Binlog记录模式
Redo Log
是属于InnoDB引擎
所特有
的日志,而MySQL Server
也有自己的日志,即 Binary log(二进制日志)
,简称Binlog。Binlog是记录所有数据库表结构变更以及表数据修改的二进制 日志,不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录,还包含语句所执行的消耗时间。开启Binlog日志有以下两个最重要的使用场景。
主从复制
:在主库中开启Binlog功能,这样主库就可以把Binlog传递给从库,从库拿到 Binlog后实现数据恢复达到主从数据一致性。数据恢复
:通过mysqlbinlog工具来恢复数据。Binlog文件名默认为“主机名_binlog-序列号”格式,例如oak_binlog-000001,也可以在配置文件中指定名称。文件记录模式有STATEMENT、ROW和MIXED三种,具体含义如下。
ROW
(row-based replication, RBR):日志中会记录每一行数据被修改的情况,然后在 slave端对相同的数据进行修改。优点
:能清楚记录每一个行数据的修改细节,能完全实现主从数据同步和数据的恢复。缺点
:批量操作,会产生大量的日志,尤其是alter table会让日志暴涨。STATMENT
(statement-based replication, SBR):每一条被修改数据的SQL都会记录到 master的Binlog中,slave在复制的时候SQL进程会解析成和原来master端执行过的相同的 SQL再次执行。简称SQL语句复制。优点
:日志量小,减少磁盘IO,提升存储和恢复速度。缺点
:在某些情况下会导致主从数据不一致,比如last_insert_id()、now()等函数。MIXED
(mixed-based replication, MBR):以上两种模式的混合使用,一般会使用 STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存 binlog,MySQL会根据执行的SQL语句选择写入模式。6.2.2 Binlog文件结构
MySQL的binlog文件中记录的是对数据库的各种修改操作,用来表示修改操作的数据结构是Log event
。不同的修改操作对应的不同的log event。比较常用的log event有:Query event、Row event、Xid event等。binlog文件的内容就是各种Log event的集合。
Binlog文件中Log event结构如下图所示:
6.2.3 Binlog写入机制
6.2.4 Binlog文件操作
Binlog状态查看
show variables like 'log_bin';
开启Binlog功能
mysql> set global log_bin=mysqllogbin;
ERROR 1238 (HY000): Variable 'log_bin' is a read only variable
需要修改my.cnf或my.ini配置文件,在[mysqld]下面增加log_bin=mysql_bin_log,重启 MySQL服务。
#log-bin=ON
#log-bin-basename=mysqlbinlog
binlog-format=ROW
log-bin=mysqlbinlog
使用show binlog events命令
show binary logs; //等价于show master logs; show master status;
show binlog events;
show binlog events in 'mysqlbinlog.000001';
使用mysqlbinlog 命令
mysqlbinlog "文件名"
mysqlbinlog "文件名" > "test.sql"
使用 binlog 恢复数据
//按指定时间恢复
mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop- datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234 //按事件位置号恢复
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234
mysqldump
:定期全部备份数据库数据。mysqlbinlog可以做增量备份和恢复操作。
删除Binlog文件
purge binary logs to 'mysqlbinlog.000001'; //删除指定文件
purge binary logs before '2020-04-28 00:00:00'; //删除指定时间之前的文件 reset master; //清除所有文件
可以通过设置expire_logs_days
参数来启动自动清理功能。默认值为0表示没启用。设置为1表示超 出1天binlog文件会自动删除掉。
6.2.5 Redo Log和Binlog区别
Redo Log是属于InnoDB引擎功能
,Binlog是属于MySQL Server自带功能
,并且是以二进制文件记录。
Redo Log属于物理日志
,记录该数据页更新状态内容,Binlog是逻辑日志
,记录更新过程。
Redo Log日志是循环写
,日志空间大小是固定,Binlog是追加写入
,写完一个写下一个,不会覆盖使用。
Redo Log作为服务器异常宕机后事务数据自动恢复
使用,Binlog可以作为主从复制和数据恢复
使用。Binlog没有自动crash-safe能力。