07 : mysql备份恢复（1） - mysqldump命令使用

注意： mysql不同引擎备份方法不同。我们先来回忆一下和备份有关的知识点。

1、存储引擎
(1)InnoDB（默认使用引擎，也是企业常用的）
热备
独立表空间（每个表一个表空间）
redo：重做日志，用来前滚
undo：回滚日志，用来回滚（未提交的事务）
行级别锁，基于索引来实现的，GAP锁
支持事务。
(2)MyISAM
温备
三个文件构成
表级锁

2、二进制日志
（1）记录的是什么？
DDL、DCL这些种类语句，记录的就是操作语句
DML：他记录的已提交的事务日志，并支持多种格式记录（row、statement、mixed）
（2）事件
开始位置（at xxx）
结束为止(下一个at)
一个事务，有多个事件做成（begin到commit）
（3）截取二进制日志
1、分析二进制日志
找到要截取日志的开始位置（start-position）和结束位置（stop-position）
mysqlbinlog --base64-output=decode=rows -vvv
2、截取日志
mysqlbinlog -d test  --start-position=xxx --stop-position=xxx
-----------------------------------------------------------------------
MySLQL备份

1、备份是为了什么？
就是为了恢复数据库损坏
2、数据库损坏
物理损坏
高可用架构可以很好解决
逻辑损坏
只能用备份就解决

3、备份类型

冷备份
在数据库未工作时进行备份。数据一致性高，可靠性高。影响所有读写。
温备份
数据库不停止工作，只是在备份时对表进行加锁，不影响读，但是影响写操作。
热备份
数据库不停止工作，基于事务的特点进行数据库在线备份，读写影响小。
受限于存储引擎类型（innoDB）。
4、备份方式
逻辑备份（文本表示：SQL 语句）
物理备份（数据文件的二进制副本）

基于复制的备份
增量备份（刷新二进制日志)

5、备份工具
逻辑备份：
1、mysqldump
– mysql原生自带很好用的逻辑备份工具
- 备份特点：备份的SQL
- 优势：可读性高、压缩比高
- 劣势：备份和恢复需要花费更多时间
-比较依赖于CPU和IO性能
2、mysqlbinlog
– 实现binlog备份的原生态命令
物理备份：
3、xtrabackup （第三方，需要单独安装配置）
– precona公司开发的性能很高的物理备份工具
- 备份特点：备份的是真正的数据文件
- 优势：备份恢复快
- 劣势：可读性差、压缩比低
- 主要是消耗IO

如何选择备份工具：
1: 100G以内，mysqldump大体上能够控制在60分钟左右，还是可以接受的
2: 100G以上，到TB级别，xtrabackup比较合适，备份恢复速度都比较快
大数据两级别，TB以上，该怎么选型？？？？？？

6、备份工具使用：

(1) mysqldump 命令备份：
数据量计算：
select sum(data_length+index_length)/1024/1024/1024 from information_schema.tables;

常用参数：
0> -u -p -h -P -S 和客户端有关的参数

1> -A 全库备份
mysqldump -uroot -p123 -A >/backup/full.sql

2> -B 备份1个或者多个单库
mysqldump -uroot -p123 -B world mysql>/backup/data.sql
mysqldump -uroot -p123 -B world >/backup/world.sql

3>单库或单表备份
备份单库(思考这里不加-B的区别)
mysqldump -uroot -p123 world >/backup/world1.sql
备份world 库下的city表 <注意不能加-B，-B后面只能全是数据库>
mysqldump -uroot -p123 world city >/backup/city.sql

** 思考并验证以下命令的区别：
mysqldump -uroot -p123 -B world >/backup/world.sql
与
mysqldump -uroot -p123 world >/backup/world1.sql

vimdiff wordpres.sql world1.sql

结论：
1、-B 在备份时，会添加create database和use语句
2、-B的备份恢复时，直接source
3、不加-B备份恢复时，需要事先创建好数据库，use进去进行source

4> -d 只备份表结构
mysqldump -uroot -p123 -A -d >/backup/aa.sql

