mysql 备份binlog_mysql 备份之逻辑备份mysqldump, mysqlbinlog, 全备及参数说明

本文介绍了MySQL的热备、温备、冷备三种备份类型,重点讲解了逻辑备份工具mysqldump和mysqlbinlog的使用,包括全备、增量备份策略。详细阐述了mysqldump的参数如--set-gtid-purged、--single-transaction等,并提供了备份恢复的实践步骤和注意事项。
摘要由CSDN通过智能技术生成

2. 备份类型

2.1 热备

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

对业务影响非常小

热备会备份备份开始前及备份过程中产生的新数据。

2.2 温备

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

影响到写入操作

2.3 冷备

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

业务停止

3. 备份方式及工具介绍

3.1 逻辑备份工具

基于SQL语句进行备份

mysqldump*****mysqlbinlog*****

3.2 物理备份工具

基于磁盘数据文件备份

xtrabackup(XBK) :percona 第三方*****MySQL Enterprise Backup(MEB)

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

4.1 mysqldump (MDP)

优点:1.不需要下载安装2.备份出来的是SQL,文本格式,可读性高,便于备份处理3.压缩比较高,节省备份的磁盘空间

缺点:4.依赖于数据库引擎,需要从磁盘把数据读出

然后转换成SQL进行转储,比较耗费资源,数据量大的话效率较低

建议:

100G以内的数据量级,可以使用mysqldump

超过TB以上,我们也可能选择的是mysqldump,配合分布式的系统

1EB=1024 PB =1000000 TB

4.2 xtrabackup(XBK)

优点:1.类似于直接cp数据文件,不需要管逻辑结构,相对来说性能较高

缺点:2.可读性差3.压缩比低,需要更多磁盘空间

建议:>100G

5.备份策略

备份方式:

全备:全库备份,备份所有数据

增量:备份变化的数据

逻辑备份=mysqldump+mysqlbinlog

物理备份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog

备份周期:

根据数据量设计备份周期

比如:周日全备,周1-周6增量

6.备份工具使用-mysqldump

6.1 mysqldump (逻辑备份的客户端工具)

6.1.1 客户端通用参数

-u -p -S -h -P

本地备份:

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

远程备份:

mysqldump-uroot -p -h 10.0.0.51 -P3306

6.1.2 备份专用基本参数

-A 全备参数

例子1:

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

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

Enter password:

mysqldump: [Warning] Using a password on the command lineinterfacecan be insecure.

Warning: Apartial 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.

# 补充:

#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

# -A表示全备

-B db1 db2 db3 备份多个单库

说明:生产中需要备份,生产相关的库和MySQL库

例子2 :

mysqldump-B db1 db2 --set-gtid-purged=OFF >/data/backup/b.sql

备份单个或多个表

例子3 world数据库下的city,country表

mysqldump-uroot -p world city country >/backup/bak1.sql

以上备份恢复时:必须库事先存在,并且ues才能source恢复

6.1.3 高级参数应用

特殊参数1使用(必须要加)

-R 备份存储过程及函数--triggers 备份触发器-E 备份事件

例子4:

[root@db01 backup]# mysqldump-uroot -p -A -R -E --triggers >/data/backup/full.sql

(5) 特殊参数2使用

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

例子5:

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

-master-data=2

以注释的形式,保存备份开始时间点的binlog的状态信息(记录position开始号和gtid的所有号)

不论是何种引擎, 都会锁表,除非配合--single-transaction参数使用。

mysqldump-uroot -p -A -R --triggers --master-data=2 >/back/world.sql

[root@db01~]# grep 'CHANGE' /backup/world.sql-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=194;

功能:

(1)在备份时,会自动记录,二进制日志文件名和位置号0默认值1以change master to命令形式,可以用作主从复制2 以注释的形式记录,备份时刻的文件名+postion号

(2)自动锁表

不使用--single-transaction时,实现的是温备,何种引擎都会锁表  配合--single-transaction,只对非InnoDB表进行锁表备份,InnoDB表进行“热“”备(实际上是实现快照备份),非真正热备,只备份备份开始时刻数据, 备份过程中产生的新数据不会备份

使用该参数后记录有备份开始时刻的position,配合mysqlbinlog恢复数据时,我们需要找出备份开始到数据库异常时刻的所有binlog信息,然后配合全备即可恢复所有

