数据损坏；
1：物理损坏
2：逻辑损坏
drop delete tuncate update
设计备份容灾策略：
备份工具选择 备份周期计划 备份监控方法
容灾：
高可用，延时从库，灾备库。 定期备份容灾检查。 周期性检查备份数据情况。 定期的故障演练。 随机用测试库恢复，业务验证 数据损坏时的快速准确恢复。 每个企业无故障要求不同。 数据迁移的工作 备份或者主从手段完成迁移。
备份类型
热备 在数据库正常业务时,备份数据,并且能够一致性恢复（只能是innodb） 对业务影响非常小
#温备 #锁表备份,只能查询不能修改（myisam） #影响到写入操作
冷备 关闭数据库业务,数据库没有任何变更的情况下,进行备份数据. 业务停止
备份方式及工具介绍
逻辑备份工具 基于SQL语句进行备份 mysqldump * mysqlbinlog *
物理备份工具 基于磁盘数据文件备份 xtrabackup(XBK) ：percona 第三方 * MySQL Enterprise Backup（MEB）
逻辑备份和物理备份的比较
mysqldump (MDP)包括主从架构(replication)，mydumper load data in file 优点： 1.不需要下载安装 2.备份出来的是SQL，文本格式，可读性高,便于备份处理 3.压缩比较高，节省备份的磁盘空间
缺点： 4.依赖于数据库引擎，需要从磁盘把数据读出 然后转换成SQL进行转储，比较耗费数据库资源，数据量大的话效率较低 建议： 100G以内的数据量级，可以使用mysqldump 超过TB以上，我们也可能选择的是mysqldump，配合分布式的系统 1EB =1024 PB =1000000 TB
xtrabackup(XBK)
优点： 1.类似于直接cp数据文件，不需要管逻辑结构，相对来说性能较高 缺点： 2.可读性差 3.压缩比低，需要更多磁盘空间 建议：
100G<TB
备份策略
备份方式： 全备:全库备份，备份所有数据 增量:备份变化的数据
逻辑备份=mysqldump+mysqlbinlog 物理备份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog
备份周期: 根据数据量设计备份周期 比如：周日全备，周1-周6增量
==========================================================================================================================================
mysqldump (逻辑备份的客户端工具)
介绍： 逻辑备份工具，备份的是sql语句。 innodb可以采取快照方式。开启独立事务获取当前最新一致性快照。 将快照中的数据放到临时表，转换成sql语句保存到sql文件里。 对于非innodb表需要锁表备份。触发FTWRL系统表部分不是innodb（全局锁表） 8.0大多数表再innodb，所以性能会增长。
客户端通用参数
-u -p -S -h -P 与mysql命令参数是一样的。
本地备份:
mysqldump -uroot -p >存放备份数据的文件
远程备份:
mysqldump -uroot -p -h ip -P3306 （是把目标主机上的数据 备份到本机)
备份参数：
-A 全部备份 mysqldump -uroot -p -A >/data/backup/full.sql -B db1 db2 db3 备份一个或者多个单库,多库空格多个库名 mysqldump -uroot -p -B world >/data/backup/world.sql
备份单个或多个表
world数据库下的city,country表
mysqldump -uroot -p world city country >/data/backup/bak1.sql 🟩🟩🟩以上备份恢复时:必须库事先存在,并且ues才能source恢复 验证以下俩语句区别： mysqldump -uroot -p -B world >/data/backup/world.sql 多了create database 和use database 语句
mysqldump -uroot -p world >/data/backup/bak1.sql 针对表级别的，没有创建库和使用库语句。 使用，如果库不在则需要手工创建，然后再use该库
高级参数
（一）--master data =2 以注释的形式,保存备份开始时间点的binlog的状态信息
案例： 假设每周日23；00全备份，1-6 binlog备份，周二有人删库 全备可以恢复，其余的binlog恢复 起点：（不好确认痛点） 方法一，备份开始时，切割日志，-F 方法二，备份开始时，自动记录日志文件信息 终点：drop前位置信息 mysqlbinlog --include-gtids='015b0095-77d7-11eb-9790-000c299e328e:503-509' mysql-bin.000018 mysql-bin.000019 mysql-bin.000020 mysql-bin.000021 > /data/binbak.sql 功能： （1）在备份时，会自动记录，二进制日志文件名和位置号 0 默认值，表示不开启 1 以change master to命令形式，可以用作主从复制 2 以注释的形式记录，备份时刻的binlog文件名+postion号 （2） 自动锁表和解锁 （3）如果配合--single-transaction，只对非InnoDB表进行锁表备份， InnoDB表进行“热“”备，实际上是实现快照备份。
mysqldump -uroot -p -A --master-data=2 >/data/backup/world.sql
（二）-F 按照库的个数进行binlog日志切割。
（三）-R 备份存储过程及函数（脚本）
（四）--triggers 备份触发器（脚本）
（五）-E 备份事件（类似计划任务）
使用方法，命令行增加就可以: 例子： mysqldump -uroot -p -A -R -E --triggers --master-data=2 --single-transaction >/data/backup/world.sql
--single-transaction innodb 存储引擎开启热备(快照备份)功能
#--set-gtid-purged=auto SET @@SESSION.SQL_LOG_BIN= 0; --set-gtid-purged=off/auto/on --max_allowed_packet=64m 备份超出最大传输包大小，使用该参数。备份时加 标准例子： mysqldump -uroot -p -A -R -E --triggers --master-data=2 --single-transaction --max_allowed_packet=64M --set-gtid-purged=off >/data/backup/world SET @@SESSION.SQL_LOG_BIN= 0;
恢复：
基于mysqldump+binlog恢复：
案例：
基础环境，mysql5.7版本，LNMT环境。数据量100G,meit 5-20m增长
备份策略：mysqldump每天全备，binlog定时备份。（在[mysqld]中加入log-bin=mysql-bin）
故障模拟，某天上午10点数据故障，核心数据被删除。
恢复思路：
1.挂维护页
2.找测试库进行数据恢复。
3.恢复前一天的全备数据。
4.截取前一天全备到该天上午10点的binlog，并恢复
5.测试业务功能是否正常。
方案一，故障数据岛回生成
方案二，测试库当生产，先临时应付业务
模拟数据恢复：
1.模拟原始数据。
2.全备
mysqldump -uroot -p -A -R -E --triggers --master-data=2 --single-transaction --max_allow_packet=64M >/data/backup/fulldate +%F.sql
3.模拟当天数据变化。
假设创建几张表插入数据
4.模拟删库。
drop database 模拟库。
5.开始恢复
检查备份，寻找binlog的master_log_pos的值
查看备份文件 /data/backup/full_xxx.sql
show events
找到起止点
10cfbdd2-04a7-11ec-a988-000c29b00156:19-23
恢复全备
set sql_log_bin=0 (禁止将自己的语句记入二进制日志文件binlog中,记得完全恢复操作完成后，别忘记了执行set sql_log_bin=1;)
source /data/backup/full_date + %F.sql
截取binlog
起点：在全备文件里找到master_log_pos cat full_2020-09-01.sql | grep -m 1 'MASTER_LOG_POS'
终点：
show master status;
show binlog events in 'mysql-bin.xxx';
找到drop之前的pos点
mysqlbinlog --skip-gtids --start-position=起点 --stop-position=终点 master-bin.xxx | mysql -uroot -p
set sql_log_bin=1;
扩展：
从mysqldump 全备中获取部分库和表的备份 1、获得表结构
sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE city/!d;q' full.sql>createtable.sql
2、获得INSERT INTO 语句，用于数据的恢复
grep -i 'INSERT INTO city' full.sqll >data.sql &
3.获取单库的备份
sed -n '/^-- Current Database: world/,/^-- Current Database: `/p' all.sql >world.sql
常用binlog日志操作命令 binlog日志格式可以通过mysql的my.cnf文件的属性binlog_format指定。如以下： binlog_format = MIXED //binlog日志格式 log_bin =目录/mysql-bin.log //binlog日志名 expire_logs_days = 7 //binlog过期清理时间 max_binlog_size 100m //binlog每个日志文件大小
binlog-do-db=需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可 binlog-ignore-db=不需要备份的数据库苦命，如果备份多个数据库，重复设置这个选项即可
1.查看所有binlog日志列表 mysql> show master logs;
2.查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值 mysql> show master status;
3.刷新log日志，自此刻开始产生一个新编号的binlog日志文件 mysql> flush logs; 注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；
4.重置(清空)所有binlog日志 mysql> reset master; binlog是二进制文件，普通文件查看器cat，vim等都无法打开， 必须使用自带的mysqlbinlog命令查看 指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos点的起始偏移，查询条数；
1.查询第一个(最早)的binlog日志： mysql> show binlog events;
2.指定查询 mysql-bin.000021 这个文件： mysql> show binlog events in 'mysql-bin.000021';
3.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起： mysql> show binlog events in 'mysql-bin.000021' from 8224;
4.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，查询10条 mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10;
5.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查询10条 mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10\G;
用mysqlbinlog将查询到的数据导入到mysql中 mysqlbinlog --start-position=245 --stop-position=582 master-bin.000009 | mysql -uroot -p
==========================================================================================================================================
xbk备份：
xtrabackup yum install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev -y 2.4版本之后用于8.0数据库 wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/\ binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm yum install percona-xtrabackup-*.rpm
介绍： 底层属于物理备份工具，拷贝数据文件，原生态支持全备和增量备份。 innodb表： 支持热备：业务正常发生的时候可以无阻塞备份，影响较小。 1，check point，将已提交的数据页刷新到磁盘，会记录一个LSN。 2，拷贝innodb表相关文件（ibdata1，frm ibd。。。） 3.备份期间，产生新的数据变化的redo，也会备份走。
非innodb表： 支持温备份： 锁表备份。 1.ftwrl，触发给全局锁。 2.拷贝非innodb表的数据。 3.解锁。 再次统计LSN号。写入专用文件。 二进制日志的位置记录下来 所有备份文件统一存放在一个目录下。
xbk的应用： 前提： 1，数据库是启动状态。 2，能连上数据库。 vim /etc/my.cnf [client] socket=sock路径 3，默认会读取[mysqld] ---》datadir 4，服务器端工具，只能本地连接 innobackupex --user=root --password=123 /data/xbk/ (全备命令) 备份结果查看： 除了数据目录 主要关注以下： 会有记录pos点记录和gtid的记录 xtrabackup_binlog_info checkpoints记录自己的LSN号 xtrabackup_checkpoints
一个全局记录信息
还有个二进制的redo文件。
自定义备份目录时间。
innobackupex --user=root --password=123 --no-timestamp /data/xbk/full_date +%F
全备恢复： （场景：关闭数据库，删除数据库数据目录） 先做备份预处理： prepare预处理 预处理原理：redo前滚，undo回滚。模仿csr过程。 innobackupex --apply-log /data/xbk/备份目录/ 数据恢复并启动数据库 cp -a /data/xbk/备份目录/* /data/数据库数据目录/ 更改拷贝后的数据为mysql 启动数据库。
xbk多出来的文件： -rw-r----- 1 root root 24 Jun 29 09:59 xtrabackup_binlog_info -rw-r----- 1 root root 119 Jun 29 09:59 xtrabackup_checkpoints -rw-r----- 1 root root 489 Jun 29 09:59 xtrabackup_info -rw-r----- 1 root root 2560 Jun 29 09:59 xtrabackup_logfile
xtrabackup_binlog_info ：（备份时刻的binlog位置） [root@db01 full]# cat xtrabackup_binlog_info mysql-bin.000003 536749 79de40d3-5ff3-11e9-804a-000c2928f5dd:1-7 记录的是备份时刻，binlog的文件名字和当时的结束的position，可以用来作为截取binlog时的起点。
xtrabackup_checkpoints ： backup_type = full-backuped from_lsn = 0 上次所到达的LSN号(对于全备就是从0开始,对于增量有别的显示方法) to_lsn = 160683027 备份开始时间(ckpt)点数据页的LSN last_lsn = 160683036 备份结束后，redo日志最终的LSN compact = 0 recover_binlog_info = 0 （1）备份时刻，立即将已经commit过的，内存中的数据页刷新到磁盘(CKPT).开始备份数据，数据文件的LSN会停留在to_lsn位置。 （2）备份时刻有可能会有其他的数据写入，已备走的数据文件就不会再发生变化了。 （3）在备份过程中，备份软件会一直监控着redo的undo，如果一旦有变化会将日志也一并备走，并记录LSN到last_lsn。 从to_lsn ----》last_lsn 就是，备份过程中产生的数据变化.
xtrabackup增量备份： 增量备份逻辑： 前提：增量依赖于全备（假设第一天全部备份） 后面的增量针对前一次的全备数据量进行备份。 主要参照前次全量备份数据的LSN号码 再次基础上变化的数据页备份走，会将备份过程中产生新的redo备份走。 增量只是少量数据。 恢复时： 需要将所有的增量（inc）备份按顺序合并到全备中，然后恢复。 每个备份都需要做prepare（预处理） 具体操作： 1，建库建表操作，插入数据 2，模拟全备： innobackupex --user=root --password=123 --no-timestamp /data/xbk/full 3，模拟数据变化： 建表插入数据。 4，模拟增量备份（inc,duibi LSN号）： innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/xbk/full /data/backup/inc
--incremental打开备份开关 --incremental-basedir 所依赖的前一次全备的目录。 5，模拟下一次增量备份 增加表。 innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/inc /data/backup/inc1 6，再模拟一次数据增量备份
7，搞破坏，干掉进程和数据。 to_lsn = 934606644 last_lsn = 934606653
to_lsn = 934624692 last_lsn = 934624701
基于xbk full + inc + binlog 恢复： 确认备份是否成功。 检查数据目录或者xbk输出日志或者checkpoints。 上一个last的lsn与上个from差9个数则正常。 恢复： 1，进行合并整理，所有inc备份到全备: 基础全备的整理： innobackupex --apply-log --redo-only /data/backup/full 只应用redo，不做undo，防止lsn号码对不上。 强制跳过回滚。 可以--help查看 除了最后一个inc不用增加redo-only参数，其余需要。 合并并prepare inc 到full innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc /data/backup/full 合并并prepare inc1 到full innobackupex --apply-log --incremental-dir=/data/backup/inc1 /data/backup/full 再做一次整体的prepare innobackupex --apply-log /data/backup/full 修复数据库并重启（可以cp过去，也可以更改my.cnf的数据目录datadir=参数） 截取日志： 起点:最后一次备份的xtrabackup_binlog_info内容 终点：因为是rm，所以直接找最后一个就行。
2，合并完成恢复数据: 3，截取二进制日志: 4，恢复日志: 作业：写mysqldump，xbk备份脚本 研究mysqldumper
