mysql数据库日志与备份

Posted 2020-11-14

1、事务隔离级别

事务隔离级别：
READ UNCOMMITTED 可读取到未提交的新的数据，产生脏读
READ COMMITTED 可读提交数据，但未提交数据不可读 ，产生不可重复读，即可读取到
多个提交数据，导致每次读取数据不一致；例如一个读的时间比较长的事务由于其它事务在更改
数据并提交，那么读的数据每次都在变化；
REPEATABLE READ 可重复读，多次读取数据都一致，产 生幻读，即读取过程中，即使有
其它提交的事务修改数据， 当前事务仍只能读取到未修改前的旧数据。此为mysql默认设置 ；
但是如果提交当前事务后开启新的事务进行查询就会查到更改后的数据；
SERIALIZABILE 可串行化，未提交的读事务阻塞修改事务，或者未提交的修改事务阻塞读
事务。导致并发性能较差；容易阻塞效率差；

2、事务隔离级别

3、事务

tx_isolation：服务器变量，默认为REPEATABLE-READ， 可在SESSION级进行修改
SET tx_isolation=‘‘
READ-UNCOMMITTED
READ-COMMITTED
REPEATABLE-READ
SERIALIZABLE
MVCC: 多版本并发控制，和事务级别相关
常用命令：
show variables like ‘tx_isolation‘; 查看设置隔离级别的系统变量的默认设置
set global tx_isolation=‘read-uncommitted‘; 设置隔离级别为脏读
start transaction; 手动开启事务，必须提交才能生效
delete from students where stuid=26;
select * from students; 两个用户都执行就可以看到未提交都可读，此为脏读
rollback; 撤销，发现都不能读了
set tx_isolation=‘read-committed‘; 设置不可重复读
set tx_isolation=‘serializable‘;
show variables like ‘tx_isolation‘;
start transaction;
select name,sleep(1) from students; 进行读事务，读完如果不提交事务；另一个用户还
会继续阻塞；
delete from students where stuid=20; 修改数据被阻塞
注意：修改文件使得隔离级别生效时要使用transaction_isolation=serialiazble

4、并发控制

死锁： 两个或多个事务在同一资源相互占用，并请求锁定对方占用的资源的状态
事务日志：
事务日志的写入类型为“追加”，因此其操作为“顺序 IO”，即磁头不用到处移动就可以写数
据，而随机IO写磁头移动频繁比较花费时间；此日志通常也被称为：预写式日志；同时由于此顺
序IO特性，写日志的时间明显比写磁盘数据快，恰巧产生断电的几率就比较小；
write ahead logging
show variables like ‘innodb_log%‘;
innodb_log_file_size 默认5M
innodb_log_files_in_group 默认2，轮流写满
innodb_log_group_home_dir 默认数据库日志所在目录
日志文件： ib_logfile0， ib_logfile1

死锁实验：
一边：
start transaction;
select * from teachers;
update students set name=‘yong‘ where stuid=4; 1 占有
update teachers set name=‘yong‘ where tid=4; 3 访问另一边占有的资源被阻塞
另一边：
start transaction;
update teachers set name=‘wang‘ where tid=4; 2 占有
update students set name=‘hello‘ where stuid=4; 4 访问一边占有的资源死锁
系统发现死锁，将另一边的占有资源释放，即后执行的资源释放，事务结束；基于innodb行
级锁实现；

日志迁移实验：
mkdir /data/mysqllog -pv 创建新的日志存放目录
chown -R mysql.mysql /data/mysqllog/ 设置目录以及文件的属主和属组
vim /etc/my.cnf
innodb-log-group-home-dir=/data/mysqllog
systemctl restart mariadb
ll /data/mysqllog/ -h
测试：执行事务，观察日志文件的时间是否变化
结果：事务日志由/var/lib/mysql目录迁移到了/data/mysqllog下面
注意：此实验需要预先关闭防火墙和selinux安全机制

5、日志

