linux系统mysql日志与备份(1)

一、二进制日志

1.作用

1.记录已提交的DML事务语句，并拆分为多个事件（event）来进行记录
2.记录所有DDL、DCL等语句
3.数据的备份恢复
4.数据的复制

#如果我拥有数据库搭建开始所有的二进制日志，那么我可以把数据恢复到任意时刻

2.二进制日志介绍

1.二进制日志默认是关闭的
2.查看二进制
	mysql> show variables like '%log_bin%';
3.配置
	[root@db03 ~]# vim /etc/my.cnf
	server_id=1
	log_bin=/service/mysql/data/mysql-bin
4.开启二进制一般存储子 $datadir/ 下面，以'mysql-bin.00000N'命名

3.二进制日志工作模式

1）工作模式种类

1.statement  语句模式
2.row		行级模式
3.mixed		混合模式

2）查看工作模式

mysql> show variables like '%binlog_format%';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.00 sec)

3）STATEMENT语句模式

#语句模式，mysql5.6默认的模式
记录数据库中操作过得所有sql语句

#查看
[root@db03 data]# mysqlbinlog mysql-bin.000014

#优缺点：
1.易读
2.不安全
3.相对于行级模式占用磁盘空间小

4）row行级模式

#行级模式，mysql5.7默认的模式
记录的是数据的变化过程

#配置行级模式
[root@db03 data]# vim /etc/my.cnf
binlog_format=row

#查看方式
[root@db03 data]# mysqlbinlog --base64-output=decode-rows -vvv mysql-bin.000016

#优缺点：
1.安全
2.不易读
3.相对于语句模式占用磁盘大

5）mixed混合模式

4.二进制管理操作

1）开启二进制

[root@db03 ~]# vim /etc/my.cnf
server_id=1
log_bin=/service/mysql/data/mysql-bin

2）查看二进制日志

#物理查看
[root@db03 data]# ll mysql-bin.*
-rw-rw---- 1 mysql mysql     167 7月  14 18:22 mysql-bin.000001
-rw-rw---- 1 mysql mysql    2636 7月  14 19:07 mysql-bin.000002

#数据库查看
mysql> show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       167 |
| mysql-bin.000002 |      2636 |
+------------------+-----------+

#查看binlog事件
mysql> show binlog events in 'mysql-bin.000016';

3）刷新

#flush logs;

#重启数据库时会刷新

#达到二进制日志上限（max_binlog_size）
mysql> show variables like '%max_binlog_size%';
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| max_binlog_size | 1073741824 |
+-----------------+------------+

4）删除binlog

1.根据存在时间删除日志
#临时生效
SET GLOBAL expire_logs_days = 7;
#永久生效
[root@db01 data]# vim /etc/my.cnf
[mysqld]
expire_logs_days = 7

2.使用purge命令删除
PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;

3.根据文件名删除
PURGE BINARY LOGS TO 'mysql-bin.000010';

4.使用reset master重置binlog
mysql> reset master; 

4.思考

数据库或表被误删除的是很久之前创建的（一年前，100个binlog）
如果基于binlog全量恢复，成本很高
1.可以用备份恢复+短时间内二进制日志，恢复到故障之前
2.非官方方法，binlog2sql，binlog取反，类似于Oracle的flushback
3.延时从库 

如果同一时间内和故障库无关的数据库都有操作，在截取binlog时都会被截取到
其他过滤方案？
1.-d 参数接库名

二、慢日志

1.作用

1.是将mysql服务器中影响数据库性能的相关SQL语句记录到日志文件
2.通过对这些特殊的SQL语句分析，改进以达到提高数据库性能的目的

2.配置

[root@db01 ~]# vim /etc/my.cnf
[mysqld]
#指定是否开启慢查询日志
slow_query_log = 1
#指定慢日志文件存放位置（默认在data）
slow_query_log_file=/service/mysql/data/slow.log
#设定慢查询的阀值(默认10s)
long_query_time=0.05
#不使用索引的慢查询日志是否记录到日志
log_queries_not_using_indexes
#查询检查返回少于该参数指定行的SQL不被记录到慢查询日志
min_examined_row_limit=100（鸡肋）

