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