日志
事务日志：transaction log;
查询日志：query log；
慢查询日志：slow query log
错误日志：error log
二进制日志：binary log
中继日志：reley log

6、日志

查询日志
记录查询操作：
文件：file
表：table
查询日志相关设置
general_log=ON|OFF 不推荐开启，记录太详细
general_log_file=HOSTNAME.log 可以更改路径
log_output=TABLE|FILE|NONE
实验：
1、vim /etc/my.cnf 修改文件
general_log=1 开启日志,默认写到/var/lib/mysql下
2、systemctl restart mariadb 重启服务
3、用命令测试查询日志具体记录的是什么
cat /var/lib/mysql/localhost.log
select from students;
update students set name=haha where stuid=24;
cat /var/lib/mysql/localhost.log
4、更改查询日志文件的路径
vim /etc/my.cnf
general_log_file=/var/log/mariadb/sql.log 此目录不必修改权限
5、systemctl restart mariadb 再次重启服务
6、ls /var/log/mariadb/ 查看是否路径修改成功
7、将查询日志文件写到表中
vim /etc/my.cnf
log_output=table
8、systemctl restart mariadb 重新启动服务
9、查看表是否写入日志
use mysql；
show tables;
select from general_log;
10、查看在写到表后是否还向之前的 /var/lib/mysql/localhost.log文件中写入日志
cat /var/lib/mysql/localhost.log 观察时间可以知道
11、关闭查询日志
vim /etc/my.cnf
删除之前加入的，然后重启mariadb服务
注意：/root下的.mysql_history文件记录了在mysql数据库中执行的所有历史命令;此查询日志不
同，是记录查询或修改的SQL语句；

7、日志

慢查询日志：记录执行查询时长超出指定时长的操作
SHOW GLOBAL VARIABLES LIKE ‘long_query_time‘;
SELECT @@GLOBAL.long_query_time;
SET GLOBAL long_query_time=N 单位秒
slow_query_log=ON|OFF 开启或关闭慢查询
slow_query_log_file=HOSTNAME-slow.log 慢查询日志文件
log_slow_filter = admin,filesort,filesort_on_disk,full_join,full_scan,query_cach
e,query_cache_miss,tmp_table,tmp_table_on_disk 这些情况不记录慢查询
log_queries_not_using_indexes=ON 不使用索引是否记录日志，默认OFF，即不记录；
log_slow_rate_limit = 1 多少次查询才记录，mariadb特有
log_slow_verbosity= Query_plan,explain 记录内容
log_slow_queries = OFF 同slow_query_log 新版已废弃
实验：
1、开启慢查询日志
ls /var/lib/mysql 查看是否有慢查询日志文件
set global slow_query_log=on;
ls /var/lib/mysql 查看是否有慢查询日志文件
2、查看日志文件内容
cat /var/lib/mysql/localhost-slow.log
3、模拟慢查询
show variables like ‘long_query_time‘; 显示慢查询时间
select name,sleep(1) from hellodb.students
4、查看慢查询是否有记录
cat /var/lib/mysql/localhost-slow.log
5、结果没有记录，是sleep模拟不正确
6、重新进行实验
（1）创建表
create table t1 (id int auto_increment primary key,name char(20),age int default
20);
desc t1;
（2）测试变量组合成名字
set @i=20;
select @i;
select concat(‘wang‘,@i);
（3）创建存储过程
delimiter //
create procedure slowquery() begin declare i int;set i=1; while i< 100000 do insert
into t1(name,age) values(concat(‘wang‘,i),i);set i=i+1;end while;end //
delimiter ;
call slowquery();
（4）编辑文件
vim /etc/my.cnf
long_query_time=0.05
slow_query_log=on
slow_query_log_file=hello2
（5）重启服务
systemctl restart mariadb
（6）进行测试
select * from t1; 查询时间大于0.05秒
cat /var/lib/mysql/hello2 查看慢查询的记录
（7）得出结论
慢查询确实会记录
常用命令：
select name from hellodb.t1 where name=‘wang99998‘;
create index index_name on t1(name);
select name from hellodb.t1 where name=‘wang99998‘;
explain select name from hellodb.t1 where name=‘wang99998‘;
drop index index_name on t1;
explain select name from hellodb.t1 where name=‘wang99998‘;
8、日志

