注意：复制不等于备份 复制是备份的一个环节。
为什么要要备份mysql
- 用于数据容灾。
- 防止误删数据。
- 审计：数据快照，过去某个时间点的数据状态。
- 用作线下测试。
定义恢复需求
规划恢复策略时，有两个重要的需求可以帮助思考：恢复点目标（PRO)和恢复时间目标（RTO）。他们定义了可以容忍丢失多少数据，以及需要等待多久将数据恢复。
- 系统可以容忍丢失多少数据？需要故障恢复，还是可以接受自从上次日常备份后所有的工作全部丢失？是否有法律法规的要求？
- 恢复需要在多长时间内完成？哪种类型的宕机是可以接受的？哪些影响（例如，部分服务不可用）是应用和用户可以接受的？当那些场景发生时，又该如何持续服务？
- 需要恢复什么？常见的需求是恢复整个服务器，单个数据库，单个表，或仅仅是特定的事务或语句
设计mysql备份方案
建议：
- 大数据库使用物理备份，逻辑备份太慢并且受资源限制。基于快照的备份，例如Perconna XtraBackup和MySQL Enterprise Backup是最好的选择。
- 保留多个备份集
- 定期从逻辑备份（或者物理备份）中抽取数据进行恢复测试
- 保存二进制日志以用于基于故障时间点的恢复。expire_logs_days(日志保留时间)应该设置的足够长.至少大于全量备份的间隔时间。
- 完不借助备份工具本身来监控备份和备份的过程。需要另外验证备份是否正常。
- 通过演练整个恢复过程来测试备份和恢复。测算恢复所需要的资源（CPU、磁盘空间、实际时间，以及网络带宽等）
- 对安全性要仔细考虑。
在线备份还是离线备份
- 锁时间：需要持有锁多长时间，例如备份期间持有的全局FLUSH TABLES WITH READ LOCK?
- 备份时间： 复制备份到目的地需要多久
- 备份负载：在复制备份到目的地时对服务器性能的影响有多少
- 恢复时间：把备份镜像从存储位置复制到MySQL服务器，重放二进制日志需要多久？
最大的权衡是备份时间与备份负载。提高备份的优先级，代价是降低服务器性能。
逻辑备份还是物理备份
- 逻辑备份:就是导出sql文件。
- 物理备份:复制物理文件。
- 逻辑备份有如下的优点：
- 逻辑备份可以使用编辑器或grep和sed之类的命令查看和操作的普通文件。
- 恢复非常简单。直接导入。
- 可以通过网络来备份和恢复。
- 非常灵活，因为mysqldump大部分人喜欢的工具。
- 与存储引擎无关。
- 有助于避免数据损坏，物理备份可能磁盘损坏。
- 逻辑备份的缺点：
- 必须由数据库服务器完成生成逻辑备份的工作，因此要使用更多的cpu周期。
- 逻辑备份文件本身很大传输慢。
- 导出的数据可能和恢复的数据不一致(软件bug可能会导致)。
- 逻辑备份恢复要重新执行sql文件比较慢。
-
物理备份优点：
-
基于文件的物理备份只需把数据库文件复制到仓库
-
恢复更简单，取决于存储引擎。对于MyISAM复制到目的地即可。InnoDB需要停止数据库服务采取其他的步骤InnoDB和MyISAM的物理备份非常容易跨平台、操作系统和MySQL版本
-
物理备份中恢复会更快不需要执行任何SQL。
-
物理备份的缺点：
-
InnoDB的原始文件通常比相应的逻辑备份要大的多。InnoDB的表空间包含很多未使用的空间。还有很多空间被用来做存储数据意外的用途（插入缓冲、回滚段等）
-
物理备份不总是可以跨平台、操作系统以及MySQL版本。文件名大小写敏感和浮点格式是可能会遇到的麻烦。很可能因浮点格式不同而不能移动文件到另一个系统
注意：
逻辑备份恢复时间不确定，问题很大。
物理备份后要测试备份是否可用。
不能完全依赖物理备份也要定期来个逻辑备份。
备份什么
需要恢复什么就备份什么，最简单的测率是指备份数据和表定义
下面是MySQL备份需要考虑的几点：
扫描二维码关注公众号，回复：
4553083 查看本文章
- 非显著数据： 容易被忽略的数据，例如二进制日志和InnoDB事务日志
- 代码 ： 触发器和存储过程
- 复制配置： 有复制关系的。二进制日志、中继日志、日志索引文件和info文件
- 服务器配置： 配置文件
选定的操作系统文件管理脚本等
增量备份和差异备份：
- 差异备份：上次全备份后所有改变的部分而做的备份，
- 增量备份：上次备份后所有修改做的备份
下面是一些建议：
- 使用Percona XtraBackup和MySQL Enterprise Backup中的增量备份特性。
- 备份二进制日志。
- 不要备份没有改变的表。
- 不要备份没有改变的行
- 某些数据根本不需要备份
- 备份所有的数据，然后发送到一个有去重特性的目的地。
增量备份的缺点包括增加恢复复杂性，额外的风险，以及更长的恢复时间。如果可全备，考虑到简便性，我们建议尽量做全备。
存储引擎和一致性
- 数据一致性：只要服务器上使用REPEATABLE READ事务隔离级别，并且没有任何DDL，就一定会有完美的一致性，以及基于时间点的数据快照，且在备份过程中不会阻塞任何后续的工作。
- 文件一致性:如果是MyISAM，flush tables with read lock 可以锁住并刷新表一旦完成可以安全复制文件。innodb不是安全的因为插入换从写日志是异步线程不收影响 所有要查看show innodb status当缓存挂起才可以复制。
管理和备份二进制日志
- 服务器的二进制日志是备份的最重要因素之一。
- MySQL 5.6版本的mysqlbinlog有一个非常方便的特性，可以连接到服务器上来实时对二进制日志做镜像。
- 二进制日志格式: 使用mysqlbinlog工具查看二进制日志的内容。时间的日志和时间、原服务器的服务器ID，end_log_pos,下一个时间的偏移字节值、时间类型，元服务器上执行时间的线程ID，对于审计和执行CONNECTION_ID()函数很重要。 exec_time,在原服务器上时间产生的错误代码。
- 安全清理二进制日志：expire_log_days 设置清理日志时间。
备份数据
- 逻辑备份： SQL导出和符号分隔文件
SQL导出：mysqldump不是生成sql逻辑备份的唯一工具。例如，也可以用mydumper或phpmyadmin工具来创建。- SQL逻辑备份缺点：
1. schema和数据存储在一起
2. 巨大的SQL语句
3. 单个巨大的文件
4. 逻辑备份的成本很高
- SQL逻辑备份缺点：
- 符号分割文件备份：
- 可以使用SQL命令SELECT INTO OUTFILE 以符号分割文件格式创建数据的逻辑备份优点是备份和还原速度更快。
- 可以使用LOAD DATA INFILE方法加载数据到表中
- SELECT INTO OUTFILE方法的一些限制：
只能备份到运行MySQL服务器的机器上的文件中
运行MySQL的系统用户必须有文件目录的写权限，因为是由MySQL服务器来执行文件的写入，而不是运行SQL命令的用户。
出于安全原因，不能覆盖已经存在的文件，不管文件权限如何
从备份中恢复
如何恢复数据取决于是怎么备份的。可能需要一下部分或全部步骤：
- 停止MySQL服务器
- 记录服务器的配置和文件权限
- 将数据从备份中移到MySQL数据目录
- 改变配置
- 改变文件权限
- 限制访问模式重启服务器，等待完成启动
- 载入逻辑备份文件
- 检查和重放二进制日志
- 检测已经还原的数据
- 以完全权限重启服务器
- 在恢复过程中，保证MySQL除了恢复进程外不接受其他访问，这一点往往比较重要。
- 加参数 --skip-networking 和 --socket=/tmp/mysql_recover.sock来启动MySQL