<>一、简介

<>1. 分类

Mysql有不同的日志文件,用来存储不同类型和功能的日志,分为二进制日志、错误日志、通用查询日志、慢查询日志。Mysql8.0又新增两种日志:中继日志和
数据定义语句日志。

<>2. 弊端

* 日志会降低mysql数据库的性能,需要花费额外时间记录日志。
* 日志会占用大量磁盘空间。
<>二、通用查询日志(general query log)

<>1. 介绍

正如他的名字一样,该日志会记录用户的所有操作,包括启动和关闭mysql服务,所有用户的连接开始时间和结束时间、发给mysql的所有sql指令。

<>2. 相关变量
show variables like '%general%'

set GLOBAL general_log=on; set GLOBAL general_log_file='/path/filename'
如果开启了以后,可以直接通过vim查看通用查询日志。

<>3.备份

如果删除或者改名了原来的日志文件,使用如何命令重新生成查询日志文件:
mysqldadmin -uroot -p flush-logs
<>三、错误日志(error log)

<>1. 介绍

错误日志记录了mysql服务器启动、停止运行的时间,以及系统启动、运行和停止过程中的诊断信息,包括错误、警告和提示等。
该日志默认是开启的,而且无法被禁止。
默认情况下,错误日志存储/var/log下,名称默认为mysqld.log

<>2. 备份
#mysql5.5.7以前不用执行第一句 install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.
log mysqldadmin-uroot -p flush-logs
<>四、二进制日志(bin log)

<>1. 介绍

它记录了数据库所有执行的ddl和dml等数据库更新事件语句,但是不包括没有修改数据的语句(select、show等)。
它的主要应用场景有两个:

* 用于数据恢复,通过查看用户执行了哪些操作,可以实现数据的增量恢复。
* 用于数据复制,master把二进制文件传递给slaves来达到master-slave数据一致的目的。
<>2. 相关变量
show variables like '%log_bin%'

log_bin_trust_function_creators:表示是否信任存储函数
log_bin_use_v1_row_events: on表示使用版本1二进制日志行,off表示使用版本2二进制日志行
show variables like '%binlog_format%'

binglog有如下3种格式:

* statement: 每一条修改的sql都会记录在binlog中。好处是不需要记录每行的变化,减少日志量,节约io。
* row: 保存那条记录被修改。可以避免存储过程或函数无法正确复制的问题。
* mixed:5.1.8以后提供,是statement和row的结合。
<>3. 永久性设置

修改mysql的my.cnf或my.ini文件:
log_bin = xxxx # 日志名 binlog_expire_logs_seconds=600 # 日志保存时间,s max_binlog_size=
100M # 单个日志大小,当前日志文件大小超过此变量,执行切换动作。默认大小为1GB。该设置不是严格遵守的。
<>4. 查看日志

mysql每重启一次,就会生成一个bin log文件。查看当前binlog列表及其大小:
show binary logs

所有对数据库的修改都会记录在binlog中,单binlog是二进制文件,无法直接查看,想要查看需要借助mysqlbinlog命令工具。
mysqlbinlog "日志文件路径/名字"
默认打开后,并没有具体的sql语句,而是记录了一些事件:

* Query事件,负责开始一个事务。
* Table_map事件,负责映射需要的表。
* Update_rows事件,复制写入数据。
* Xid事件,复制结束事务。 mysqlbinlog -v "日志文件路径/名字" # 将行事件以伪sql形式表示出来
<>5. 恢复数据

可以使用mysqlbinlog工具从指定时间点开始到另外一个时间点的日志中恢复数据。
mysqlbinlog [option] filename | mysql -uroot -p
option有几个重要参数:

* --start-date 和--stop-date :可以指定数据库恢复的起始时间和结束时间
* --start-position 和--stop-position :可以指定恢复数据的开始位置和结束为止
* --database=“”:指定数据库
如果是用位置恢复,需要使用如下命令来获取为止:
show binlog events in 'binlog 文件名'

<>6. 删除二进制日志

mysql的二进制文件可以配置自动删除,也可以安全的手动删除的方法。
PURGE MASTER LOGS 删除指定部分:
PURGE {MASTER | BINARY} LOGS TO '指定文件名' # 删除创建时间早于xxx的日志 PURGE {MASTER |
BINARY} LOGS BEFORE '指定日期' # 删除xxxx时间前创建的所有日志。
RESET BINARYLOGS 删除所有:

<>7. 两阶段提交

binglog的写入策略由参数sync_binlog控制,默认是0。表示每次提交都只写到操作系统缓存中,由系统判断什么时候执行刷盘。为1
时,表示每次提交都会刷盘。当大于1时,表示累计到n个事务时才刷盘。
innodb更新一条指定数据的过程如下:

edo log与binlog都写一次的话,也就是存在以下两种情况:

* 先写binlog,再写redo log:当前事务提交后,写入binlog成功,之后主节点崩溃。在主节点重启后,由于没有写入redo
log,因此不会恢复该条数据。而从节点依据binlog在本地回放后,会相对于主节点多出来一条数据,从而产生主从不一致。
* 先写redo log,再写binlog:当前事务提交后,写入redo log成功,之后主节点崩溃。在主节点重启后,主节点利用redo
log进行恢复,就会相对于从节点多出来一条数据,造成主从数据不一致。
此时,如果发生崩溃,就可以根据redolog和binlog进行恢复。
在写入redo log时,会顺便记录XID,即当前事务id。在写入binlog时,也会写入XID。因此存在以下三种情况:

* 如果在写入redo log之前崩溃,那么此时redo log与binlog中都没有,是一致的情况,崩溃也无所谓。
* 如果在写入redo log prepare阶段后立马崩溃,之后会在崩恢复时,由于redo log没有被标记为commit。于是拿着redo
log中的XID去bin log中查找,此时肯定是找不到的,那么执行回滚操作。
* 如果在写入bin log后立马崩溃,在恢复时,由redo log中的XID可以找到对应的bin log,这个时候直接提交即可。
总的来说,在崩溃恢复后,只要redo log不是处于commit阶段,那么就拿着redo
log中的XID去binlog中寻找,找得到就提交,否则就回滚。在这样的机制下,两阶段提交能在崩溃恢复时,能够对提交中断的事务进行补偿,来确保redo
log与binlog的数据一致性。

技术
今日推荐
阅读数 7017
阅读数 2018
阅读数 1515
阅读数 1303
阅读数 1303
阅读数 1134
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信