mysqldump 逻辑备份和物理备份

逻辑备份

逻辑备份是备份sql语句,在恢复的时候执行备份的sql语句实现数据库数据的重现。

工具:mysqldump

特点:

1、可移植性比较强

2、备份和恢复的花费时间长,不适用于大型业务系统

物理备份

物理备份就是备份数据文件了,比较形象点就是cp下数据文件,但真正备份的时候自然不是的cp这么简单。

工具:xtrabackup

特点:

1、不具备移植性,备份环境和恢复环境必须是完全相同的

2、备份和恢复时间较快,适用于大型业务系统

mysqldump特性

备份原理:

通过协议连接到mysql数据库,将需要备份的数据查询出来,将查询出的数据转换成对应的insert语句,当我们需要还原这些数据时,只要执行这些insert语句,即可将对应的数据还原。

 

优点:

可以直接使用文本处理工具处理对应的备份数据,因为备份数据已经被mysqldump转换为了对应的insert语句,所以,我们可以借助文件系统中的文本处理工具对备份数据进行直接处理。


缺点:

1、无法备份索引等信息(因为它只是单纯的将需要备份的数据查询出来,还原后需要重建索引)

2、当数据为浮点类型时,会出现精度丢失

3、备份过程属于逻辑备份,备份速度、恢复速度与物理备份工具相比较慢,而且mysqldump备份的过程是串行化的,不会并行的进行备份,如果想要并行备份,可以使用mydumper,但是此处我们不考虑这些,只考虑mysqldump,当数据量较大时,一般不会使用mysqldump进行备份,因为效率较低。

 

特性:

mysqldump对innodb存储引擎支持热备,innodb支持事务,我们可以基于事务通过mysqldump对数据库进行热备。

mysqldump对myisam存储引擎只支持温备,通过mysqldump对使用myisam存储引擎的表进行备份时,最多只能实现温备,因为在备份时会对备份的表请求锁,当备份完成后,锁会被释放。

 

备份数据长这样:

[root@backup2] /var/lib/mysql$ mysqldump -uroot test -p
Enter password:
-- MySQL dump 10.13 Distrib 5.7.21, for Linux (x86_64)
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 5.7.21-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `tb1`
--

DROP TABLE IF EXISTS `tb1`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `tb1` (
`name` varchar(60) DEFAULT NULL,
`age` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `tb1`
--

LOCK TABLES `tb1` WRITE;
/*!40000 ALTER TABLE `tb1` DISABLE KEYS */;
INSERT INTO `tb1` VALUES ('hanli',27),('dongpo',24),('heiqi',28),('yeyi',28),('xueji',24);
/*!40000 ALTER TABLE `tb1` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2018-03-17 4:50:16

选项

--master-data   

标记备份开始时binlog所对应的position(位置)

值为0:不记录对应二进制日志文件位置,与不使用此选项的效果相同。

此值为1:记录对应二进制日志文件位置,默认值,也就是说,使用--master-data与使用--master-data=1的效果相同,会在备份文件中生成对应的"CHANGE MASTER TO"语句,此语句中标明了备份开始时二进制日志的前缀名以及其所处的position(位置),生成此语句的目的是,在主从复制结构中的"从服务器"中通过备份sql还原数据以后,告诉"从库",从"主库"的二进制日志文件中的哪个位置开始"同步"。如果我们没有使用主从复制结构,同时又想要在备份时记录二进制日志文件的position,则可以将此选项的值设置为2

此值为2:记录对应二进制日值文件的位置,如果将此选项的值设置为2,则会在备份文件中生成对应的"CHANGE MASTER TO"语句,但是此语句将会被注释,只是单纯的为了记录备份时的二进制日志文件位置

--flush-logs

如果,我们将二进制日志的大小设置为600兆,那么,每当二进制日志的大小满600兆,对应的二进制日志文件就会发生滚动,生成一个新的二进制文件,并将原来的600兆保存,假设,我们使用mysqldump对数据库进行备份的那一刻,对应binlog的大小为300兆,也就是说,备份操作开始时,二进制日志文件的position的位置则会处于文件居中的位置,那么,当我们想要找到对应position进行重放时,此位置之前的操作记录对于我们来说都是"无用"的,可是比较尴尬的是,我们还必须找到此位置,这样就会产生一些"多余的工作量"。如果使用了此选项,备份开始时就会滚动一次二进制日志,无论二进制日志对应的文件大小是否达到600兆,都会滚动,这样,我们就能在对应的二进制日志文件的开头部分开始重放日志了。

--routines

备份时存储过程和存储函数

--triggers

备份时触发器

--events

备份时事件表

--single-transaction(表类型为innodb,热备)

--lock-all-tables(表类型为myisam,温备)

对所有数据备份时,使用--lock-all-tables,表示对所有库的所有表加读锁,对应的短选项为-x,与--single-transaction不能同时存在,示例如下

mysqldump -uroot -h192.168.1.146 --lock-all-tables --all-databases -p > dbbackup.sql

对指定的数据库进行备份时,使用--lock-tables,表示对指定库的所有表加锁,对应的短选项为-l,与--single-transaction不能同时存在时,示例如下

mysqldump -uroot -h192.168.1.146 --lock-tables --databases zsythink -p > zsythink.sql

也可以使用上述语句对innodb存储引擎的表进行备份,不过这样就不是热备了,而是温备。

实例:

对于innodb存储引擎

1、未开启二进制日志,备份指定数据库

mysqldump -uroot -h192.168.1.146 --single-transaction --routines --triggers --events --databases test -p > test.sql

2、开启二进制日志,备份指定数据库

mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --databases test -p >test.sql

3、开启二进制日志,备份所有数据库

mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --all-databases -p > dbbackup.sql

对于myisam存储引擎

1、未开启二进制日志,备份指定数据库

mysqldump -uroot -h192.168.1.146 --routines --triggers --events --lock-tables --databases test -p > test.sql

2、开启二进制日志的情况下,备份指定数据库

mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --routines --triggers --events --lock-tables --databases test -p > test.sql

3、开启二进制日志,备份所有数据库

mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --routines --triggers --events --lock-all-tables --all-databases -p > dbbackup.sql

数据恢复

注意:

因为恢复数据时会执行大量的insert语句,如果没有特殊要求,还原时没有必要将这些操作记录到二进制日志中,所以关闭当前会话的二进制日志记录。
set sql_log_bin=OFF;
所有恢复操作完成后,再将当前会话中的sql_log_bin再次开启。

恢复命令
\. /testdir/zsythink.sql
此命令只是恢复到了备份sql对应的时间点,还需要进行时间点还原。

进行时间点恢复时,备份时间点之后的数据则需要通过二进制日志进行还原,首先,要从二进制日志中提取对应的sql,提取sql的起始位置为备份开始时那一刻二进制文件对应的position,因为在使用mysldump备份时,我们推荐使用--master-data=2选项,所以在对应的数据库备份sql文件中应该存在对应的position,提取sql的结束位置应该是drop语句对应的位置,因为咱们模拟的场景是有人误操作drop了数据库,所以结束位置应该是drop语句的位置。注意,不要把误操作的drop语句提取出来,否则重放对应sql时又会将对应的数据删除,如果是那样就前功尽弃了。

原文:http://www.zsythink.net/archives/1450

转载于:https://www.cnblogs.com/fanren224/p/8590874.html

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值