5> 生产中必加的选项(1)
-R 备份存储过程和函数数据
--triggers 备份触发器数据
mysqldump -uroot -p123 -A -R --triggers >/backup/full.sql

<6> -F flush logs
在备份时，刷新一个新的二进制日志文件
（有几个数据库就会刷新出几个binlog文件 - 所以一般我们很少使用，使用下面的那个参数<7>）
mysqldump -uroot -p123 -A -R --triggers -F >/backup/full.sql

<7>生产中必加的选项(2)
--master-data=1 记录增加binlog日志文件名和 对应的位置点可执行的语句
--master-data=2 把记录的语句变成--注释，不会执行(默认使用这个)

功能：
1、在备份开始时刻，记录当时二进制日志的文件号，位置号，将来可以作为二进制日志的截取的起始位置
2、如果添加了此参数，会自动对备份的表加锁，对于加了--single-transaction参数的时候，
如果是innodb表则会实行“热备”

mysqldump -uroot -p123 -A -R --triggers --master-data=2>/backup/full.sql

<8>生产中必加的选项(3)
--single-transaction 主要的功能是，对innodb表实现“热备”（快照）
mysqldump -uroot -p123 -A -R --triggers --master-data=2 --single-transaction >/backup/full.sql

mysqldump 热备的实现原理是什么？
1、热备的前提是，只能对innodb表才能实现的
2、热备的实现原理，基于时间点的的快照
3、我的理解是，数员工人数。。。。。

-----------------------------
<9> mysqldump企业备份实现
mysqldump -uroot -p123 -A -R --triggers --master-data=2 --single-transaction |gzip >/backup/alL_$(date +%F).sql.gz

基于mysqldump备份策略？
0、数据量级在100G以内，时间控制在1小时以内比较合适。
1、每小时备份二进制日志，可以设定为远程备份。
2、备份和数据要存储在不同的设备上。
3、以上的操作都是由crontab。

备份策略1：每天全备，每小时binlog备份
00 23 * * * full.sh
00 * * * * binlog.sh
----------------
备份策略2：每周日备份全备，其它时间备份binlog

00 23 * * 7 full.sh (mysqldump 全备)
00 23 * * 1-6 binlog.sh （思路find 出来binlog文件，打包备份推送到远程）

----------------
从远程备份：
mysqldump -uroot -p123 -h 10.0.0.51 -A -R --triggers --master-data=2 --single-transaction |gzip >/backup/alL_$(date +%F).sql.gz

------------------------
<10> 利用备份恢复故障数据

故障案例基本背景：
1、mysql 5.6.34单节点数据库
2、数据量：30G
3、备份策略：mysqldump+mysqlbinlog
故障描述：
开发人员，周一上午10点，误删除生产库oss_base（计费、营帐、His、Boss）所有数据，线上核心应用Crash。
故障处理思路：
1、将业务进行断开，避免二次伤害
2、搭建一个备用库，恢复周日全备。
3、截取二进制日志，恢复到备用库。
4、测试备用库数据，可用性和完整性
5、恢复应用
方式一：应用直接割接到被用户，开启应用
方式二：将故障数据，倒回到元生产库，开其应用
项目结果：经过30分钟的处理，业务恢复正常。

故障模拟及恢复：
1、周日23:00全备
mysqldump -uroot -p123 -A -R --triggers --master-data=2 --single-transaction |gzip >/backup/alL_$(date +%F).sql.gz

2、模拟周一数据变化
mysql> create database oss_base charset utf8;
mysql> use oss_base
mysql> create table oss_tab(id int , name varchar(20));

mysql> insert into oss_tab values(1,‘a‘);
mysql> insert into oss_tab values(2,‘b‘);
mysql> insert into oss_tab values(3,‘c‘);
mysql> insert into oss_tab values(4,‘d‘);
mysql> commit;

3、模拟故障
mysql> drop database oss_base;