slow_query_log = 1
slow_query_log_file=/service/mysql/data/slow.log
long_query_time=3
log_queries_not_using_indexes

3.慢日志测试

#建表
mysql> create table solwlog2 select * from city;
Query OK, 4079 rows affected (0.07 sec)
Records: 4079  Duplicates: 0  Warnings: 0

#反复插入
mysql> insert solwlog select * from solwlog;
Query OK, 2088448 rows affected (9.00 sec)
Records: 2088448  Duplicates: 0  Warnings: 0

#查看慢日志
[root@db03 data]# less slow.log

4.使用mysqldumpslow命令来分析慢查询日志

#输出记录次数最多的10条SQL语句
mysqldumpslow -s c -t 10 /database/mysql/slow-log

-s:
是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙；
-t:
是top n的意思，即为返回前面多少条的数据；
-g:
后边可以写一个正则匹配模式，大小写不敏感的；

#例子：
	#得到返回记录集最多的10个查询
	mysqldumpslow -s r -t 10 /database/mysql/slow-log

	#得到按照时间排序的前10条里面含有左连接的查询语句
	mysqldumpslow -s t -t 10 -g "left join" /database/mysql/slow-log

5.扩展

第三方推荐（扩展）：
yum install -y percona-toolkit-3.0.11-1.el6.x86_64.rpm

使用percona公司提供的pt-query-digest工具分析慢查询日志
[root@mysql-db01 ~]# pt-query-digest /application/mysql/data/mysql-db01-slow.log

三、mysql数据备份

#mysql客户端
mysql
mysqladmin
mysqldump

1.备份的原因

1.备份就是为了恢复。
2.尽量减少数据的丢失（公司的损失）

2.备份的类型

1.冷备：停库，停服务，备份
2.热备：不停库，不停服务，备份
3.温备：不停服务，锁表（阻止数据写入），备份

#冷备份:
这些备份在用户不能访问数据时进行，因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是，对于某些应用程序，会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。

#温备份:
这些备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。

#热备份:
这些动态备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。

3.备份的策略

1.全备：全部数据备份
2.增备：针对于上一次备份，将新数据备份
3.差异备份：基于上一次全备进行新数据的备份

4.备份方式

1）逻辑备份

#基于SQL语句的备份
1.binlog
2.into outfile
	[root@db03 data]# vim /etc/my.cnf
	[mysqld]
	secure-file-priv=/tmp
	mysql> select * from world.city into outfile '/tmp/world_city.data';

3.mysqldump
4.replication

2）物理备份

#备份底层的数据文件
1.备份整个data数据目录
2.xtrabackup

四、mysqldump客户端

1.常用参数

1.不加参数：用于备份单个表
    1）备份库
    [root@db02 ~]# mysqldump ku > /tmp/ku.sql
    2）备份表
    [root@db02 ~]# mysqldump ku test > /tmp/ku.sql
    3）备份多个表
    [root@db02 ~]# mysqldump ku test test2 test3 > /tmp/ku.sql
    #注意：当不加参数时命令后面跟的是库名，库的后面全都是必须是库下面的表名

2.连接服务端参数(基本参数)：-u -p -h -P -S

3.-A, --all-databases：全库备份

4.-B：指定库备份
[root@db01 ~]# mysqldump -uroot -p123 -B db1 > /backup/db1.sql
[root@db01 ~]# mysqldump -uroot -p123 -B db1 db2 > /backup/db1_db2.sql

5.-F：flush logs在备份时自动刷新binlog（不怎么常用）
[root@db01 backup]# mysqldump -uroot -p123 -A -F > /backup/full_2.sql

6.--master-data=2：备份时加入change master语句0没有1不注释2注释
	1）等于2：记录binlog信息，并注释（日常备份）
	2）等于1：记录binlog信息，不注释（扩展从库）
	0）等于0：不记录binlog信息
	[root@db01 backup]# mysqldump -uroot -p123 --master-data=2 >/backup/full.sql

7.--single-transaction：快照备份

