2020-03-02备份恢复

1. 运维在数据库备份恢复方面的职责

1.1 设计备份策略

备份周期: 根据数据量

备份工具:mysqldump xtrabackup  MEB(MYSQL Enterprise BACKUP MEB)

备份方式:

全备 :  mdp

增量:binlog (flush logs,cp)

物理备份:XBK

全备:XBK

时间:

自动:


1.2  日常备份检查

确认有没有备份?  crontabl -l ---------->1备份脚本  2shell脚本 3备份的路径 4备份数据(大小)5看备份日志 6检查备份文件

1.3 定期恢复演练(测试库)

一季度 或者 半年

1.4 故障恢复

通过现有备份,能够将数据库恢复到故障之前的时间点.   

1.5 迁移

1. 停机时间

2. 回退方案

2. 备份类型

2.1 热备

在数据库正常业务时,备份数据,并且能够一致性恢复(只能是innodb)

对业务影响非常小

2.2 温备

锁表备份,只能查询不能修改(myisam)

影响到写入操作

冷备

关闭数据库业务,数据库没有任何变更的情况下,进行备份数据.

业务停止

4. 逻辑备份和物理备份的比较

4.1 mysqldump (MDP)






备份工具使用-mysqldump

-u -p -S -h -P

本地备份:

mysqldump -uroot -p  -S /tmp/mysql.sock

远程备份:

mysqldump -uroot -p  -h 10.0.0.51 -P3306

备份专用基本参数

-A 全备参数

[root@db01~]# mkdir-p/data/backup

mysqldump-uroot-p-A>/data/backup/full.sql

Enterpassword:

mysqldump:[Warning]Usinga password on the command line interfacecanbe insecure.Warning:A partialdumpfrom a server that hasGTIDswill bydefaultinclude theGTIDsof all transactions,even those that changed suppressed parts of the database.Ifyou don't want to restoreGTIDs,pass--set-gtid-purged=OFF.Tomake a completedump,pass--all-databases--triggers--routines--events.

# 补充:

#1.常规备份是要加--set-gtid-purged=OFF,解决备份时的警告

#[root@db01~]# mysqldump-uroot-p123-A--set-gtid-purged=OFF>/backup/full.sql

#2.构建主从时,做的备份,不需要加这个参数#[root@db01~]# mysqldump-uroot-p123-A--set-gtid-purged=ON>/backup/full.sql

-B db1 db2 db3 备份多个单库

#[root@db01~]# mysqldump-uroot-p123-B city gtid >/backup/db.sql

备份单个或多个表

[root@localhost backup]# mysqldump -uroot -p ten nine >/backup/table.sql

Enter password:

Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.

mysqldump: Got error: 1049: Unknown database 'ten' when selecting the database

[root@localhost backup]# ll

总用量 181776

-rw-r--r--. 1 root root 186133944 3月  2 22:08 full.sql

-rw-r--r--. 1 root root      993 3月  2 22:16 table.sql

 高级参数应用

-R 备份存储过程及函数

--triggers 备份触发器

-E 备份事件

--master-data=2

--single-transaction

-F 在备份开始时,刷新一个新binlog日志

mysqldump-uroot-p-A-R--triggers-F>/bak/full.sql

-master-data=2 *****

(1)记录备份时刻的binlog信息

(2) 自动锁表

        不加--single-transaction,温备份

        加了--single-transaction,对于innodb表不锁表备份(快照备份)

--single-transaction *****

对于innodb的表进行一致性快照备份,不锁表

每天全备 mysqldump 60G

周三,下午2点,数据库损坏

恢复思路?

1  找一个临时库 恢复到周二

2  截取全备之前的binlog,恢复到误删除之前的状态

方法一 : 直接用临时库 顶替

方法二 :将误删除的导入生产库

起点 : -master-data=2

终点 : 误删之前

故障演练

mysqldump -uroot -p123 -A -R --triggers --set-gtid-purged=OFF --master-data=2 --single-transaction|gzip >/backup/full_$(date +%F).sql.gz

gunzip full_2020-03-03.sql.gz

起点:
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=793;

858

mysqlbinlog --skip-gtids --start-position=793 --stop-position=858 /data/binlog/mysql-bin.000005 >backup/bin.sql

set sql_log_bin=0;

source /backup/full_2020-03-03.sql

source /backup/bin.sql

set sql_log_bin=1;

你可能感兴趣的:(2020-03-02备份恢复)