此时我们即可从全备文件中找到记录的position号,从该号开始到异常时刻的所有binlog就都可以提出来了,--start-position=这里记录的position号

截取二进制文件参考:https://www.cnblogs.com/quzq/p/12866410.html

--single-transaction

innodb 存储引擎开启热备(快照备份)功能

master-data可以自动加锁

(1)在不加--single-transaction ,启动所有表的温备份,所有表都锁定

(1)加上--single-transaction ,对innodb进行快照备份,对非innodb表可以实现自动锁表功能

例子6: 备份必加参数

mysqldump-uroot -p -A -R -E --triggers --master-data=2 --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

-A  全备

-R  备份过程和函数

-E  备份事件

--triggers  备份触发器

--master-data=2记录备份开始时间节点

--single-transaction配合master-data参数区分存储引擎做快照备份或温备

--set-gtid-purged=auto

该参数取值默认是auto;

如果开启了gtid功能,auto时,备份出的备份文件中会记录gtid信息。off时,备份出的文件不带gtid信息

使用带有gtid的备份恢复后数据库也会有gtid号,不带是不会有gtid记录。

取值使用场景:1. --set-gtid-purged=OFF,可以使用在日常备份参数中.

mysqldump-uroot -p -A -R -E --triggers --master-data=2 --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql2. auto或on:在构建主从复制环境时需要的参数配置

mysqldump-uroot -p -A -R -E --triggers --master-data=2 --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

--max-allowed-packet=#

用于控制备份时传输数据包的大小

mysqldump -uroot -p -A -R -E --triggers --master-data=2 --single-transaction --set-gtid-purged=OFF --max-allowed-packet=256M >/data/backup/full.sql--max-allowed-packet=#

The maximum packet length to send to or receivefrom server.

6.2 小练习:

6.2.1. 实现所有表的单独备份

提示:

information_schema.tables

mysqldump-uroot -p123 world city >/backup/world_city.sqlselect concat("mysqldump -uroot -p123",table_schema," ",table_name,"--master-data=2 --single-transaction --set-gtid-purged=0 -R -E --triggers>/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema');

6.2.2.模拟故障案例并恢复

(1)每天全备

(2)binlog日志是完整

(3)模拟白天的数据变化

(4)模拟下午两点误删除数据库

需求: 利用全备+binlog回复数据库误删除之前。

故障模拟及恢复:1. 模拟周一23:00的全备

mysqldump-uroot -p -A -R -E --triggers --master-data=2 --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql2. 模拟白天的数据变化

Master [(none)]>create database day1 charset utf8;

Master [(none)]>use day1

Master [day1]>create table t1(id int);

Master [day1]>insert into t1 values(1),(2),(3);

Master [day1]>commit;

Master [world]>update city set countrycode='CHN';

Master [world]>commit;

模拟磁盘损坏:

[root@db01 data]# \rm-rf /data/mysql/data/*3. 恢复故障

[root@db01 data]# pkill mysqld

[root@db01 data]# \rm -rf /data/mysql/data/*

4. 恢复思路

1.检查备份可用性

2.从备份中获取二进制日志位置

3.根据日志位置截取需要的二进制日志

4.初始化数据库,并启动

5.恢复全备

6.恢复二进制日志

6.3. 压缩备份并添加时间戳

例子:

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

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

mysqldump备份的恢复方式(在生产中恢复要谨慎,恢复会删除重复的表)set sql_log_bin=0;

source/backup/full_2018-06-28.sql

注意:1、mysqldump在备份和恢复时都需要mysql实例启动为前提。2、一般数据量级100G以内,大约15-45分钟可以恢复,数据量级很大很大的时候(PB、EB)3、mysqldump是覆盖形式恢复的方法。

一般我们认为,在同数据量级,物理备份要比逻辑备份速度快.

逻辑备份的优势:1、可读性强2、压缩比很高

7、故障恢复思路

1、停业务,避免数据的二次伤害2、找一个临时库,恢复周三23:00全备3、截取周二23:00 ---周三10点误删除之间的binlog,恢复到临时库4、测试可用性和完整性5、5.1方法一:直接使用临时库顶替原生产库,前端应用割接到新库5.2方法二:将误删除的表导出,导入到原生产库6、开启业务

处理结果:经过20分钟的处理,最终业务恢复正常

参考原文:

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值