日志分类
一、mysql日志分类
日志是MySQL数据库的重要组成部分。日志文件中记录着MySQL数据库运行期间发生的变化;也就是说用来记录MySQL数据库的客户端连接状况、SQL语句的执行情况和错误信息等。当数据库遭到意外的损坏时,可以通过日志查看文件出错的原因,并且可以通过日志文件进行数据恢复
二、错误日志
默认情况下,错误日志是开启的,且无法被禁止。默认情况下,错误日志是存储在数据库的数据文件目录中,名称为hostname.err,其中,hostname为服务器主机名
1、查询错误日志存放路径
#方式一:
[root@web01 ~]# mysqladmin -uroot -p"Hzl@20144" variables | grep -w log_error
| log_error | /var/log/mysqld.log
#方式二:
mysql> show variables like "%log_error%";
+---------------------+---------------------+
| Variable_name | Value |
+---------------------+---------------------+
| binlog_error_action | ABORT_SERVER |
| log_error | /var/log/mysqld.log |
| log_error_verbosity | 3 |
+---------------------+---------------------+
3 rows in set (0.00 sec)
2、配置错误日志(默认是启用的)
#自定义错误日志位置
[root@localhost ~]# vim /etc/my.cnf
[mysqld]
#绝对路径
log_error=/var/log/mysql.errlog
#相对路径
#log_error=mysql.errlog
#创建错误日志文件
[root@localhost ~]# touch /var/log/mysql.errlog
[root@localhost ~]# chmod 640 /var/log/mysql.errlog
[root@localhost ~]# chown mysql.mysql /var/log/mysql.errlog
#重启数据库
[root@localhost ~]# systemctl restart mysqld
3、错误日志参数控制
MySQL中,其中log_error定义是否启用错误日志的功能和错误日志的存储位置
此外还可以用参数控制,是否将告警信息(warning messages)也写入错误日志。
在不同的版本中改控制参数有所不同
#MySQL 5.6中用log_warnings参数控制
log_warnings=0, #表示不记录告警信息。
log_warnings=1 #(默认值)表示告警信息写入错误日志。
log_warnings # 大于1,表示各类告警信息,例如有关网络故障的信息和重新连接信息写入错误日志
#MySQL5.7新增的log_error_verbosity参数
#它有三个可选值, 分别对应:
log_error_verbosity=1 #错误信息;
log_error_verbosity=2 #错误信息和告警信息;(推荐)
log_error_verbosity=3 #(默认值就是3)错误信息、告警信息和通知信息
4、错误日志记录的信息
1)#服务器启动和关闭过程中的信息
未必是错误信息,比如mysql是如何去初始化存储引擎的过程记录在错误日志里等等
2)#服务器运行过程中的错误信息
比如sock文件找不到,无法加载mysql数据库的数据文件,如果忘记初始化mysql或data dir路径找不到,或权限不正确等 都会记录在此
3)#事件调度器运行一个事件时产生的信息
一旦mysql调度启动一个计划任务的时候,它也会将相关信息记录在错误日志中
4)#在从服务器上启动从服务器进程时产生的信息
在复制环境下,从服务器进程的信息也会被记录进错误日志
三、mysql事务的日志
【redo】
记录的是尚未完成的操作,断电则用其重做
#redo即redo日志:
是用于记录数据库中数据变化的日志,只要你修改了数据块那么就会记录redo信息,当然nologging除外了。
你的每次操作都会先记录到redo日志中,当出现实例故障(像断电),导致数据未能更新到数据文件,则数据库重启时须redo,重新把数据更新到数据文件
【undo】
记录的改动之前的旧数据,一旦改错,可以回滚
#undo即undo段:
是指数据库为了保持读一致性,存储历史数据在一个位置。
用于记录更改前的一份copy,用于回滚、撤销还原
四、一般查询日志
1)#默认是关闭的
一般不会开启,因为哪怕你开启事务一顿操作,最后不提交也会记录,生产上程序跑sql很多,会非常非常占地方,从来都不启动,要看操作去binlog
2)#配置文件开启
#方式一:
[root@db01 ~]# vim /etc/my.cnf
general_log=on
general_log_file=/var/log/select.log
#方式二:
#命令行设置:可以使用set global general_log=on;设置
#文件创建并授权
[root@localhost ~]# touch /var/log/select.log
[root@localhost ~]# chmod 640 /var/log/select.log
[root@localhost ~]# chown mysql.mysql /var/log/select.log
[root@localhost ~]# systemctl restart mysqld
3)#查看一般查询日志
#方式一:
[root@db01 ~]# mysqladmin -uroot -pHzl@20144 variables|grep general_log
#方式二:
[root@db01 ~]# mysql -uroot -pHzl@20144
mysql> show variables like '%gen%';
+----------------------------------------+--------------------------+
| Variable_name | Value |
+----------------------------------------+--------------------------+
| auto_generate_certs | ON |
| general_log | OFF |
| general_log_file | /var/lib/mysql/web01.log |
| sha256_password_auto_generate_rsa_keys | ON |
+----------------------------------------+--------------------------+
4 rows in set (0.00 sec)
五、慢查询日志
【慢日志的概述】
1> 慢查询会导致CPU,IOPS,内存消耗过高。当数据库遇到性能瓶颈时,大部分时间都是由于慢查询导致的。 开启慢查询日志,可以让MySQL记录下查询超过指定时间的语句,之后运维人员通过定位分析,能够很好的优化数据库性能
2> 慢查询日志记录的慢查询不仅仅是执行比较慢的SELECT语句,还有INSERT,DELETE,UPDATE,CALL等DML操作,只要超过了指定时间,都可以称为"慢查询",被记录到慢查询日志中
3> 默认情况下,慢查询日志是不开启的,只有手动开启了,慢查询才会被记录到慢查询日志中
1、慢查询日志的作用
1)#将mysql服务器中影响数据库性能的相关SQL语句(所有语句,增删改查)记录到日志文件
2)#通过对这些特殊的SQL语句分析并改进,提高数据库性能
2、慢日志的的查询
mysql> show variables like "%slow%";
+---------------------------+-------------------+
| Variable_name | Value |
+---------------------------+-------------------+
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| slow_launch_time | 2 |
| slow_query_log | ON |
| slow_query_log_file | /var/log/slow.log |
+---------------------------+-------------------+
5 rows in set (0.00 sec)
3、慢查询日志的配置
#配置文件慢日志默认是不开启的
[root@db01 ~]# vim /etc/my.cnf
[mysqld]
#指定是否开启慢查询日志
slow_query_log = 1
#指定慢日志文件存放位置(默认在data)
slow_query_log_file=/var/log/slow.log
#设定慢查询的阀值(默认10s)
long_query_time=0.05
#不使用索引的慢查询日志是否记录到日志
log_queries_not_using_indexes=ON
#查询检查返回少于该参数指定行的SQL不被记录到慢查询日志,少于100行的sql语句查询慢的话不记录,一般不使用
#min_examined_row_limit=100
#日志文件创建并授权
touch /var/log/slow.log
chmod 640 /var/log/slow.log
chown mysql.mysql /var/log/slow.log
systemctl restart mysqld
4、测试慢日志
######################## 测试慢日志 #########################
#方式一:
测试:BENCHMARK(count,expr)
mysql> SELECT BENCHMARK(50000000,2*3);
+-------------------------+
| BENCHMARK(50000000,2*3) |
+-------------------------+
| 0 |
+-------------------------+
1 row in set (0.51 sec)
#执行卡死,查看执行的sql执行时间,如果停不下来 可以 kill id
show processlist;
kill 3;
#方式二:
#循环插入数据
insert city_new select * from city;
insert city_new select * from city_new;
insert city_new select * from city_new;
insert city_new select * from city_new;
######################## 查询日志 #########################
#方式一:
#查看慢日志可以使用
cat /var/log/slow.log
#实时查看状态
tail -f /var/log/slow.log
#方式二:
#查询得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s r -t 10 /var/log/slow.log
#参数说明:
-s:指定排序方式
c、t、l、r分别是按照记录次数、时间、查询时间、
返回的记录数来排序,ac、at、al、ar,表示相应的倒叙
-t:是top n的意思,即为返回前面多少条的数据;
-g:后边可以写一个正则匹配模式,大小写不敏感的;
#方式三:
#使用软件查询
yum provides pt-query-digest #pt-query-digest 是分析MySQL查询日志最有力的工具,该工具功能强大,它可以分析binlog,Generallog,slowlog,也可以通过show processlist或者通过 tcpdump 抓取的MySQL协议数据来进行分析,比 mysqldumpslow 更具体,更完善
#直接分析慢查询文件
pt-query-digest slow.log > slow_report.log #该工具可以将查询的剖析报告打印出来,可以分析结果输出到文件中,分析过程是先对查询语句的条件进行参数化,然后对参数化以后的查询进行分组统计,统计出各查询的执行时间,次数,占比等,可以借助分析结果找出问题进行优化
六、二进制日志(bin log)
二进制日志即binlog日志,记录了mysql数据库所有的dml,ddl语句事件(不包含select)。记录增删改,也可以记录SQL语句及行记录变化,还可以记录这些操作事件;总之会记录所有修改操作的SQL语句
1、二进制日志概述(binlog)
1> MySQL的二进制日志(bin log)是一个二进制文件,主要记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的所有操作。
2> 二进制日志(bin log)中记录了对MySQL数据库执行更改的所有操作,并且记录了语句发生时间、执行时长、操作数据等其它额外信息,但是它不记录SELECT、SHOW等那些不修改数据的SQL语句
#不要混淆以下三种日志:
(1)general log:一般日志,记录数据库里的所有SQL操作记录
(2)redo log:只记录innodb存储引擎的修改日志
(3)binlog:只记录server层面内部的修改情况。--select /show 不记录
2、二进制日志的作用 (binlog)
1)恢复(recovery):某些数据的恢复需要二进制日志。例如,在一个数据库全备文件恢复后,用户可以通过二进制日志进行point-in-time的恢复
2)复制(replication):其原理与恢复类似,通过复制和执行二进制日志使一台远程的MySQL数据库(一般称为slave或者standby)与一台MySQL数据库(一般称为master或者primary)进行实时同步
3)审计(audit):用户可以通过二进制日志中的信息来进行审计,判断是否有对数据库进行注入攻击
#开启binlog的好处
(1)#数据恢复:可以基于时间点恢复,以及根据其进行增量与差异备份
(2)#mysql主从复制,通过binlog实现数据复制
【二进制日志的工作模式】
binlog格式分为: STATEMENT、ROW和MIXED三种:
1、语句模式:statement
binlog_format=statement(Mysql5.7.6之前的默认级别)
记录对数据库做出修改的sql语句,不记录该sql的上下文信息
#语句模式介绍:
STATEMENT格式的binlog记录的是数据库上执行的原生SQL语句,这种方式有好处也有坏处
好处就是相当简单,简单地记录和执行这些语句,能够让主备保持同步,在主服务器上执行的SQL语句,在从服务器上执行同样的语句。另一个好处是二进制日志里的时间更加紧凑,所以相对而言,基于语句的复制模式不会使用太多带宽,同时也节约磁盘空间
坏处就是同一条SQL在主库和从库上执行的时间可能稍微或很大不相同,因此在传输的二进制日志中,除了查询语句,还包括了一些元数据信息,如当前的时间戳。即便如此,还存在着一些无法被正确复制的SQ
#例如:
1)#开启binlog日志后,我们在某个库下自定义函数,若想定义成功需要先设置配置项
set global log_bin_trust_function_creators=TRUE;
2)#然后自定义函数
delimiter //
create function f1(
i1 int,
i2 int)
returns int
BEGIN
declare num int;
set num = i1 + i2;
return(num);
END //
delimiter ;
3)#最后执行一条插入语句
insert into t1(name) values(concat("hzl",f1(1,2)));
如果使用statement模式,那么这条insert语句将会被记录到二进制日志中,而sql语句中依赖的f1
的定义是不会记录下来的,f1只存在于当前库
############################### 缺点 ############################
不需要记录细到每一行数据的更改变化,因此,binlog日志量小,IO压力小,性能较高
#例如:
一条语句修改了100万行,该模式下只需要记录下该条语句即可
############################### 优点 ############################
日志中记录的sql语句可能有上下文依赖,此时脱离了当前数据库环就无法运行了,因此该模式下容易
出现主从不一致的问题。
#例如:
主库记录的某条sql语句引用了主库中的函数、触发器、存储过程等特殊功能,在从库上接收了该sql之后,可能就无法正确运行,从而主从库数据不一致的问题。
ps :row模式是基于每一行来记录变化的,所以不会出现类似的问题。
#应用场景
sql语句对mysql内置功能依赖比较少:不使用存储过程/触发器/函数,可以使用该模式,否则还是推荐行级模式
2、行级模式:ROW
binlog_format=row(mysql5.7.6之后+8.0的默认级别)
ROW格式的二进制日志基本是标配了,主要是因为它的优势远远大于缺点。并且由于ROW格式记录行数据,所以可以基于这种模式做一些DBA工具,比如数据恢复,不同数据库之间数据同步等
#行级模式介绍
记录每一行数据修改的细节,即哪一条记录被修改了,修改成什么样了
#例如:执行语句(f1参照上例,此处略)
insert into t1(name) values(concat("hzl",f1(1,2)));
如果使用row模式,那么日志中会记录插入了一条新记录,记录中的name字段值为’hzl'
############################### 优点 ############################
相当于把上下文依赖都记录了下来,可以更方便查看每一条数据修改的细节,并且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题,即该模式下主从复制强一致,数据最安全
############################### 缺点 ############################
日志量大
#例如
一条语句修改了100万行,语句模式下只需要记录一条语句即可
而行级模式却修改记录下100万行的修改记录,binlog日志的量可能会大得惊人。
#应用
sql语句对mysql内置功能依赖比较多,希望数据最安全,复制强一致的场景推荐行级模式
3、混合模式:mixed
binlog_format=mixed,一般不用
MIXED也是MySQL默认使用的二进制日志记录方式,但MIXED格式默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。比如用到UUID()、USER()、CURRENT_USER()、ROW_COUNT()等无法确定的函数
#混合模式介绍
结合 row level 与statement level的优点
混合(mixed-based)模式默认采用语句模式记录日志,在一些特定的情况下会将记录模式切换为行级模式记录,这些特殊情况包含但不限于以下情况
•当函数中包含UUID()时。
•当表中有自增列(AUTO_INCREMENT)被更新时。
•当执行触发器(trigger)或者存储过程(stored function)等特殊功能时。
•当FOUND_ROWS()、ROW_COUNT()、USER()、CURRENT_USER()、CURRENT_USER等执行时。
#应用场景
看上去这种方式似乎比较美好,但是在生产环境中,为了保险起见,一般会使用row模式。
【binlog的相关概念】
二进制日志文件,顾名思义,它是二进制的,所以我们不能直接使用cat命令进行查看,而是需要通过一些别的命令查看其内容,而且,二进制日志文件,有”事件”和”位置”的概念
(1)# 事件(events)
通俗的讲,我们可以把binlog中的每一条记录当做一个”事件”
因为binlog记录了所有对数据库进行的修改,所以,我们可以认为,数据库的修改被记录到二进制日志中,这些记录每一条都可以理解为一个”事件”。
(2)# 位置(position)
由于二进制日志文件是二进制的,所以,我们可以把整个二进制文件想象成一个字节序列。
假设,二进制日志文件刚开始是空的,从第1个字节开始记录,假设记录第一个”事件”(第一条记录),需要15个字节,那么第一个事件的开始”位置”就是1,结束”位置”就是15,由于前15个字节已经被第一个事件占用,那么当我们想要通过二进制日志记录第二个事件时,则需要从第15个字节向后开始记录,假设记录第二个”事件”需要20个字节,那么第二个事件在binlog中的起始”位置”就是15,结束”位置”就是35,以此类推
【binlog相关参数】
1、server_id
服务ID,主从库必须不一样,建议数字为:ip+端口,5.7.3以后版本,必须指定
2、 log-bin
此变量用于控制是否开启二进制日志,而且这是一个只读变量,默认值为OFF
当我们启动数据库以后,在当前数据库连接中查看此变量的值,此变量值可能为OFF,表示不记录二进制日志,如果想要记录二进制日志,只需将此值设置为二进制日志的文件名即可
但是需要注意的是,我们无法在当前会话中使用set命令设置log_bin的值,因为它是一个只读变量,我们只能通过修改my.cnf的方式,设置log_bin的值
假设,我们编辑my.cnf文件,设置log_bin的值为mybinlog,那么,在mysql的数据目录中,将会自动生成一个以mybinlog为文件名前缀的二进制日志文件
如果想要再次禁用binlog,只需要将log_bin这一行配置从my.cnf文件中注释即可,或者将其删除,重启mysql服务后,再次查看log_bin的值,其值为OFF,注意,不要直接在my.cnf文件中将log_bin的值,设置为ON或者OFF,如果这样做,你将会看到以ON或者OFF为文件名前缀的二进制日志文件。换句话说,如果my.cnf配置文件中没有log_bin的配置,则表示未开启二进制日志,如果my.cnf中存在log_bin的配置,那么则表示开启了二进制日志,同时二进制日志文件的名称将会以log_bin对应的值为文件名前缀,同时,二进制日志文件的后缀名会进行自动编号,每次日志滚动后,后缀名编号自动加1。
#示例:
log-bin=/var/lib/mysql/mybinlog #绝对路径
#log-bin=mybinlog #也可以用相对路径,会在$datadir下产生mysqlbinlog-00000N
3、 log_bin_index
不设置的话,会根据log_bin值名称自动生成mybinlog.index
log_bin_index=var/lib/mysql/mybinlog.index
4、 sql_log_bin
默认为ON
此变量用于标识当前会话中的操作是否会被记录于二进制日志
此变量值设置为ON,则表示在当前数据库连接中,对数据库进行修改的语句将会被记录到binlog中,此变量值设置为OFF,则表示在当前数据库连接中,对数据库进行的修改的语句将不会被记录到binlog中
在主从复制结构中,这些语句由于没有被binlog记录,所以也不会同步到从节点中。换句话说,即使在my.cnf配置文件中设置了log_bin的值,当前会话中,如果sql_log_bin的值设置为OFF,当前会话的操作也不会记录在二进制日志中。
而且需要注意的是,sql_log_bin是一个会话界别的变量,只能在当前会话中使用set sql_log_bin命令进行设置,不能使用set global sql_log_bin命令进行设置,因为它是会话级别的变量,而且,sql_log_bin也不能配置在my.cnf文件中,否则可能会无法启动mysql。
5、binlog_format
此变量值得含义上文已经解释过,此变量的值决定了二进制日志的记录方式,此变量的值可以设置为statement、row、mixed,分别表示以语句的形式记录二进制日志,以数据修改的形式记录二进制日志,以混合的方式记录二进制日志,安全保险起见,推荐使用row的方式记录
6、max_binlog_size
设置单个二进制日志文件的最大大小,以字节为单位,超过此值大小,则二进制日志文件会自动滚动
比如设置为500M为524288000
7、sync_binlog
innodb_flush_log_at_trx_commit控制redo日志的刷盘策略,建议值为1
sync_binlog控制binlog日志的刷盘策略,建议值为1
当我们把innodb_flush_log_at_trx_commit设置为1的时候,表示事务提交时,事务日志立马从内存刷写到磁盘中的事务日志文件中,而sync_binlog对于二进制日志的作用,就像innodb_flush_log_at_trx_commit对于事务日志的作用,由于二进制日志一开始存在于内存(binlog_cache)中,如果将sync_binlog设置为1,则表示每1次事务提交之后,都会立即将内存中的二进制日志立即同步到磁盘中的二进制日志文件中
如果将sync_binlog设置为0,则表示当事务提交之后,mysql不会立即将内存中的binlog刷写到磁盘中的binlog日志文件中,而是由文件系统决定什么时候刷写,这可能取决于文件系统的缓存机制,当此值设置为0时,一旦操作系统宕机,那么将丢失未从内存中同步到磁盘中的binlog
所以,当此值设置为0时,安全性最差,但是性能最高,当此值设置为1时,安全性最高,性能最差,除了将此值设置为0或1,还能设置为N,假设将此值设置为3,则表示每3次事务提交后,将binlog从内存刷写到磁盘一次,值设置的越大,有可能丢失的日志数据将会越多
当然,性能会越好,在追求安全的情况下,推荐设置为1,但是听说,此值设置为0和设置为1时在性能上的差距还是比较明显的,如果设置为0或N,最好为操作系统准备带有备用电源的缓存
8、其他参数
#打开才能查看详细记录,默认为off
binlog_rows_query_log_events=on
#表示自动删除10天以前的日志
expire_logs_days=10
#full,minimal,noblob分别表示binlog中内容全记录,只记录被操作的,和不记录二进制
binlog_row_image=full #(full,minimal,noblob)
【查看binlog配置项目】
#方式一:
[root@db01 ~]# mysqladmin -uroot -pEgon@123 variables |grep -w log_bin #不进入数据库进行查看日志
#方式二:
#在数据命令行进行查看
show variables like '%log_bin%';
show variables like '%binlog%';
show variables like '%binlog_format%';
show variables like '%server%';
show variables like 'expire_logs_days'; -- #过期日志天数
【开启binlog】
1> 默认是关闭的
2> 配置开启binlog
vim /etc/my.cnf
[mysqld]
server_id=1
log-bin=/var/lib/mysql/mybinlog
binlog_format='row' #(row,statement,mixed),不建议随意去修改binlog工作模式
binlog_rows_query_log_events=on
max_binlog_size=100M
#日志文件创建并授权 (文件不存在需要手动创建)
touch /var/lib/mysql/mybinlog
chmod 640 /var/lib/mysql/mybinlog
chown mysql.mysql /var/lib/mysql/mybinlog
systemctl restart mysqld
【查看binlog日志】
查看日志日志名、状态、事件
show binary logs;
show master logs;
show master status;
show binlog events in 'mybinlog.000002';
show binlog events in 'mybinlog.000002' limit 3;
查看日志内容
1)#执行下述sql
create database if not exists test;
use test;
create table user(name varchar(10));
begin; #开启一个事务
insert into user values("hzl1"),("hzl2"),("hzl3");
update user set name="HZL" where name="hzl1";
commit; #提交事务
2)#查看事务状态
show master status; -- binlog的当前position
查看binlog,看看有没有记录,二进制文件我们看不了,有专门的命令
查看全部:
#mysqlbinlog mybinlog.000002
#按时间:
mysqlbinlog mybinlog.000002 --start-datetime="2022-11-05 10:02:56"
mysqlbinlog mybinlog.000002 --stop-datetime="2022-11-05 11:02:54"
mysqlbinlog mybinlog.000002 --start-datetime="2022-11-05 10:02:56" --stop-datetime="2022-11-05 11:02:54"
#按字节数:
mysqlbinlog mybinlog.000002 --start-position=337
mysqlbinlog mybinlog.000002 --stop-position=662
mysqlbinlog mybinlog.000002 --start-position=337 --stop-position=662
#如果是行级模式,想要看懂详细内容则需要加上额外参数,但是仅用于看懂内容,如果要用于还原数据,还是应该去掉额外的参数并将内容定位到文件中
mysqlbinlog --base64-output=decode-rows -vvv mybinlog.000002 # 仅用于查看,不
#能用于日后的数据恢复
mysqlbinlog mybinlog.000002 --start-position=100 > /tmp/1.sql # /tmp/1.sql可用于日后的数据恢复
【使用binlog恢复数据】
#修改数据
begin; #开启事务
update user set name="XXX" where name="hzl2";
commit;
#发现自己修改错了
select * from user;
#回滚,回滚不了,已经提交了
rollback; #回滚事务
select * from user;
#一怒之下删表
drop table user;
#恢复数据:查看binlog数据的起始点与要恢复到的位置点,导出成SQL
mysqlbinlog mybinlog.000002 --stop-position=772 > /tmp/binlog.sql
mysql -uroot -pHzl@20144 < /tmp/binlog.sql
【刷新与清除binlog日志】
1、刷新binlog
#刷新binlog:关闭当前的二进制日志文件并创建一个新文件
1)#手动执行命令刷新
flush logs;
或者
mysqladmin -uroot -p flush-logs; #不登录数据库进行刷新
或者
mysql -uroot -pHzl@20144 -e 'flush logs' #使用参数指定sql语句
2)#重启数据库时会刷新
3)#二进制日志上限(max_binlog_size);当binlog达到1G,自动刷新
2、清除binlog
#清除二进制日志原则
#在存储能力范围内,能多保留则多保留,基于上一次全备前的可以选择删除
1) 删除所有binlog,相当于重置
reset master;
2) 删除指定binlog名之前的所有binlog(保留指定的binlog)
purge binary logs to 'mybinlog.00003'; -- mybinlog.00003之前的都删除掉
3)删除日期之前的日志:手动执行
PURGE {MASTER | BINARY} LOGS BEFORE 'date' --用于删除日期之前的日志,BEFORE变量的
date自变量可以为'YYYY-MM-DD hh:mm:ss'格式
#如:(MASTER 和BINARY 在这里都是等效的)
PURGE MASTER LOGS TO 'mybinlog.00003';
purge binary logs before '2021-07-13 19:11:00';
还可以做减法:如只保留3天的
PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;
4)删除日期之前的日志:修改配置参数,让mysql自动执行删除7天前的binlog
#临时生效
SET GLOBAL expire_logs_days = 7;
#永久生效
[root@db01 data]# vim /etc/my.cnf
[mysqld]
expire_logs_days = 7
【日志总述】
【二进制日志】
以二进制文件的形式记录了数据库的操作,但是不记录查询语句,也叫变更日志
################################ 启动与设置二进制日志 #############################
#在mysql配置文件中添加
[root@hzl ]# vim /etc/my.cnf
[mysqld]
log-bin=/var/lib/mysql/mybinlog #默认路径filename自定义
#log-bin = ./my-binlog #不设置绝对路径,在工作目录下
#查看binlog生成文件
[root@hzl /]# ll /var/lib/mysql/ |grep binlog
-rw-r----- 1 mysql mysql 0 7月 17 01:10 mybinlog
-rw-r----- 1 mysql mysql 177 7月 17 01:10 mybinlog.000001 #每启动一次重启时生成一个的文件
-rw-r----- 1 mysql mysql 154 7月 17 01:10 mybinlog.000002
-rw-r----- 1 mysql mysql 62 7月 17 01:10 mybinlog.index
#叙述:
1)启动与设置二进制日志:在Mysql的配置文件中添加此参数:log-bin=DIR/filename #DIR是存放二进制日志的目录,一般自定义在mysql目录下;
2)每启动一次Mysql,该目录下就会生成一个filename.00000x的文件;
3)目录下还有一个filename.index的文件,用于存储所有二进制文件清单;
4)如果我们没有设置DIR和filename,则默认在数据目录下以hostname-bin.00000x命名
################################# 查看binlog ##############################
#直接查看binlog日志文件
[root@web01 mysql]# mysqlbinlog mybinlog.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#210717 1:03:52 server id 1 end_log_pos 123 CRC32 0x74bd29b5 Start: binlog v 4, server v 5.7.34-log created 210717 1:03:52 at startup
ROLLBACK/*!*/;
........
.....
#mysql命令行查看binlog
mysql> show master logs\G #查看所有binlog
*************************** 1. row ***************************
Log_name: mybinlog.000001
File_size: 177
*************************** 2. row ***************************
Log_name: mybinlog.000002
File_size: 154
2 rows in set (0.00 sec)
#################################### 删除binlog ################################
#删除二进制日志binlog
mysql> reset master; #表示删除所有binlog
Query OK, 0 rows affected (0.02 sec)
#指定删除00004之前的所有binlog
mysql> purge master logs to 'mybinlog.000004'; #删除某一个之前的binlog
Query OK, 0 rows affected (0.00 sec)
#指定删除日期之前所有
mysql> purge master logs to '2021-07-19 1:00:00';
############################## 使用binlog还原数据库 #############################
mysqlbinlog mysql-bin.000001 | mysql -u root -p
mysqlbinlog mysql-bin.000002 | mysql -u root -p
#这条命令可以理解为:使用mysqlbinlog读取二进制日志文件然后使用mysql命令还原到数据库中
ps :注意还原时必须是编号小的先还原
mysql> create table t2(id int);
Query OK, 0 rows affected (0.05 sec)
mysql> insert t2 values("1"),("2"),("3");
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from t2;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)
#制定你想恢复的时间点进行恢复binlog
mysqlbinlog --start-position="213" sstop-position="456" mysql-bin.000002 | mysql -u root -p
! ! ! 还没写完,续集