错误日志
mysqld启动和关闭过程中输出的问题事件信息
mysqld运行中产生的错误信息
event scheduler运行一个event时产生的日志信息
在主从复制架构中的从服务器上启动从服务器线程时产 生的信息
错误日志相关配置
SHOW GLOBAL VARIABLES LIKE ‘log_error‘;
错误日志文件路径：
log_error=/PATH/TO/LOG_ERROR_FILE
是否记录警告信息至错误日志文件
log_warnings=1|0: 1记录，0不记录
show variables like ‘log_warnings‘;

9、日志

二进制日志
记录导致数据改变或潜在导致数据改变的SQL语句
功能：通过“重放”日志文件中的事件来生成数据副本
注意：建议二进制日志和数据文件分开存放
二进制日志相关配置
查看mariadb自行管理使用中的二进制日志文件列表
SHOW {BINARY | MASTER} LOGS; master和binary是等价的
查看使用中的二进制日志文件
show master status;
File：mysql-binlog.000001 指的是日志为哪个文件
Position：75932947 指的是日志写到哪个位置了；一旦发生修改操作，就会导致位
置变化；
查看指定二进制文件中的内容
SHOW BINLOG EVENTS [IN ‘log_name‘] [FROM pos] [LIMIT [offset,] row_count]
show binlog events in ‘mariadb-bin.000001‘ from 6516 limit 2,3;
常用命令：
show binary logs; 显示二进制日志
show variables like ‘log_bin‘; 显示二进制日志变量，指定文件位置
show variables like ‘sql_log_bin‘; 是否记录二进制日志
注意：记录数据库的增删改操作，不是基于引擎的；

10、日志

二进制日志记录格式
二进制日志记录三种格式
基于“语句”记录：statement，记录语句，默认模式 ；如果语句中有时时变化的函数如
now（），那么还原就不能和原来完全一样；
基于“行”记录：row，记录数据，日志量较大；记录的是语句的返回结果；
混合模式：mixed, 让系统自行判定该基于哪种方式进行
格式配置
show variables like ‘%binlog_format%‘;
二进制日志文件的构成
有两类文件
日志文件：mysql|mariadb-bin.文件名后缀，二进制格式
如： mysql-bin.000001
索引文件：mysql|mariadb-bin.index，文本格式，记录二进制文件有哪些
实验： 二进制日志记录格式
1、执行语句，进行测试
delete from students where gender=‘F‘;
mysqlbinlog /data/binlog/mysql-binlog.000002 查看日志看出只记录一条语句，
不是很详细；
mysqlbinlog /data/binlog/mysql-binlog.000002 -v 显示的详细了但是语句还是原来
的；
2、编辑文件，改变日志文件记录的格式
vim /etc/my.cnf
binlog_format=row
3、重启服务
systemctl restart mariadb 每重启一次，二进制日志文件就滚动一个新的文件
4、测试
delete from students where gender=‘F‘;
mysqlbinlog /data/binlog/mysql-binlog.000002 发现没有记录
mysqlbinlog /data/binlog/mysql-binlog.000003 -v 日志发生滚动了，更改查询
实验：利用二进制日志文件
1、将日志导入一个文件中
data/binlog/mysql-binlog.000004 > binlog
2、执行命令，测试
delete from students where stuid=22;
mysql < binlog 还原，里面有insert语句
3、这就是生成原来环境的方法
注意：二进制日志不要随便删除，即使再次完全备份了；留一段时间可以防止误操作而
不能还原到原来的数据；
11、日志