8.-d：仅表结构
9.-t：仅数据

10.-R, --routines：备份存储过程和函数数据
11.--triggers：备份触发器数据
12.gzip:压缩备份
	#备份成压缩包
	[root@db01 ~]# mysqldump -uroot -p123 -A | gzip > /backup/full.sql.gz
	#恢复压缩包中的数据
	[root@db03 ~]# zcat /tmp/full.sql.gz | mysql -uroot -p123

#完整的备份命令：
mysqldump -uroot -p123 -A -R --triggers --master-data=2 –-single-transaction > /tmp/full.sql

2.注意：

1）mysqldump在备份和恢复时都需要MySQL实例启动为前提
2）一般数据量级100G以内，大约15-30分钟可以恢复
3）mysqldump是以覆盖的形式恢复数据的

五、企业案例

1.背景

1.正在运行的网站系统，MySQL数据库，数据量25G，日业务增量10-15M。
2.备份策略：每天23：00，计划任务调用mysqldump执行全备脚本
3.故障时间点：上午10点开发人员误删除一个核心业务表，如何恢复？

2.思路

1.停库，避免二次伤害
2.创建新库
3.倒入前一天的全备
4.通过binlog找到前一天23：00到第二天10点之间的数据
5.导入找到的新数据
6.恢复业务
	a.直接使用临时库顶替原生产库，前端应用割接到新库（数据量特别大的时候）
	b.将误删除的表单独导出，然后导入到原生产环境（数据量小的时候）

3.模拟案例

1）模拟生产数据

mysql> create database dump;
mysql> use dump
mysql> create table dump(id int);
mysql> insert dump values(1),(2),(3),(4);
mysql> select * from dump;

2）模拟23:00全备

[root@db03 mysql]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 --single-transaction > /tmp/full.sql

3）模拟23：00到10:00的数据操作

mysql> use dump
mysql> insert dump values(1000),(2000),(3000),(4000);

4）模拟删库

mysql> drop database dump;
Query OK, 1 row affected (0.00 sec)

4.恢复数据

1）停库，避免二次伤害

[root@db03 mysql]# systemctl stop mysqld

2）创建新库

3）导入前一天的全备

#老库将数据传输到新库
[root@db03 ~]# scp /tmp/full.sql 172.16.1.52:/tmp/
#新库导入全备数据
[root@db02 ~]# mysql < /tmp/full.sql

4）通过binlog找到前一天23：00到第二天10点之间的数据

1.找到binlog的起始位置点
[root@db03 data]# head -22 /tmp/full.sql | tail -1
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=971790;

2.找到结束位置点
[root@db03 data]# mysqlbinlog mysql-bin.000006 > 1.txt
[root@db03 data]# vim 1.txt
过滤 drop database dump，取出命令上面的位置点
# at 972068
......
drop database dump

3.取出位置点之间的数据
[root@db03 data]# mysqlbinlog -d dump --start-position=971790 --stop-position=972068 mysql-bin.000006 > /tmp/new.sql

5）导入找到的新数据

#老库将binlog数据传到新库
[root@db03 ~]# scp /tmp/new.sql 172.16.1.52:/tmp/

#新库导入新的数据
[root@db02 ~]# mysql < /tmp/new.sql

6）确认数据

mysql> use dump

mysql> show tables;
+----------------+
| Tables_in_dump |
+----------------+
| dump           |
+----------------+

mysql> select * from dump;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
| 1000 |
| 2000 |
| 3000 |
| 4000 |
+------+

7）恢复业务

1.直接使用临时库顶替原生产库，前端应用割接到新库（数据量特别大的时候）
2.将误删除的表单独导出，然后导入到原生产环境（数据量小的时候）
	1）新库导出指定业务库
	[root@db02 ~]# mysqldump dump > /tmp/dump.sql
	2）新库将数据推送回老库
	[root@db02 ~]# scp /tmp/dump.sql 172.16.1.53:/tmp
	3）将恢复的数据导入老库
	mysql> create database dump;
	mysql> use dump;
	mysql> source /tmp/dump.sql