mysql备份与还原

一、数据备份的重要性

1 、备份的主要目的是灾难恢复
2 、在生产环境中,数据的安全性至关重要
3 、任何数据的丢失都可能产生严重的后果
4 、造成数据丢失的原因
      程序错误
     人为操作错误
     运算错误
     磁盘故障
     灾难 ( 如火灾、地震 ) 和盗窃

二、数据库备份类型

2.1 物理备份

数据库备份可以分为物理备份逻辑备份。物理备份是对数据库操作系统的物理文件(如数据文件、日志文件等)的备份。这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据库。
物理备份又可以成为冷备份(脱机备份)、热备份(连接备份)和温备份

① 冷备份 (脱机备份)

冷备份 ( 脱机备份 ) :是在 关闭数据库的时候进行 的( tar
  • 定义:冷备份是指在系统完全停止的情况下进行的备份。这意味着所有应用程序都需要关闭,并且在备份期间不会有新的数据生成。
  • 优点:简单易行,通常比热备或温备更快完成。
  • 缺点:需要停机时间,这可能会对业务造成影响;而且恢复时也需要较长的时间来重启系统。

② 热备份 (联机备份)

热备份 ( 联机备份 ) 数据库处于运行状态,依赖于数据库的日志文件 mysqlhotcopy mysqlbackup
  • 定义:热备份是在系统完全运行状态下进行的备份。这意味着即使在备份过程中,系统仍然可以接受新的数据输入和处理请求。
  • 优点:无需停机,对业务影响最小;备份完成后可以立即投入使用。
  • 缺点:技术实现较为复杂,消耗系统和数据库资源备份过程中需要对每个数据文件申请开始和结束备份的操作,否则可能会备份到一些不一致的数据。

③ 温备份

温备份 : 数据库锁定表格(不可写入但可读)的状态下进行备份操作 mysqldump
  • 定义:温备份介于冷备和热备之间,指数据库在非峰值时间进行的备份,这时数据库可能未关闭但流量较小。
  • 优点:可以减少停机时间,同时能够保证数据的一致性。
  • 缺点:实施起来比冷备复杂,可能需要特殊的技术手段来保证数据一致性。无法提供24x7的全天候备份服务

2.2 逻辑备份⭐⭐⭐

逻辑备份是对数据库逻辑组件的备份 . 表示为逻辑数据库结构
这种类型的备份适用于可以编辑数据值或表结构
从数据库的备份策略角度来看,备份又可分为完全 备份、差异备份和增量备份

① 完全备份 ***

  • 完全备份是指每次对整个数据库及其结构进行全面的备份,保存的是备份完成时刻的数据库状态。
  • 完全备份是差异备份和增量备份的基础,备份和恢复操作非常简单方便。
  • 但是,完全备份会导致大量的数据重复,占用大量的磁盘空间,并且备份所需的时间较长。
  • 这种备份策略虽然简单可靠,但由于其占用大量的存储空间和时间,通常仅在首次备份或数据量不大时使用。
  • 恢复数据时,可以直接使用最近的一次完全备份文件,恢复过程简单快捷。

② 差异备份

  • 差异备份是指备份自上次完全备份以来被修改过的所有文件。
  • 这种备份策略会导致每次差异备份中包含的数据量逐渐增加,因为它是基于上一次完全备份的时间点来进行的。
  • 由于每次差异备份都会记录从上次完全备份之后的所有更改,所以可能会包含一些重复的数据。
  • 恢复数据时,首先需要恢复最新的完全备份,然后只需恢复最后一次差异备份即可。

③ 增量备份 ***

  • 增量备份是指只备份自上次完全备份或上次增量备份以来被修改过的文件
  • 备份的时间点是从上次完全备份或上次增量备份之后的数据变化,因此备份的数据量较小,占用的空间少,备份速度也较快
  • 恢复数据时,需要从上一次的完全备份开始,依次恢复所有后续的增量备份。这意味着恢复过程可能比较耗时,并且如果中间某次增量备份数据损坏或丢失,将导致这部分数据无法恢复。
  • 每次增量备份都是基于上一次完全备份或增量备份之后的数据变化,因此不会出现重复数据的情况,也不会额外占用磁盘空间
  • 尽管增量备份节省了存储空间和备份时间,但如果任何一个增量备份文件损坏或丢失,则可能导致数据无法完全恢复。
备份方式比较
备份方式                           完全备份                    差异备份                  增量备份
完全备份时的状态            表 1 、表 2                     1 、表 2                  1 、表 2
1 次添加内容                   创建表 3                       创建表 3                    创建表 3
备份内容                        表 1 、表 2 、表 3                    3                          3
2 次添加内容                    创建表 4                      创建表 4                    创建表 4
备份内容                    表 1 、表 2 、表 3 、表 4          3 、表 4                       4

工作中备份的方式和机制⭐⭐⭐

逻辑备份的策略(增、全、差异)
如何选择逻辑备份策略(频率)
合理值区间 ⭐⭐⭐
一周一次的全备,全备的时间需要在不提供业务的时间区间进行 PM 10点 AM 5:00之间进行全备
增量:3天/2天/1天一次增量备份
差异:选择特定的场景进行备份
mysql备份数据存放在  备份服务器
如何存放到备份服务器: 磁盘挂载、nfs共享存储
只保留3个月数据,3个月之后除掉3个月之前的数据,具体存储时间还是听领导的安排
小企业一般一个mysql数据库只存放一个库,大企业可能有一个mysql里放很多库
通过shell脚本进行自动化备份,如果是完全备份的话,就是将 /usr/local/mysql/data 里的库进行压缩,

三、常见的备份方法

3.1 物理冷备
备份时数据库处于关闭状态,直接打包数据库文件( tar
备份速度快,恢复时也是最简单的
3.2 专用备份工具 mysqldump mysqlhotcopy
mysqldump 常用的逻辑备份工具
mysqlhotcopy 仅拥有备份 MyISAM ARCHIVE
3.3 启用二进制日志进行增量备份
进行增量备份,需要刷新二进制日志
MySQL 支持增量备份,进行增量备份时必须启用二进制日志。二进制日志文件为用户提供复制,对执行备份点后进行的数据库更改所需的信息进行恢复。如果进行增量备份(包含自上次完全备份或增量备份以来发生的数据修改),需要刷新二进制日志。
3.4 第三方工具备份
免费的 MySQL 热备份软件 Percona XtraBackup mysqlbackup

四、MySQL完全备份

是对整个数据库、数据库结构和文件结构的备份,保存的是备份完成时刻的数据库 ,是差异备份与增量备份的基础
1 、优点:   备份与恢复操作简单方便
2 、缺点:   数据存在大量的重复
                   占用大量的备份空间
                   备份与恢复时间长

五、数据库完全备份分类

5.1 物理冷备份与恢复
关闭 MySQL 数据库
使用 tar 命令直接打包数据库文件夹
直接替换现有 MySQL 目录即可
5.2 mysqldump 备份与恢复
MySQL 自带的备份工具,可方便实现对 MySQL 的备份
可以将指定的库、表导出为 SQL 脚本
使用命令 mysq| 导入备份的数据

六、实战案列

数据库备份之前,必须开启二进制日志文件

把内容插入进  /etc/my.cnf

vim /etc/my.cnf              #在 [mysqld] 里插入

log-error=/usr/local/mysql/data/mysql_error.log
general_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
log-bin=mysql-bin
slow_query_log=ON
slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log
long_query_time=5

systemctl restart mysqld        #重启 mysql 服务,生成 二进制文件、日志文件

ls /usr/local/mysql/data         #里面 mysql-bin.00001,每重启一次mysql,就会生成一个二进制文件,mysql-bin.00002、mysql-bin.00003、....

环境准备:
use kgc;
create table info1 (
id int(4) not null auto_increment,
name varchar(10) not null,
age char(10) not null,
hobby varchar(50),
primary key (id));
insert into info1 values(1,'user1',20,'running');
insert into info1 values(2,'user2',30,'singing');

6.1 MySQL完全备份与恢复

InnoDB 存储引擎的数据库在磁盘上存储成三个文件 : db.opt( 表属性文件)、表名.frm(表结构文件)、表名.ibd(表数据文件)

6.1.1 物理冷备份与恢复

systemctl stop mysqld
cd /usr/local/mysql/
tar zcvf mysql_all-data_$(date +%F).tar.gz data       # 压缩备份
mv /usr/local/mysql/mysql_all-data_2024-09-02.tar.gz /opt/backup
mv /usr/local/mysql/data/ /home           #模拟数据库挂了,data没了
tar zxvf mysql_all-data_2024-09-02.tar.gz -C /usr/local/mysql/      #解压恢复
cd /usr/local/mysql/data
ls

 

6.1.2 mysqldump 备份与恢复(温备份)

mysqldump (导出) 、mysql命令 (导入)
create table info2 (id int,name char(10),age int,sex char(4));
insert into info2 values(1,'user',11,' 性别 ');
insert into info2 values(2,'user',11,' 性别 ');
(1) 、完全备份一个或多个完整的库 ( 包括其中所有的表 )
mysqldump -u root -p[ 密码 ] --databases 库名 1 [ 库名 2] ... > / 备份路径 / 备份文件名 .sql
# 导出的就是数据库脚本文件(导出的是你之前操作的命令,相当于重做一遍
  当备份时不加 --databases(只有表,没有库)
:
①、备份 kgc库 结构和数据
mysqldump -u root -p123456 --databases kgc > /opt/backup/kgc_all.sql
 
②、备份mysql与kgc两个库结构和数据
mysqldump -u root -p123456 --databases mysql kgc > /opt/backup/mysql-kgc.sql    
①、备份一个 kgc 库 结构和数据
②、备份 mysql 与kgc两个库结构和数据
(2) 、完全备份 MySQL 服务器中所有的库
mysqldump -u root -p[ 密码 ] --all-databases > / 备份路径 / 备份文件名 .sql
:
mysqldump -u root -p123456 --all-databases > /opt/backup/all-databases.sqll
(3) 、完全备份指定库中的部分表
mysqldump -u root -p[ 密码 ] 库名 [ 表名 1] [ 表名 2] ... > / 备份路径 / 备份文件名 .sql
:
①、完全备份kgc下info1表
mysqldump -u root -p123456 kgc info1 > /opt/backup/kgc_info1.sql
②、完全备份kgc下info2表
mysqldump -u root -p123456 kgc info2 > /opt/backup/kgc_info2.sql
③、完全备份kgc下info1表和info2表
mysqldump -u root -p123456 kgc info1 info2 > /opt/backup/kgc_info1_and_info2.sql
④、完全备份kgc下info1表结构
mysqldump -u root -p123456 -d kgc info1 > /opt/backup/kgc_info1_table.sql
# 使用 -d 选项,说明 只保存数据库的表结构
# 不使用 “-d" 选项,说明表数据也进行备份
# 做为一个表结构模板
(4) 查看kgx下info1备份文件
grep -v "^--" /opt/backup/kgc_info1.sql | grep -v "^/" | grep -v "^$"

6.1.3 Mysql 完全恢复

# 恢复数据库
1. 使用 mysqldump 导出的文件,可使用导入的方法
source 命令
mysql 命令
2. 使用 source 恢复数据库的步骤
登录到 MySQL 数据库
执行 source 备份 sql 脚本的路径
①、source命令恢复数据(恢复库下的表)
1、 模拟数据库出现问题
[root@server1 backup]# mysql -uroot -p123456       # 登录数据库
mysql> use kgc;                 # 查看数据库信息
mysql> drop table info1;          # 删除kgc库下info1表
mysql> show tables;
2、恢复数据表
mysql> use kgc;       #进入kgc数据库
mysql> source /opt/backup/kgc_info1.sql        #恢复kgc下info1表(kgc_info1)

 

②、source恢复数据 

mysql -uroot -p123456 -e 'drop table kgc.info2';              #删除kgc库下的info2
mysql -uroot -p123456 -e 'show tables from kgc';             #查看kgc库下的表
+---------------+
| Tables_in_kgc |
+---------------+
| info1         |
| ky37          |
+---------------+
mysql -uroot -p123456 kgc < /opt/backup/kgc_info2.sql        #恢复kgc库下的info2表
mysql -uroot -p123456 -e 'show tables from kgc';              #查看kgc库下的表
+---------------+
| Tables_in_kgc |
+---------------+
| info1         |
| info2         |
| ky37          |
+---------------+

备份时 加--databases 和 不加--databases 的区别

[root@mysql abc]# mysql -uroot -p123123 -e 'show tables from kgc;'      # 查看kgc库下的表
备份时加 --databases , 表示 针对于kgc库
mysqldump -uroot -p123456 --databases kgc > /opt/backup/kgc_all.sql    
# 备份kgc库和数据
# 恢复命令过程为:
mysql -uroot -p123123
drop database kgc;
exit
mysql -uroot -p123456 kgc < /opt/backup/kgc_all.sql       #恢复kgc数据
备份时不加 --databases(只有表,没有库) ,表示 针对kgc下的所有表
mysqldump -uroot -p123456 kgc > /opt/backup/kgc.sql      # 备份kgc的数据(没有库)
# 恢复过程:
mysql -uroot -p123123
drop database kgc;
create database kgc;       #不加--databases,没有kgc库,要自己创建
exit
mysql -uroot -p123456 kgc < /opt/backup/kgc.sql
# 查看 kgc_all.sql kgc.sql
主要原因在于两种方式的备份(前者会从 "create databases" 开始 , 而后者则全是针对表格进行操作)
4. 在生产环境中,可以使用 Shell 脚本自动实现定时备份(时间频率需要确认)
0 1 * * 6 /usr/local/mysql/bin/mysqldump -uroot -pabc123 kgc info1 >
./kgc_infol_$(date +%Y%m%d).sql ;/usr/local/mysql/bin/mysqladmin -u root -p
flush-logs

 ①、加--databases

②、不加--databases

 数据库迁移

当备份时不加 --databases(只有表,没有库)

mysqldump -uroot -p123456 A > /opt/backup/A.sql   和

mysqldump -uroot -p123456 --databases A > /opt/backup/A_all.sql   的区别

vim A_all.sql     # --databases 多了创建库,使用库 的过程;不加 --databases 没有库,只有表

 数据库A 迁移到 数据库B

[root@localhost ~]# mysqldump -uroot -p123456 A > /opt/backup/A.sql

[root@localhost ~]# mysql -uroot -p123456 -e 'show tables from B';

[root@localhost ~]# mysql -uroot -p123456 B < /opt/backup/A.sql 

[root@localhost ~]# mysql -uroot -p123456 -e 'show tables from B';
+-------------+
| Tables_in_B |
+-------------+
| a1          |
| a2          |
+-------------+

6.2 MySQL 增量备份与恢复

6.2.1 MySQL 数据库增量恢复
1. 一般恢复
将所有备份的二进制日志内容全部恢复
2. 基于位置恢复
数据库在某一时间点可能既有错误的操作也有正确的操作
可以基于精准的位置跳过错误的操作
发生错误节点之前的一个节点,上一次正确操作的位置点停止
3. 基于时间点恢复
跳过某个发生错误的时间点实现数据恢复
在错误时间点停止,在下一个正确时间点开始
6.2.2 MySQL 增量备份
一、增量备份实验
1.开启二进制日志功能
vim /etc/my.cnf
[mysqld]
log-bin=mysql-bin
binlog_format = MIXED # 可选,指定二进制日志 (binlog) 的记录格式为 MIXED (混合输入)
server-id = 1 # 可加可不加该命令
# 二进制日志 (binlog) 3 种不同的记录格式 : STATEMENT ( 基于 SQL 语句 ) ROW( 基于行 ) MIXED( 混合
模式 ) ,默认格式是 STATEMENT
STATEMENT (基于 SQL 语句) :
每一条涉及到被修改的 sql 都会记录在 binlog
缺点:日志量过大,如 sleep() 函数, last_insert_id()> ,以及 user-defined fuctions udf )、
主从复制等架构记录日志时会出现问题
总结:增删改查通过 sql 语句来实现记录,如果用高并发可能会出错,可能时间差异或者延迟,可能不是我们
想想的恢复可能你先删除或者在修改,可能会倒过来。准确率底
ROW( 基于行 )
只记录变动的记录,不记录 sql 的上下文环境
缺点 : 如果遇到 update......set....where true 那么 binlog 的数据量会越来越大
总结: update delete 以多行数据起作用,来用行记录下来,
只记录变动的记录,不记录 sql 的上下文环境,
比如 sql 语句记录一行,但是 ROW 就可能记录 10 行,但是准确性高,高并发的时候由于操作量,性能变低 比较
大所以记录都记下来,
MIXED 推荐使用
一般的语句使用 statement ,函数使用 ROW 方式存储。
systemctl restart mysqld
=====================================================================
mysql 增量备份 STATEMENT ROW 通俗解释
MySQL 中,增量备份是指只备份发生变化的数据,而不是整个数据库。在增量备份中,可以使用基于语句
Statement )或基于行( Row )的方式来记录和复制这些变化。
基于语句的增量备份( Statement-Based Incremental Backup ):
通俗解释:就像记录每一步操作一样,基于语句的增量备份会记录每个 SQL 语句的变化,而不是具体的数
据行。当备份时,只需要记录执行过的 SQL 语句,而不是具体的数据内容。
适用场景:适用于简单的 SQL 语句操作,如 INSERT UPDATE DELETE 等,可以通过记录 SQL 语句来还
原数据变化。
基于行的增量备份( Row-Based Incremental Backup ):
通俗解释:就像记录每个人的变化一样,基于行的增量备份会记录每个数据行的变化情况,而不是 SQL 语句。当备份时,只需要记录哪些数据行发生了变化,而不是具体的SQL 语句。
适用场景:适用于复杂的数据变化情况,如涉及多个表之间关联的操作,可以通过记录数据行的变化来还原数据。
在增量备份中,选择基于语句或基于行的方式取决于您对数据变化的关注点和备份恢复的需求。基于语句的增量备份更注重SQL 操作的记录,而基于行的增量备份更注重数据行的变化情况。根据具体情况选择合适的备份方式可以更有效地保护和恢复数据。
======================================================================
查看二进制日志文件的内容
cp /usr/local/mysql/data/mysql-bin.000002 /opt/
mysqlbinlog --no-defaults /opt/mysql-bin.000002
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
#--base64-output=decode-rows :使用 64 位编码机制去解码( decode )并按行读取( rows
#-v: 显示详细内容
#--no-defaults : 默认字符集(不加会报 UTF-8 的错误)
PS: 可以将解码后的文件导出为 txt 格式,方便查阅
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002 >
/opt/mysql-bin.000002
例如, STATEMENT 模式记录量较少,但有可能会因为没有记录下所有细节而产生问题; ROW 模式可以记录下所有细节,但是记录量可能会非常大。所以在实际使用中需要根据情况选择适合的模式。
二进制日志中需要关注的部分
1 at :开始的位置点
2 end_log_pos :结束的位置
3 、时间戳: 210712 11:50:30
4 SQL 语句
2. 进行完全备份 ( 增量备份时基于完全备份的,所以我们直接完全备份数据库 )
[root@mysql data]# mysqldump -uroot -p school info > /opt/school_info1_$(date
+%F).sql
[root@mysql data]# mysqldump -uroot -p123123 school > /opt/school_all_$(date
+%F).sql
3. 可每天进行增量备份操作,生成新的二进制日志文件 ( 例如 :mysql-bin.000002)
mysqladmin -u root -p flush-logs
4. 插入新数据,以模拟数据的增加或变更
PS: 在第一次完全备份之后刷新二进制文件,在第二个二进制文件中记载着 " 增量备份的数据 "
mysql> create database ky29;
Query OK, 1 row affected (0.00 sec)
mysql> use ky29;
Database changed
mysql> create table test1 (id int(4),name varchar(4));
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test1 values(1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test1 values(2,'two');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test1;
+------+------+
| id | name |
+------+------+
| 1 | one |
| 2 | two |
+------+------+
2 rows in set (0.00 sec)
5. 再次生成新的二进制日志文件 ( 例如 :mysql-bin.000003)
mysqladmin -u root -p flush-logs
# 之前的步骤 4 的数据库操作会保存到 mysql-bin.000002 文件中,之后我们测试删除 ky29 库的操作会保存在
mysql-bin.000003 文件中 (以免当我们基于 mysql-bin.000002 日志进行恢复时,依然会删除库)
6.2.3 MySQL 增量恢复
1、 一般恢复
(1) 、模拟丢失更改的数据的恢复步骤(直接使用恢复即可)
备份 ky11 库中 test1
mysqldump -uroot -p123123 ky29 test1 > /opt/ky29_test29.sql
删除 ky13 库中 test1
drop table ky13.test1;
恢复 test1
mysql -uroot -p ky13 < info-2023-04-29.sql
# 查看日志文件
[root@mysql data]# mysqlbinlog --no-defaults --base64-output=decode-rows -v
mysql-bin.000002
(2) 、模拟丢失所有数据的恢复步骤
模拟丢失所有数据
[root@mysql data]# mysql -uroot -p123123
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| ky13 |
| mysql |
| performance_schema |
| school |
| sys |
| test |
+--------------------+
7 rows in set (0.00 sec)
mysql> drop database ky29;
Query OK, 1 row affected (0.00 sec)
mysql> exit
基于 mysql-bin.000002 恢复
mysqlbinlog --no-defaults /opt/mysql-bin.000002 | mysql -u root -p
2. 断点恢复
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
:
at 302
#201122 16:41:16
插入了 "user3" 的用户数据
at 623
#201122 16:41:24
插入了 "user4" 的用户数据
(1) 、基于位置恢复
插入三条数据
mysql> use ky29;
mysql> select * from test1;
+------+------+
| id | name |
+------+------+
| 1 | one |
| 2 | two |
+------+------+
2 rows in set (0.00 sec)
mysql> insert into test1 values(3,'true');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test1 values(4,'f');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test1 values(5,'t');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test1;
+------+------+
| id | name |
+------+------+
| 1 | one |
| 2 | two |
| 3 | true |
| 4 | f |
| 5 | t |
+------+------+
5 rows in set (0.00 sec)
# 需求:以上 id =4 的数据操作失误,需要跳过
确认位置点,刷新二进制日志并删除 test1
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000003
960 停止
1066 开始
# 刷新日志
mysqladmin -uroot -p123123 flush-logs
mysql> use ky13;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_ky29 |
+----------------+
| test1 |
+----------------+
1 row in set (0.00 sec)
mysql> drop table ky29.test1;
Query OK, 0 rows affected (0.00 sec)
基于位置点恢复
# 仅恢复到操作 ID “623" 之前的数据,即不恢复 "user4" 的数据
mysqlbinlog --no-defaults --stop-position='623' /opt/mysql-bin.000002 | mysql -
uroot -p
# 仅恢复 "user4" 的数据,跳过 "user3" 的数据恢复
mysqlbinlog --no-defaults --start-position='623' /opt/mysql-bin.000002 | mysql -
uroot -p
mysqlbinlog --no-defaults --start-position='400' --stop-position='623'
/opt/mysql-bin.000002 | mysql -uroot -p # 恢复从位置为 400 开始到位置为 623 为止
(2) 、基于时间点恢复
mysqlbinlog [--no-defaults] --start-datetime=' - - 日 小时 : 分钟 : ' --stop
datetime=' - - 日小时 : 分钟 : ' 二进制日志 | mysql -u 用户名 -p 密码
# 仅恢复到 16:41:24 之前的数据,即不恢复 "user4" 的数据
mysqlbinlog --no-defaults --stop-datetime='2023-04-22 16:41:24' /opt/mysql
bin.000002 | mysql -uroot -p
# 仅恢复 "user4" 的数据,跳过 "user3" 的数据恢复
mysqlbinlog --no-defaults --start-datetime='2023-04-22 16:41:24' /opt/mysql
bin.000002 | mysql -uroot -p
如果恢复某条 SQL 语之前的所有数据,就 stop 在这个语句的位置节点或者时间点
如果恢复某条 SQL 语句以及之后的所有数据,就从这个语句的位置节点或者时间点 start
七、总结
mysql 备份与恢复 : 备份的类型 :
1 、物理备份、逻辑备份
物理备份 : 冷备、温备、热备
1 )冷备 : tar ,需要关闭 mysql 服务,或者确保 mysql 服务在进行 tar 备份时,没有客户端的写入操作
2 )温备 : mysqldump ,这个是 mysql 自带的备份工具,特性,逐表备份,每备份一张表时,会先 drop
刑除,然后重新 create 创建表结构,然后再锁表(仅锁定写的操作,但可读),进行 insert 语句的备
份,备份完成后,进行 unlock 解锁 , 然后继续备份下一个
3 )热备 : xtrabackup mysqlhotcopy 等热备工具(第三方 ) ,在 mysql 正常运行时,进行备份、
2 、逻辑备份 :
1 )全量备份 : tar mysqldump -u -p --all-databases
2 )增量备份 : 主要使用 bin-log 二进制日志来完成备份,同时每个增量备份的文件,可以通
:mysqladmin -u -p flush-logs 来刷新生成新的增备的日志文件,同时可以结合 crontab 完成自动刷新
+----------------+
| test1 |
+----------------+
1 row in set (0.00 sec)
mysql> drop table ky29.test1;
Query OK, 0 rows affected (0.00 sec)
基于位置点恢复
# 仅恢复到操作 ID “623" 之前的数据,即不恢复 "user4" 的数据
mysqlbinlog --no-defaults --stop-position='623' /opt/mysql-bin.000002 | mysql -
uroot -p
# 仅恢复 "user4" 的数据,跳过 "user3" 的数据恢复
mysqlbinlog --no-defaults --start-position='623' /opt/mysql-bin.000002 | mysql -
uroot -p
mysqlbinlog --no-defaults --start-position='400' --stop-position='623'
/opt/mysql-bin.000002 | mysql -uroot -p # 恢复从位置为 400 开始到位置为 623 为止
(2) 、基于时间点恢复
mysqlbinlog [--no-defaults] --start-datetime=' - - 日 小时 : 分钟 : ' --stop
datetime=' - - 日小时 : 分钟 : ' 二进制日志 | mysql -u 用户名 -p 密码
# 仅恢复到 16:41:24 之前的数据,即不恢复 "user4" 的数据
mysqlbinlog --no-defaults --stop-datetime='2023-04-22 16:41:24' /opt/mysql
bin.000002 | mysql -uroot -p
# 仅恢复 "user4" 的数据,跳过 "user3" 的数据恢复
mysqlbinlog --no-defaults --start-datetime='2023-04-22 16:41:24' /opt/mysql
bin.000002 | mysql -uroot -p
如果恢复某条 SQL 语之前的所有数据,就 stop 在这个语句的位置节点或者时间点
如果恢复某条 SQL 语句以及之后的所有数据,就从这个语句的位置节点或者时间点 start PS: 再进行基于二进制文件的增备恢复时,有必要的话,需要先恢复完备的数据,再逐个恢复增备的数
据,直到恢复至我们需要恢复的数据为止
3 )差异备份 : 需要选择保存日志的格式为 ROW (基于行)的备份方式日志保存的类型 :
1) 混合模式 Mixed( 建议使用 )
2) 基于行 ROWS
3) 基于 sql ( 默认 )
mysql 恢复的方式 :
1) 基于冷备 (tar )形式 : tar zxvf 解压打包的 /usr/local/mysql/data 数据下的内容
2 )基于自带的温备工具 : 使用 mysgldump 进行备份后,可使用两种方式进行恢复
: mysql -u -p 库名 < /opt/mysql_all.sql( 备份文件的路径 )
mysql -u -p -e 'source /opt/mysql_all.sql' 直接使用 source 进行恢复
3 )基于日志 : bin-log ,首先开启二进制日志的配置 log-bin=mysql-bin log_format=MiXED,
然后在 /usr/local/mysql/data MysQL 工作目录下,会生成 mysql-bin.00000x 的二进制日志文件
接着使用 mysqlbinlog --no-defaults 二进制日志路径 mysql -u -p 基于完整的二进制日志文件进行恢复基于位置点和时间点进行恢复: 使用 mysqlbinlog --no-defaults --base64-output=decode-rows -v 二进制日志文件路径,查看正确操作和需要跳过的错误操作的at (position 位置点)和 datetime (时间点)来进行恢复
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值