二进制日志相关的服务器变量：
sql_log_bin=ON|OFF：是否记录二进制日志，默认ON ；相比于下一项可以动态修改，而不
用重启服务；
log_bin=/PATH/BIN_LOG_FILE：指定文件位置；默认 OFF，表示不启用二进制日志功能，
上述两项都开启才可
binlog_format=STATEMENT|ROW|MIXED：二进制日志记录的格式，默认STATEMENT
max_binlog_size=1073741824：单个二进制日志文件的 最大体积，到达最大值会自动滚
动生成新的文件，默认为1G
说明：文件达到上限时的大小未必为指定的精确值
sync_binlog=1|0：设定是否启动二进制日志即时同步磁盘 功能，默认0，由操作系统负责同
步日志到磁盘
expire_logs_days=N：二进制日志可以自动删除的天数。 默认为0，即不自动删除
实验1：启动二进制日志
1、编辑文件
vim /etc/my.cnf
log_bin
2、重启数据库服务
systemctl restart mariadb
3、查看二进制日志文件
ll /var/lib/mysql/
mariadb-bin.index 记录二进制日志文件有哪些，列表
cat mariadb-bin.index
mariadb-bin.000001 二进制文件
实验2：指定分区存放二进制日志
1、创建目录（当做分区）
mkdir /data/binlog/ -pv
2、更改目录的权限属性
chown -R mysql:mysql /data/binlog/
3、编辑文件
vim /etc/my.cnf
log_bin=/data/binlog/mysql-binlog
4、重启服务
systemctl restart mariadb
5、查看日志情况
ll /var/lib/mysql/
ll /data/binlog/
6、数据库执行命令
call slowquery;
7、时时查看日志文件的大小
ll /data/binlog/ 发现日志文件在不断的变大
8、执行未提交的命令，查看文件的大小变化
start transaction;
call slowquery;
ll /data/binlog/
发现不变
commit
ll /data/binlog/ 提交后查看文件的大小，发现大幅度增长了
注意：由于不可能时时进行备份，所以二进制日志很重要；如果磁盘坏了，那么可以先进行一次
全备份恢复，然后利用二进制日志恢复数据库到最新状态；二进制日志文件记录的是提交完成的
数据，和存储引擎无关，记录所有的数据库改变操作；而事物日志文件在未提交就记录；二进制
日志文件不会覆盖写数据，而是一直增长；二进制日志在生产中是强烈建议启用的；

12、日志

mysqlbinlog：二进制日志的客户端命令工具
命令格式：
mysqlbinlog [OPTIONS] log_file…
--start-position=# 指定开始位置
--stop-position=#
--start-datetime= 不推荐，因为一个秒可能进行多个操作，查询不够精确
--stop-datetime=
时间格式：YYYY-MM-DD hh:mm:ss
--base64-output[=name]
示例：mysqlbinlog --start-position=6787 --stop-position=7527 /var/lib/mysql/mariadb-
bin.000003
mysqlbinlog --start-datetime="2018-01-30 20:30:10" -stop-datetime="2018-01-30
20:35:22" mariadb-bin.000003;
实验：mysqlbinlog选项
1、修改文件
vim hellodb2_InnoDB.sql
将hellodb替换为hellodb2
2、导入
mysql < hellodb2_InnoDB.sql
3、对hellodb进行操作
delete from students where stuid=20; 需要use hellodb才能在4中导出到文件
4、查看日志进行检验
mysqlbinlog -d hellodb2 /data/binlog/mysql-binlog.000004 > binlog_hellodb2
mysqlbinlog -d hellodb /data/binlog/mysql-binlog.000004 > binlog_hellodb
13、日志

二进制日志事件的格式：

at 328

