MySQL恢复备份读书笔记
1.
任何执行时间长于 wait_timeout或interactive_timeout选项值得备份，都会导致会话被关闭，这也会隐含执行UNLOCK TABLES命令。
2.
对于使用FLUSH TABLES WITH READ LOCK的备份策略来讲，一个共同的缺陷是它们需要两个独立的线程来完成备份过程。运行FLUSH TABLES WITH READ LOCK命令，
然后从当前连接退出将自动执行一条UNLOCK TABLES命令。从FLUSH TABLES WITH READ LOCK成功返回后，任何备份选项都必须在一个不同的并发线程中执行，只
有当适用的备份选项完成时，才可以执行UNLOCK TABLES.
3.
在高并发系统中使用FLUSH TABLES WITH READ LOCK命令的风险是有可能会需要较长的时间，因为有其他耗时较长的语句需要执行，最好被监控和终结，对于在
线型应用的影响又是是不可忽略的。
4.
对MySQL备份的常用方案：
* 文件系统冷备份
|-->优点：过程简单，允许使用任何文件系统备份工具来执行备份。
|-->缺点：备份过程中MySQL实例不能用
恢复过程需要一个相似的系统（操作系统，目录结构）
重启MySQL时，MySQL实例的内存池要重新初始化，为SQL语句提供最忧性能
* SQL导出（dump）
| 带有--lock tables选项的mysqldump命令一次只能锁定一个模式的表，如果应用程序写入不同模式，且使用了不支持事务的存储引擎，则
在备份过程可能会产生不一致数据。
|-->优，缺点：它支持跨操作系统的兼容解决方案（一个在linux上备份的可在windows恢复），他是一种静态备份（1.主二进制文件，2.主
二进制文件位置）,数据是ASII格式的（可以用文本编辑器查看备份文件）。对于较小的数据库来讲是非常理想的，5GB-20GB
之间。不适用于对时间要求非常强的恢复（由于使用 mysqldump的输出进行恢复的操作是单线程），另外mysqldump命令使用
的是MySQL的c/s协议，不一定必须在同一台服务器上执行，有助于减少I/O写入需求及磁盘容量，但是会增加命令执行时间和
网络利用。
* 表抽取
|--> ASII格式备份是另外一种形式是产生一个逐表的数据文件（一个表一个数据文件），既是数据快照。快照对于全系统不适用，但是对于
时序数据，一次性写入数据和档案数据，尤其是如果数据手工分区，则是非常理想的。
mysqldump命令在底层文件权限方面具有较大灵活性，这种权限是输出文件所必需的。
* 文件系统热快照
|-->实际上并不是一个MYSQL特有的策略，而是一种在直连驱动器上使用逻辑卷管理器（LVM）的基于磁盘的操作系统命令。
* InnoDB热备份
|-->对于一个只有InnoDB的MYSQL实例，有两个产品可进行非阻断式热备份。MySQL Enterprise Backup(MEB),既是InnoDB Hot Backup,和XtraBackup.
注意：除了支持适用于InnoDB的应用程序外，也支持MYSQL的元模式和任何其他表的myisam备份，但需要将表锁定。
5.
*时间点恢复技术（PITR）：它是将mysql二进制文件应用于某个被恢复的快照上来执行的。
*注意：系统管理员用操作系统命令删除，mysql二进制日志文件是一种可能引起灾难的做法，删除二进制日志文件时，一定要用适当的MYSQL命令。
* 灾难恢复 ---> DR
* 平均恢复时间--->MTTR
* 平均检测时间--->MTTR
* 恢复点目标---->RPO (组织规定的时间点，到这个时刻数据必须恢复)
* 恢复时间目标--->RTO(能接受的恢复状况的持续时间)
* 服务等级协议--->SLA(包含对技术和业务两方面决策的职责)
6.
MYSQL的复制局限性：
|--->复制的滞后（show slave status 命令确定MYSQL复制信息包括滞后信息）
|--->一致性（percona工具包 pt_table_checksum检查数据一致性的开源工具）
|--->模式一致性，用layman检测模式差异
MYISAM恢复过程是对一个给定表的索引重建，这就是为什么不是在系统启动时给出一个关于MYISAM表发生崩溃报告。而是在通过一个给定的索引访问表
数据时才给出的原因。
*myisam-recover配置选项可以为MYISAM表提供某些不会引起崩溃的属性。
*mysql重启对于性能影响--InnoDB缓冲池，myisam关键缓存在内的主内存缓冲区清空。
*进行一个冷文件系统拷贝或文件快照恢复就是安装所有mysql数据和配置文件，这需要在所安装的mysql不运行时进行。
*mysql企业备份（MEB）恢复：使用MEB进行一个静态备份的恢复是一条简单的命令，但必须执行一些前期的准备：
*1.停止mysql实例
*2.删除任何现存的数据目录
*3.创建一个干净的数据目录，或授权用户创建数据目录的权限
运行 mysqlbackup copy-back
*在执行XtraBackup恢复前首先要停止mysql，并要确保现有数据目录确实存在是空的，他不会检查mysql没有运行/
*注意：这里有一个管理二进制日志的技巧，即在备份执行期间执行一条FLUSH LOGS命令，这会在备份时产生一个新的二进制日志文件，并能方便地确定
将要用到的二进制日志的开始位置。
7.
mysql配置选项：数据管理： datadir-->默认情况，是所有数据库，表，innodb数据，服务器日志和二进制日志文件在系统的存储目录。datadir中的
目录代表数据库。对于linux，这个目录是：/var/lib/mysql
basedir basedir-->是mysql的安装目录在文件系统的位置，把她放到path里面方便访问mysql服务器和客户端程序。
linux中这个目录是：/usr
警告：在创建任何数据库对象之前，应该首先设置innodb_file_per_table变量，不可能有混合模型，从一个系统表空间安全转移一个
逐表表空间的唯一方法是：转存所有数据，停用所有对象，然后重建数据库对象并重新载入所有数据。
在MYSQL中，为了收回空间，最先考虑的就是删除二进制文件，手动删除的问题就是MYSQL中对这个文件的引用没有删除，正确方法应该是用PURGE MASTER命
令，这样会删除物理文件和内部定义。
*为了更好地管理系统，一个配置良好的MYSQL安装应该清晰地分隔mysql数据目录，mysql二进制日志和mysql中继日志目录。
在一台外部系统上测试备份，以确保再进行备份的时刻未发生损坏是非常重要的。
*RDS恢复（亚马逊web服务为mysql提供一种远程数据库服务）的局限性：不能物理访问数据库服务器，尽管有API接口可以用来改变mysql配置项的设置和查
看mysql的错误日志，但却不能查看正在使用的系统资源或其他东西。（例如：二进制日志）
*常见停机的原因：存储系统的问题是首要因素，而操作系统和网络也是停机的原因，SAN 和RAID存储系统不是备份的解决方案。
*使用管道命令时，第一个好处就是输出文件在执行过程中就被自动压缩了，不需要任何额外的临时磁盘空间，这在磁盘空间有限时是很有帮助的，执行者条
命令需要额外的时间是它的不利之处，与mysqldump组合使用，锁定全部表，影响应用程序的访问/
*linux的nice和ionice命令可以改变一个系统上的工作的优先级并降低某些命令的系统影响。将linux管道和一条可用的魅力组合使用时，可以实现跨越网络
的流式输出，而不用在数据库服务器上写入任何备份信息。------通过利用netcat(nc)，可以在一个给定端口直接通过TCP/UDP来传递文件，这通常需要确定
目标服务器能够进行接收通信，还需要某个确定端口进行额外的防火墙访问。
*MEB并不支持对远端主机的来连接，尽管MEB有一个--host配置选项，仅适用于一种情形：这个选项存在于一个[client]配置段中且在执行期间没有产生错误
消息，因此需要对这个选项的作用进行分析，在对分析结果进行验证的时候会用到远程连接。
*用ezNcrypt生成一个加密的mysqldump备份。
8.
云计算中的MYSQL:
对于mysql数据库解决方案（除了一个运行股票的mysql实现外，其余都是在虚拟环境中运行）
Amazon,HP,Google,都提供基于运用核心mysql服务器的mysql云部署。
*亚马逊关系数据库服务:
*Amazon Relational Database Service(RDS):
|-->优点：具有能够激活对mysql软件的更新进行自动监控能力，（使用--auto-minor-ver
sion-upgrade-true选项）。具有不用额外的工作就可以更新或退回RDS实际尺寸
能力。
|-->局限性：不能直接访问mysql配置文件（my.cnf）访问变化参数需要通过rds-modify-db
-parameter-group命令。任何用户都不能拥有super权限。不能访问度二进制
日志。不能访问错误日志。
*Google Cloud SQL：
|-->http://effectiveMySQL.com/article/setting-up-google-cloud-sql/
*HP Cloud Database as a Service(DBAAs):
|-->http://hpcloud.com
*云计算的使用并不意味着灾难不会出现。云已经能确保使适当的DR操作更加普遍，云的使用需要访问用户业务数据而引起的安全方面的
担忧。适当的加密很重要。