4、恢复
（1）检查全备，找到二进制日志截取的起始位置
-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000009‘, MASTER_LOG_POS=120;
（2）恢复全备
gunzip alL_2019-10-03.sql.gz
set sql_log_bin=0;
source /backup/alL_2019-10-03.sql
到此为止，已经将数据恢复到了昨天23点时间点。
（3）截取二进制日志

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000009 | 975 | | | |
+------------------+----------+--------------+------------------+-------------------+

mysql> show binlog events in ‘mysql-bin.000009‘;

| mysql-bin.000009 | 871 | Query | 6 | 975 | drop database oss_base

mysqlbinlog --start-position=120 --stop-position=871 /data/mysql/mysql-bin.000009 >/backup/binlog.sql

（4）恢复二进制日志
mysql> set sql_log_bin=0;
mysql> source /backup/binlog.sql
mysql> show databases;
mysql> use oss_base;
mysql> select * from oss_tab;

_______________________________________________________
测试1： rm -rf /application/mysql/data/数据库删掉 恢复思路？
注意：二进制日志/data/mysql 别删了，生成中binlog文件是和数据文件分开放的，我们这里是放一起了

(1)误删除数据
rm -rf /application/mysql/data/*
（2）关闭数据库
pkill mysqld / kill -9 id / killall mysqld
(3) 初始化数据
/application/mysql/scripts/mysql_install_db --user=mysql --basedir=/application/mysql --datadir=/application/mysql/data/
（4）恢复
（1）检查全备，找到二进制日志截取的起始位置
-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000009‘, MASTER_LOG_POS=120;
（2）恢复全备
gunzip alL_2010-10-03.sql.gz
set sql_log_bin=0;
source /backup/alL_2019-10-03.sql
到此为止，已经将数据恢复到了昨天23点时间点。
（3）截取二进制日志

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000009 | 975 | | | |
+------------------+----------+--------------+------------------+-------------------+

mysql> show binlog events in ‘mysql-bin.000009‘;

| mysql-bin.000009 | 871 | Query | 6 | 975 | drop database oss_base

mysqlbinlog --start-position=120 --stop-position=871 /data/mysql/mysql-bin.000009 >/backup/binlog.sql

（4）恢复二进制日志
mysql> set sql_log_bin=0;
mysql> source /backup/binlog.sql
mysql> show databases;
mysql> use oss_base;
mysql> select * from oss_tab;

--------------------------------------------------------------------------
思考，如果在drop之后又做了一下其他库的正常修改操作，该怎么恢复？
比如：
create database test;
use test;
create table tab(id int ,name varchar(20));
insert into tab values(1,‘a‘),(2,‘b‘);
commit;

解决思路：
在binlog里面找到drop的那个位置点，一直到binlog的结束点，把这一段也导入到数据库里面就可以了。

______________________________________________

原文地址：https://www.cnblogs.com/jim-xu/p/11619613.html

时间： 2024-10-18 05:20:32

07 : mysql备份恢复（1） - mysqldump命令使用的相关文章

MySQL备份--xtrabackup与mysqldump工具使用

MySQL备份----xtrabackup与mysqldump工具的使用 一.Xtrabackup8.0: 一个用于MySQL数据库物理热备的备份工具,支持MySQL.Percona server和MariaDB,开源免费,是目前较为受欢迎的主流备份工具.xtrabackup只能备份innoDB和xtraDB两种数据引擎的表,而不能备份MyISAM数据表. 备份原理: Percona XtraBackup的工作原理是在启动时记住日志序列号(LSN),然后复制数据文件.同时,Percona Xtr

MySQL数据库恢复(使用mysqlbinlog命令)

MySQL数据库恢复(使用mysqlbinlog命令) 1:开启binlog日志记录 修改mysql配置文件mysql.ini,在[mysqld]节点下添加 复制代码代码如下: # log-bin log-bin = E:/log/logbin.log 路径中不要包含中文和空格.重启mysql服务.通过命令行停止和启动mysql服务 复制代码代码如下: c:\>net stop mysql; c:\>net start mysql; 进入命令行进入mysql并查看二进制日志是否已经启动 Sql

Mysql备份恢复

五.Mysql备份恢复 1.备份方式: ■直接phpmyadmin导出备份.我们用root管理权限进入phpmyadmin,然后把需要备份网站的mysql数据库导出备份,建议用gzip压缩格式 ■ mysqldump命令.我们用登陆SSH,然后用命令备份 ■ LVS快照备份  2.备份策略: ■ 完整备份 ■ 增量备份 ■ 差异备份 3.备份类型: ■ 冷备(cold backup):需要关mysql服务,读写请求均不允许状态下进行: ■ 温备(warm backup): 服务在线,但仅支持读请

Linux运维　第四阶段　（六）MySQL备份&&还原（mysqldump、LV’s snapshot、xtrabackup）

Linux运维 第四阶段 (六)MySQL备份&&还原(mysqldump.LV's snapshot.xtrabackup) 一.相关概念 备份:副本,mysql-database备份不同于RAID(RAID是保证硬件损坏而不会业务终止) 备份内容:数据.配置文件.二进制日志.事务日志 1.备份类型: >热备份.温备份.冷备份 热备份:读写不受影响,复杂度高,InnoDB(xtrabackup,mysqldump),lvm快照功能可实现几乎热备: 温备份:仅可执行读操作,MyISA

Mysql 备份恢复的简单实践

一.备份: 进行mysql的安装目录: 使用./mysqldump -u root -h 127.0.0.1 -P 3306 -p mysql>trymysql.sql 输入密码,备份成功. 二.恢复 进行mysql. 创建数据库 create database trymysql; 进入数据库 use trymysql ; 恢复 source trymysql.sql Mysql 备份恢复的简单实践

MySQL备份恢复基础知识及MySQLdump讲解

数据库备份恢复知识要点: 时间轴备份类型分类: 完全备份:备份整个数据集 增量备份:上一次完全备份,或上一次增量备份以后变化的数据的备份(还原麻烦,节省空间) 差异备份:仅备份最近一次完全备份以来变化的数据(还原简单,空间消耗大) 什么是物理备份.逻辑备份: 物理备份:直接复制数据文件进行备份(有可能占用更多的空间,备份速度快,做热备较难) 逻辑备份:从数据库中导出数据"另存为"而进行的备份(从二进制转化为文本格式,有可能丢失精度,需要专门的协议客户端才能进行,和数据存储引擎无关.备份

mysql备份恢复常用命令

Linux下MySQL的备份与还原  备份 [[email protected] ~]# cd /var/lib/mysql (进入到MySQL库目录,根据自己的MySQL的安装情况调整目录) [[email protected] mysql]# mysqldump -u root -p voice>voice.sql,输入密码即可.还原法一:[[email protected] ~]# mysql -u root -p 回车,输入密码,进入MySQL的控制台"mysql>"

mysql备份恢复详解

前言 为什么需要备份数据? 数据的备份类型 MySQL备份数据的方式 备份需要考虑的问题 设计合适的备份策略 实战演练 使用cp进行备份 使用mysqldump+复制BINARY LOG备份 使用lvm2快照备份数据 使用Xtrabackup备份 总结 前言 我们试着想一想, 在生产环境中什么最重要?如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢?这可能是最恐怖的事情了吧, 我感觉在生产环境中应该没有什么比数据跟更为重要. 那么我们该如何保证数据不丢

(转)解锁MySQL备份恢复的4种正确姿势

本文根据DBAplus社群第104期线上分享整理而成. 原文:http://dbaplus.cn/news-11-1267-1.html 讲师介绍   冯帅 点融网高级DBA 分享大纲: 备份高于一切,今天汇总一下常用的几种备份方法,以及恢复的步骤. 一.mysqldump 在日常工作中,我们会使用mysqldump命令创建SQL格式的转储文件来备份数据库.或者我们把数据导出后做数据迁移,主备搭建等操作.mysqldump是一个逻辑备份工具,复制原始的数据库对象定义和表数据产生一组可执行的SQL