#151105 16:31:40 server id 1 end_log_pos 431 Query thread_id=1 exec_time=0
error_code=0
use mydb/!/;
SET TIMESTAMP=1446712300/!/;
CREATE TABLE tb1 (id int, name char(30))
/!/;
事件发生的日期和时间：151105 16:31:40
事件发生的数据库服务器标识：server id 1
事件的结束位置：end_log_pos 431
事件的类型：Query
事件发生时所在服务器执行此事件的线程的ID：thread_id=1
语句的时间戳与将其写入二进制文件中的时间差：exec_time=0
错误代码：error_code=0
事件内容： GTID：Global Transaction ID，mysql5.6以mariadb10以上版本专属属性

14、日志

清除指定二进制日志：
PURGE { BINARY | MASTER } LOGS { TO ‘log_name‘ | BEFORE datetime_expr }
示例：
PURGE BINARY LOGS TO ‘mariadb-bin.000003’;删除3前日志
PURGE BINARY LOGS BEFORE ‘2017-01-23‘;
PURGE BINARY LOGS BEFORE ‘2017-03-22 09:25:30‘;
删除所有二进制日志，index文件重新记数
RESET MASTER [TO #]; 日志文件从#开始记数，默认 从1开始， 说明：此语句一般是
master第一次启动时执行；指定数字时要考虑版本问题，5.5.6是不行的
切换日志文件：
FLUSH LOGS; 手动换为新的二进制文件存放日志
注意：删除日志文件一定慎重；先备份再删除，备份的日志一定要确定能够使用；用purge命令
删除日志是按文件进行删的，如果另一个文件中既有符合条件的又有不符合条件的，那么不会删
除这个文件；

15、日志

中继日志：relay log （之后讲解）
主从复制架构中，从服务器用于保存从主服务器的二进制日志 中读取到的事件
事务日志：transaction log
事务型存储引擎自行管理和使用
redo log
undo log
Innodb事务日志相关配置：
show variables like ‘%innodb_log%‘;
innodb_log_buffer_size 事务日志的缓存区大小
innodb_log_file_size 5242880 每个日志文件大小
innodb_log_files_in_group 2 日志组成员个数
innodb_log_group_home_dir ./ 事务文件路径
注意：由于日志的重要性，建议将日志与数据文件分开存放，日志文件放到固态磁盘上；日志文
件要足够大，否则大事务写满两个文件后将会在事务没有提交的时候将数据写磁盘（如/var/lib/mysql/hellodb/t1.ibd）以可以覆盖旧的日志，但是如果要rollback那么没有之前的日志是不行的，而且只能撤销数据不能回收空间，很麻烦了；当然也可以增加日志文件个数；
事物日志应该放在 一个独立的分区，以防止顺序写空间被其它数据文件占用

16、备份和恢复

为什么要备份
灾难恢复：硬件故障、软件故障、自然灾害、××××××、误操作 测试等数据丢失场景
备份注意要点
能容忍最多丢失多少数据
恢复数据需要在多长时间内完成 恢复数据要先停机
需要恢复哪些数据
还原要点
做还原测试，用于测试备份的可用性
还原演练 定期还原演练以熟练

17、备份和恢复

备份类型：
完全备份，部分备份
完全备份：整个数据集
部分备份：只备份数据子集，如部分库或表 这些数据变化比较频繁
完全备份、增量备份、差异备份
增量备份：仅备份最近一次完全备份或增量备份（如果存 在增量）以来变化的数据，备
份较快，还原复杂
差异备份：仅备份最近一次完全备份以来变化的数据，备 份较慢，还原简单
注意：二进制日志文件不应该与数据文件放在同一磁盘

18、备份和恢复

热备份、温备份、冷备份
热备：读写操作均可执行 事务机制
温备：读操作可执行；但写操作不可执行 如银行两个账号转账数据不同步
冷备：读写操作均不可进行 关闭服务进行备份
MyISAM：温备，不支持热备
InnoDB: 都支持
物理和逻辑备份
物理备份：直接复制数据文件进行备份，与存储引擎有关， 占用较多的空间，速度快
逻辑备份：从数据库中“导出”数据另存而进行的备份，与 存储引擎无关，占用空间少，速度
慢，可能丢失精度 ；相当于执行查询语句将结果导出；
注意：物理备份需要打包数据文件和日志文件，而且/etc/my.cnf配置文件也要进行复制；复制之前要将服务停止；mysql是针对中小型数据存放的（在1T以下）；
19、备份和恢复

备份时需要考虑的因素
温备的持锁多久
备份产生的负载
备份过程的时长
恢复过程的时长
备份什么
数据
二进制日志、InnoDB的事务日志
程序代码（存储过程、存储函数、触发器、事件调度器）
服务器的配置文件

20、备份和恢复

设计备份方案
数据集：完全+增量
备份手段：物理，逻辑
备份工具
mysqldump：逻辑备份工具，适用所有存储引擎，温备； 支持完全或部分备份；对InnoDB
存储引擎支持热备
cp, tar等复制归档工具：物理备份工具，适用所有存储引 擎；只支持冷备；完全和部分备份
LVM的快照：先加锁，做快照后解锁，几乎热备；借助文 件系统管理工具进行备份
mysqlhotcopy：几乎冷备；仅适用于MyISAM存储引擎

21、备份和恢复

备份工具的选择：
mysqldump+复制binlog：
mysqldump：完全备份
复制binlog中指定时间范围的event：增量备份
LVM快照+复制binlog：
LVM快照：使用cp或tar等做物理备份；完全备份
复制binlog中指定时间范围的event：增量备份
xtrabackup：
由Percona提供支持对InnoDB做热备(物理备份)的工具 完全备份、增量备份
mysqlbackup：热备份， MySQL Enterprise Edition组件 付费的

22、备份和恢复

逻辑备份工具：mysqldump, mydumper, phpMyAdmin
Schema和数据存储在一起、巨大的SQL语句、单个巨大的备份文件
mysqldump：
客户端命令，通过mysql协议连接至mysqld服务器
mysqldump [options] [db_name [tbl_name ...]]
mysqldump [options] db_name [tbl_name ...]
mysqldump [options] –databases|B db_name ...
mysqldump [options] --all-databases|A
mysqldump参考：
https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html
实验1：演示备份与还原 数据库比较大时为保证数据的一致性，不可用
mkdir /backups 创建目录作为备份文件的存放地
mysql -e ‘show databases;‘ 不进入数据库就查看有哪些数据库
mysqldump hellodb|less 发现备份的大SQL语句中没有创建数据库的语句
mysqldump hellodb > /backups/hellodb.sql 备份到指定文件
mysql -e ‘drop database hellodb;‘ 先删除数据库，然后还原
mysql -e ‘create database hello;‘ 由于备份时没有创建数据库的语句，故而此时在还
原之前需要手动创建数据库，可能和原来创建的语法不一样，如编码机制等
show create database hello; 可以查看创建数据库时的各种定义如编码字符等
mysql hello < /backups/hellodb.sql 进行数据库的还原
实验2：
mysqldump hello students > /backups/hellodb_students.sql 备份数据库中的一个表
mysql test < /backups/hellodb_students.sql 还原表到数据库
23、备份和恢复

mysqldump常见选项：
-A， --all-databases 备份所有数据库，含create database
-B , --databases db_name… 指定备份的数据库，包括 create database语句
-E, --events：备份相关的所有event scheduler
-R, --routines：备份所有存储过程和存储函数
--triggers：备份表相关的触发器，默认启用,用--skiptriggers，不备份触发器
--master-data[=#]： 此选项须启用二进制日志
1：所备份的数据之前加一条记录为CHANGE MASTER TO语 句，非注释，不指定#，
默认为1；用于主从复制
2：记录为注释的CHANGE MASTER TO语句 此选项会自动关闭--lock-tables功能，自
动打开--lock-alltables功能（除非开启--single-transaction）
实验1：
mysqldump -A > /backups/all.sql 备份所有数据库 写锁有多个也有可能造成数据不一
致
cat /backups/all.sql|grep ‘CREATE DATABASE‘|head -n3 可以看到有创建数据库的语句
systemctl stop mariadb 停止服务
rm -rf /var/lib/mysql/ 删除数据库文件
systemctl start mariadb 重启服务后系统库被自动创建，而自己写的数据库没有了
mysql < /backups/all.sql 进行还原数据库操作
select user from user; 查看test账号是否被还原
show variables like ‘character%‘; 查看字符集的类型；创建数据库时和字符集有关
实验2：
mysqldump -B test hello > /backups/hello_test.sql 备份两个数据库
less /backups/hello_test.sql 里面有创建数据库的操作
rm -rf /var/lib/mysql/hello 删除hello数据库
rm -rf /var/lib/mysql/test/ 删除test数据库
mysql < /backups/hello_test.sql 进行还原数据库的操作，不能成功；如果将服务停止后
再进行删除，也不能还原；说明直接删除的方式有错误；正常用drop命令进行删除是可以还原的
rm -rf /var/lib/mysql/ 清空
systemctl restart mariadb 重启生成系统数据库
mysql < /backups/hello_test.sql 进行还原成功
mysqldump -A |gzip > /backups/all_gz.sql.gz 先压缩再备份
mysqldump -A |xz > /backups/all_xz.sql.xz 压缩备份；
注意：先压缩再备份虽然节省空间但会比较慢，要先备份完再压缩才好点
gzip hello_test.sql 先备份再压缩
实验3：
delimiter // 改变结束符
create procedure slowquery() begin declare i int;set i=1; while i< 100000 do insert into
t1(name,age) values(concat(‘wang‘,i),i);set i=i+1;end while;end// 创建存储过程
mysqldump -A > /backups/all.sql 进行所有数据库的备份，包括存储过程、触发器等
grep slowquery /backups/all.sql 可以看出备份中含有所创建的存储过程
rm -rf /var/mysql/ 删除数据库
systemctl start mariadb 重启服务
mysql < /backups/all.sql 将备份进行还原
call slowquery; 还原后进行存储过程的调用
use mysql; 进入系统数据库
select from procG; 查看表中的数据；表中记录了存储过程
实验4：
mysqldump -A --master-data=1 > /backups/all_1.sql 进行完全备份，并记录二进制日志
的当前时间点，以在数据破坏的时候可以先完全备份还原再依靠二进制日志增量备份还原
mysqldump -A --master-data=2 > /backups/all_2.sql 同上，但是记录时间点有注释
diff /backups/all_2.sql /backups/all_1.sql 比较两个备份文件的不同点
yum install mariadb-server 在新机器上安装mariadb
delete from students where stuid=22; 在完全备份后执行的语句，由二进制日志记录
scp /data/binlog/mysql-binlog.000023 172.18.62.61:/app 将二进制日志文件放到不被破
坏的地方，如另一个机器；
scp /etc/my.cnf 172.18.62.61:/etc/my.cnf 复制配置文件
scp /backups/all_1.sql 172.18.62.61:/app 复制完全备份的数据文件
systemctl start mariadb 在新机器上启动服务
mysqlbinlog /app/mysql-binlog.000023 --start-position=530432 > /app/binlog 将完全备
份中指定位置开始的二进制日志导出来
mysql < /app/all_1.sql 完全备份的还原
mysql < /app/binlog 增量备份的还原
select * from students; 进入数据库查看是否完成还原
24、备份和恢复

mysqldump常见选项
-F, --flush-logs ：备份前滚动日志，锁定表完成后，执行flush logs命令,生成新的二进制日志
文件，配合-A时，会导致刷新多个数据 库，在同一时刻执行转储和日志刷新，则应同时使用--
flush-logs和x，--master-data或--single-transaction,此时只刷新一次 ；建议：和-x，--master-
data或 --single-transaction一起使用 ；-x一般用于MyISAM引擎的数据库；
--compact 去掉注释，适合调试，生产不使用
-d, --no-data 只备份表结构
-t, --no-create-info 只备份数据,不备份create table
-n,--no-create-db 不备份create database，可被-A或-B覆盖
--flush-privileges 备份mysql或相关时需要使用
-f, --force 忽略SQL错误，继续执行
--hex-blob 使用十六进制符号转储二进制列（例如，“abc”变 为0x616263），受影响的数据
类型包括BINARY， VARBINARY， BLOB，BIT
-q, --quick 不缓存查询，直接输出，加快备份速度
实验1：
mysqldump -A -F > /backups/all_A-F.sql 备份前刷新日志
ls /data/binlog/ -l 发现有几个数据库就生成几个日志文件;每备份一个数据库前就刷新一次
日志；
实验2：
mysqldump -A --compact > /backups/all_c.sql 去掉注释进行备份
mysqldump -A > /backups/all.sql 包含注释的备份
ll /backups/ 比较两个备份的大小
25、备份和恢复

MyISAM备份选项： 支持温备；不支持热备，所以必须先锁定要备份的库，而后 启动备份操作
锁定方法如下：
-x,--lock-all-tables：加全局读锁，锁定所有库的所有表 ，同时加--single-transaction或--
lock-tables选项会关闭 此选项功能
注意：数据量大时，可能会导致长时间无法并发访问数据库
-l,--lock-tables：对于每个单独的数据库，在启动备份之 前分别锁定其所有表，默认为on,可
使用--skip-lock-tables 禁用,对备份MyISAM的多个库,可能会造成数据不一致
注：以上选项对InnoDB表一样生效，实现温备，但不推荐 使用

26、备份和恢复

InnoDB备份选项：
支持热备，可用但不建议用温备
--single-transaction 此选项Innodb中推荐使用，不适用MyISAM，此选项会 开始备份
前，先执行START TRANSACTION指令，并且在 备份期间，不允许对数据进行修改操作
此选项和--lock-tables（此选项隐含提交挂起的事务） 选项是相互排斥
备份大型表时，建议将--single-transaction选项和-quick结合一起使用

27、生产备份策略

InnoDB建议备份策略
mysqldump –uroot –A –F –E –R –single-transaction -master-data=1 --flush-privileges --
triggers --hexblob >$BACKUPDIR/fullback$BACKUP_TIME.sql
MyISAM建议备份策略
mysqldump –uroot –A –F –E –R –x -–master-data=1 -flush-privileges --triggers --hex-blob

$BACKUPDIR/fullback$BACKUP_TIME.sql
实验：恢复误删除的数据库到最新状态
（1）完全备份
mysqldump -A -F --master-data=2 --single-transaction > /app/all-date +%F%T.sql
（2）对数据库修改
insert into students(name,age,gender) values(‘a‘,‘29‘,‘F‘);
drop database hellodb;
（3）发现问题
mysql>flush tables with read lock; 加锁
iptables 禁止其它用户访问
（4）查看完全备份的位置
less /app/all-2018-02-2309:48:53.sql
CHANGE MASTER TO MASTER_LOG_FILE=‘mariadb-bin.000008‘,
MASTER_LOG_POS=245;
（5）flush logs 生成新日志文件
（6）备份日志文件
cp /var/lib/mysql/mariadb-bin.000008 /app/
mysqlbinlog --start-position=245 mariadb-bin.000008 > /app/bin.sql
mysqlbinlog mariadb-bin.000009 >> /app/bin.sql 还有日志就追加
（7）删除日志中的误操作命令
vim /app/bin.sql
删除drop database hellodb; 此命令
（8）还原前关闭二进制日志记录
mysql>set sql_log_bin=0;
（9）解锁
mysql>unlock tables;
（10）还原完全备份
mysql> source /app/all-2018-02-2309:48:53.sql
（11）还原二进制日志的备份
mysql> source /app/bin.sql
（12）重新开启二进制日志
mysql>set sql_log_bin=1;
（13）重新允许用户访问
iptables 恢复用户访问