二进制日志的工作模式 (二进制日志的类型)
1.statement 语句模式(mysql5.6的默认模式)，记录数据库中所有操作过的的'SQL语句'(create insert alter drop)
优点：易读，相对于行级模式，占用磁盘空间小
缺点：不安全
2.row 行级模式
优点：安全
缺点：'不易读'，相对于语句模式，占用磁盘大
3.mixed 混合模式
#查看mysql工作模式
5.7.6之前默认为STATEMENT模式。MySQL 5.7.7之后默认为ROW模式。这个参数主要影响主从复制(也就是说mysql5.7.7之后，主从方式会修改)
mysql> show variables like '%binlog_format%';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
---------------------------------------------------------
#查看statement工作模式的binlog
[root@db03 data]# mysqlbinlog mysql-bin.000014
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200723 8:05:42 server id 2 end_log_pos 120 CRC32 0xf44bc0a5 Start: binlog v 4, server v 5.6.46-log created 200723 8:05:42 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
VtQYXw8CAAAAdAAAAHgAAAABAAQANS42LjQ2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABW1BhfEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAaXA
S/Q=
'/*!*/;
# at 120
#200723 8:16:52 server id 2 end_log_pos 208 CRC32 0x65d2cf88 Query thread_id=6 exec_time=0 error_code=0
SET TIMESTAMP=1595463412/*!*/;
SET @@session.pseudo_thread_id=6/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
create database xs
/*!*/;
# at 208
#200723 8:20:15 server id 2 end_log_pos 301 CRC32 0x52edbfa7 Query thread_id=7 exec_time=1 error_code=0
use `xs`/*!*/;
SET TIMESTAMP=1595463615/*!*/;
create table xs(id int) 'create'
/*!*/;
# at 301
#200723 8:20:46 server id 2 end_log_pos 376 CRC32 0x8ff0ec90 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1595463646/*!*/;
BEGIN
/*!*/;
# at 376
#200723 8:20:46 server id 2 end_log_pos 473 CRC32 0xe9d72178 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1595463646/*!*/;
insert xs values(0),(1),(2) 'insert'
/*!*/;
# at 473
#200723 8:20:46 server id 2 end_log_pos 504 CRC32 0x75c0d272 Xid = 64
COMMIT/*!*/;
# at 504 #####drop之前的位置点（end_log_pos 615）-------------
#200723 8:21:15 server id 2 end_log_pos 615 CRC32 0xa77379b1 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1595463675/*!*/;
SET @@session.pseudo_thread_id=7/*!*/;
DROP TABLE `xs` /* generated by server */ 'drop'
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
----------------------------------------------------------------------------
#配置row工作模式(binlog起始大小167)
[root@db03 data]# vim /etc/my.cnf
binlog_format=row
mysql> show variables like '%binlog_format%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
#查看binlog
[root@db02 data]# mysqlbinlog mysql-bin.000002
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200723 20:18:15 server id 1 end_log_pos 120 CRC32 0xfefb1228 Start: binlog v 4, server v 5.6.46-log created 200723 20:18:15 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG ' #该位置为加密后的SQL语句
B4AZXw8BAAAAdAAAAHgAAAABAAQANS42LjQ2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAHgBlfEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAASgS
+/4=
'/*!*/;
# at 120
create alter 仍会记录，show use select drop updata不会记录
#查看row模式的binlog（mysqlbinlog --help）（@1=1所在位置附近为SQL语句）
[root@db03 data]# mysqlbinlog --base64-output=decode-rows -vvv mysql-bin.000016
# at 759
#200723 20:31:27 server id 1 end_log_pos 806 CRC32 0x53bad73a Table_map: `cs`.`css` mapped to number 72
# at 806
#200723 20:31:27 server id 1 end_log_pos 852 CRC32 0x07f740a8 Update_rows: table id 72 flags: STMT_END_F
### UPDATE `cs`.`css` #row模式下的SQL语句，语句多，占用空间大
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=10 nullable=1 is_null=1 */
### SET
### @1=100 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=10 nullable=1 is_null=1 */
# at 852
----------------------------------------------------------------
#二进制不同的工作模式产生的binlog，肯定不能导入另一种工作模式的库，所以mixed一般不会使用
慢日志
概念：
作用：
1.是将mysql服务器中'影响数据库性能'的相关SQL语句'记录'到日志文件
2.通过对这些特殊的'SQL语句分析'，改进以达到'提高数据库性能'的目的(优化)
#配置慢日志
[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
慢日志测试
#建表
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
-----------------------------------------------------------------------
分析慢日志
#输出记录次数最多的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
-------------------------------------------------------------------
有能力的可以做成可视化界面：
Anemometer基于pt-query-digest将MySQL慢查询可视化
https://www.percona.com/downloads/percona-toolkit/LATEST/ 慢日志分析工具下载
https://github.com/box/Anemometer 可视化代码下载
第三方推荐（扩展）：
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客户端
1.mysql
2.mysqldump
3.mysqladmin
#备份的作用
恢复，防止数据丢失
#备份的类型
1.冷备，停库，停服务，再备份
2.温备，不停库，不停服务，锁表（阻止数据写入），再备份
3.热备，不停库，不停服务，再备份
#备份的方式
1.全量备份，全部数据备份
这些备份在用户不能访问数据时进行，因此无法读取或修改数据。这些脱机备份会'阻止'执行任何使用数据的活动。这些类型的备份'不会干扰'正常运行的系统的性能。但是，对于某些应用程序，会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。
2.增量备份，针对于上一次备份，将新数据备份
这些备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。
3.差异备份，基于上一次'全备'进行新数据的备份
这些动态备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。
#备份的方式
1.逻辑备份
基于SQL语句的备份
1.binlog
2.into outfile(需要配置文件中配置：secure-file-priv)
[root@db03 data]# vim /etc/my.cnf
[mysqld]
secure-file-priv=/tmp
mysql> select * from world.city into outfile '/tmp/world_city.data';
3.主从复制，为了读写分离 MHA打下基础
4.mysqldump（###）
5.replication
2.物理备份
1.备份整个data目录，停库，打包，拷贝，解压即用，查看（占用磁盘空间大，需要取出drop前的那段binlog）
2.xtrabackup可以进行增量备份，但是不易恢复
#旧库初始化数据库
/etc/init.d/mysqld stop && rm -rf ../data/* && ./mysql_install_db --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data/
四、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语句,在文件的22行，记录binlog的位置点
1）等于2：记录binlog信息，并注释（使用最多）
2）等于1：记录binlog信息，不注释（扩展多个从库的时候使用，不需要再指定位置点 master_log_file master_log_pos）
0）等于0：不记录binlog信息
[root@db01 backup]# mysqldump -uroot -p123 --master-data=2 >/backup/full.sql
7.--single-transaction：快照备份（该参数与 --master-data=2 一起，组成'热备'）
8.-d：仅表结构（x）
9.-t：仅数据(x)
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
[root@db03 ~]# mysql -uroot -p123 < zcat /tmp/full.sql.gz
#完整的备份命令：
mysqldump -uroot -p -A -R --triggers --master-data=2 --single-transaction > /tmp/full.sql
#使用mysqldump命令备份的库保存在文件中，该文件中含有（create--drop）语句
#位置点
[root@db02 tmp]# head -22 full.sql |tail -1
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=1464;
#删除drop语句
[root@db02 tmp]# vim full.sql
DROP TABLE IF EXISTS `cs`; ###################
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `cs` (
`id` int(11) DEFAULT NULL,
`status` enum('1','0') DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
2.注意：
1）mysqldump在备份和恢复时都需要MySQL实例'启动'为前提
2）一般数据量级'100G以内'，大约15-30分钟可以恢复
3）mysqldump是以'覆盖'的形式恢复数据的(因为导出的时候添加了drop语句)
五、企业案例
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）模拟生产数据
create database dump;
use dump;
create table dump(id int);
insert dump values(1),(2),(3),(4);
select * from dump;
2）模拟23:00全备(定时任务)
[root@db03 mysql]# mysqldump -uroot -p -A -R --triggers --master-data=2 --single-transaction > /tmp/full.sql
3）模拟23：00到10:00的数据操作（全备后，数据损坏之前）
use dump;
insert dump values(1000),(2000),(3000),(4000);
select * from dump;
4）模拟删库
drop database dump; #删除的是库，binlog里面只有建表语句
show databases;
4.恢复数据
1）停库，避免二次伤害
[root@db03 mysql]# /etc/init.d/mysqld stop && netstat -lntup
2）创建新的数据库
3）导入前一天的全备
#老库将数据传输到新库
[root@db03 ~]# scp /tmp/full.sql 172.16.1.52:/tmp/
#新库导入全备数据
[root@db02 ~]# mysql -uroot -p < /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.000005', MASTER_LOG_POS=682815;
2.找到结束位置点
[root@db03 data]# mysqlbinlog mysql-bin.000006 > 1.txt && grep -A 4 'drop database dump' 1.txt
COMMIT/*!*/;
# at 682325 #########
#200724 20:16:00 server id 1 end_log_pos 682417(不是这个)
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 -uroot -p < /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> create database dump;
mysql> source /tmp/dump.sql; #数据量大的时候建议使用
#mysqldump指定库导出，那么mysql -uroot -p dump < xx就指定库导入