高性能MySQL笔记（下） - 版本历史

Admin：/* 确定期望的日志位置 */

2019-08-08T10:07:04Z

‎确定期望的日志位置

Admin：/* 计划外提升 */

2019-08-08T10:05:07Z

‎计划外提升

Admin：/* 确定期望的日志位置 */

2019-08-08T09:56:29Z

‎确定期望的日志位置

Admin：/* 15.7备份和恢复工具 */

2017-12-07T04:16:02Z

‎15.7备份和恢复工具

Admin：/* 15.6 从备份中恢复 */

2017-12-07T04:15:47Z

‎15.6 从备份中恢复

Admin：/* 15.5备份数据 */

2017-12-07T04:15:05Z

‎15.5备份数据

Admin：/* 15.4管理和备份二进制日志 */

2017-12-07T04:14:45Z

‎15.4管理和备份二进制日志

Admin：/* 15.3设计MySQL备份方案 */

2017-12-07T04:14:23Z

‎15.3设计MySQL备份方案

Admin：/* 第十二章高可用性 */

2017-12-07T04:13:36Z

‎第十二章高可用性

Admin：/* 十一章可扩展的MySQL */

2017-12-07T04:12:58Z

‎十一章可扩展的MySQL

@@ 第154行： / 第154行： @@
 ====<font color=red>计划外提升</font>====
-====确定期望的日志位置====
+确定期望的日志位置
 如果有备库和新主库的位置不相同，则需要找到该备库最后一条执行的事件在新主库的二进制日志中相应的位置，然后执行CHANGE MASTER TO 。可以通过mysqlbinlog工具来找到备库执行的最后一条查询，然后在主库找到同样一条查询，进行简单的计算即可得到。示例命令如下（不需要用户名密码）：<br />

@@ 第152行： / 第152行： @@
 [https://www.douban.com/note/446551760/ RESET MASTER 和RESET SLAVE]
-====计划外提升====
+====<font color=red>计划外提升</font>====
-<font color=red>!!!</font>
 ====确定期望的日志位置====

@@ 第153行： / 第153行： @@
 ====计划外提升====
 ====确定期望的日志位置====
 如果有备库和新主库的位置不相同，则需要找到该备库最后一条执行的事件在新主库的二进制日志中相应的位置，然后执行CHANGE MASTER TO 。可以通过mysqlbinlog工具来找到备库执行的最后一条查询，然后在主库找到同样一条查询，进行简单的计算即可得到。示例命令如下（不需要用户名密码）：<br />
    mysqlbinlog   mysql-bin.000011 | tail -n 30

@@ 第582行： / 第582行： @@
 ;InnoDB Recovery Toolkit:如果InnoDB数据损坏到了根本不能启动MySQL的程度，还可以使用Percona出品的InnoDB Recovery Toolkit从表空间数据文件里抽取数据。可以从 http://www.percona.com/software 免费获取
-==15.7备份和恢复工具==
+==备份和恢复工具(15.7)==
@@ 第592行： / 第592行： @@
 ;mylvmbackup:它通过LVM快照帮助MySQL自动备份
 ;Zmanda Recovery Manager:有免费和商业两种版本。它是一个备份和恢复的管理器，并非单一工具。
 =附录D EXPLAIN=
 一个复杂的例子

@@ 第486行： / 第486行： @@
     Logical volume "backup_mysql" successfully removed
-==15.6 从备份中恢复==
+==从备份中恢复(15.6)==
 恢复时我们喜欢以  --skip-networking 和 --socket=/tmp/mysql_recover.sock 选项来启动MySQL
-===15.6.1恢复物理备份===
+===恢复物理备份===
 *对于MyISAM可能需要LOCK TABLES 和 FLUSH TABLES
 *对于InnoDB如果事务日志文件和表空间文件不匹配——例如，替换了表空间文件，但没有替换事务日志文件——InnoDB会拒绝启动
@@ 第496行： / 第496行： @@
 *建议观察MySQL启动时的错误日志： '''$ tail -f /var/log/mysql/mysql.err'''
 *注意MySQL在有错时也会启动，只是InnoDB不会工作
-===15.6.2恢复逻辑备份===
+===恢复逻辑备份===
 *禁掉二进制日志通常是个好主意，除非要将还原操作复制到备库
 *加载巨大文件对一些存储引擎也有影响。应该以可控大小的块来加载，并逐个提交事务
@@ 第522行： / 第522行： @@
 ;pt-fifo-split:这个程序还可以帮助分块加载大文件，而不是在单个大事务中操作，这样效率更高
-===15.6.3基于时间点的恢复===
+===基于时间点的恢复===
 参考一下10.7节案例：[http://blog.sina.com.cn/s/blog_70207ec20102v9vf.html mysql开启二进制日志记录文件 简介： MySQL的二进制日志]<br />
@@ 第560行： / 第560行： @@
 接下来是检查数据以确保没有问题，然后关闭服务器并撤销对my.cnf的改变，最后重启服务器
-===15.6.4更高级的恢复技术===
+===更高级的恢复技术===
 ;用于快速恢复的延时复制:当延时复制时，在备库执行问题语句前发现了问题，则恢复就更容易了：
 :先停止备库，然后 '''START SLAVE UNTIL master_log_file='binlog.000002',master_log_pos=829090187'''
@@ 第576行： / 第576行： @@
 :#在server2上用STOP SLAVE停掉复制进程
 :#将所需表从server2复制到server1
-===15.6.5InnoDB崩溃恢复===
+===InnoDB崩溃恢复===
 ;二级索引损坏:一般可用 OPTIMIZE TABLE 来修复
 ;innodb_force_recovery及聚簇索引损坏:聚簇索引损坏时也许只能使用 '''innodb_force_recovery''' 选项来导出表。

@@ 第409行： / 第409行： @@
 </source>
-==15.5备份数据==
+==备份数据(15.5)==
-===15.5.1生成逻辑备份===
+===生成逻辑备份===
 ;SQL导出: 如导出test下的t1表：mysqldump test t1
 ;符号分隔文件备份:特点是速度快，比SQL方式快一倍，以下是导出和导入的例子：
@@ 第419行： / 第419行： @@
 </source>
-===15.5.2文件系统快照===
+===文件系统快照===
 [[MySQL基于LVM快照的备份恢复]]<br />

@@ 第395行： / 第395行： @@
 :*故意将一个备库延时一段时间对于某些灾难场景非常有用。例如延时复制一小时，当一个不期望的语句在主库上运行后，将有一个小时的时间观察到并从中继日志重放之前停掉复制。然后可以提升备库为主库。重放少量相关的日志事件，跳过错误的语句。这比我们后面要讨论的基于时间点的恢复技术可能要快很多。pt-slave-delay工具可以帮助实现这个方案
-==15.4管理和备份二进制日志==
+==管理和备份二进制日志(15.4)==
 *它们对于基于时间点的恢复是必须的
 *MySQL复制也使用二进制日志，因此备份和恢复的策略经常和复制相互影响

@@ 第352行： / 第352行： @@
 = 第十四章应用层优化 =
 = 第十五章备份与恢复=
-==15.3设计MySQL备份方案==
+==设计MySQL备份方案(15.3)==
 建议：
 *在生产环境中，对于大数据库来说，物理备份是必须的：逻辑上备份太慢并受到资源限制，从逻辑备份中恢复需要很长时间。基于快照的备份，例如Percona XtraBackup 和 MySQL Enterprise Backup（[http://blog.csdn.net/yangzhawen/article/details/44808225 mysql enterprise backup入门使用]） 是最好的选择
@@ 第361行： / 第361行： @@
 *通过演练整个恢复过程来测试备份和恢复，测算恢复所需的资源(CPU、磁盘空间、实际空间以及网络带宽等)
 *对安全性要仔细考虑。如果有人能接触生产服务器，他是否也能访问备份服务器呢？反过来呢？
-===15.3.1在线备份还是离线备份===
+===在线备份还是离线备份===
 避免使用 FLUSH TABLES WITH READ LOCK 的最好方法是只使用InnoDB表。<br />
-===15.3.2逻辑备份还是物理备份===
+===逻辑备份还是物理备份===
 ;逻辑备份:要测试备份和恢复的时间
 :PerconaServer的mysqldump会对输出格式化，能减少2/3的还原时间
@@ 第370行： / 第370行： @@
 建议混合使用物理备份和逻辑备份：先使用物复制，以此数据启动MySQL服务器实例并运行 mysqlcheck 。然后周期性的使用mysqldump 执行逻辑备份。
-===15.3.3备份什么===
+===备份什么===
 ;非显著数据:例如，二进制日志和InnoDB事务日志
 ;复制配置:如果要恢复一个涉及复制关系的服务器，应该备份所有与复制相关的文件，例如二进制日志、中继日志、日志索引文件和.info文件。至少应该包含 SHOW MASTER STATUS 和/或 SHOW SLAVE STATUS 的输出。执行FLUSH LOGS 也非常有好处，可以让MySQL从一个新的二进制日志开始。从日志的开头做基于故障时间点的恢复要比从中间容易。
@@ 第385行： / 第385行： @@
 *备份所有数据，然后发送到一个有去重特性的目的地，例如ZFS文件管理程序
-===15.3.4存储引擎和一至性===
+===存储引擎和一至性===
 ;数据一致性:也可以使用 mysqldump来获得InnoDB表的一致性逻辑备份，采用 --single-transaction 选项
 ;文件一致性:对于 InnoDB，确保文件在磁盘上的一致性更难。即使使用 FLUSH TABLES WITH READ LOCK，InnoDB依旧在后台运行：插入缓存、日志和写线程断续将变更合并到日志和表空间文件中。这些线程设计上是异步的——在后台执行这些工作可以帮助InnoDB取得更高的并发性——正因为如此它们与LOCK TABLES无关。因此，不仅需要确保每个文件内部是一致的，还需要同时复制同一个时间点的日志和表空间文件。如果 在备份时有其它线程在修改文件，或在与表空间文件不同的时间点备份日志文件，会在恢复后再次因系统损坏而告终。可以通过以下几个方法规避这个问题：

@@ 第318行： / 第318行： @@
 =第十二章高可用性=
-==12.4避免单点故障==
+==避免单点故障(12.4)==
-===12.4.2同步复制===
+===同步复制===
 ;1.MySQL Cluster;它在所有的节点上进行主—主复制。这意味着在任何节点上写入；这些节点拥有等同的读写能力。每一行都是冗余存储的，这样即便丢失了一个节点，也不会丢失数据。
 :已经大规模在线产品的使用经验
@@ 第335行： / 第335行： @@
 *写入速度由最差的结点来决定
 *。。。。所有不建议用
-===12.4.3基于复制的冗余===
+===基于复制的冗余===
 复制管理器是使用标准MySQL复制来创建冗余的工具。它通常监控和管理三件事：
 *应用和MySQL的通信
@@ 第344行： / 第344行： @@
 ;[http://mysql-mmm.org MMM]:问题比较多，它在人工—故障转移时比较有用。但在自动-故障转移时遇到了不少问题
 ;另一个是 [http://code.google.com/p/mysql-master-ha/ MAH工具集]:它比较新，它有一个很好的测试集，可以防止一些MMM遇到过的一些问题
-==12.5故障转移和故障恢复==
+==故障转移和故障恢复(12.5)==
 在UNIX领域，故障转移常常使用High Availability Linux 项目提供的工具来完成。Pacemaker是栈中一个主要的工具，它替代了老的心跳工具。<br />
 以下小节提供了一些比较普遍的故障转移技术
-===12.5.1提升备库或者切换角色===
+===提升备库或者切换角色===
 = 第十三章云端的MySQL =
 = 第十四章应用层优化 =

@@ 第245行： / 第245行： @@
 =十一章可扩展的MySQL=
-==11.1什么是可扩展性==
+==什么是可扩展性(11.1)==
 可扩展性表明了，当需要增加资源以执行更多工作时系统能获得划算的同等提升。以下是可扩展性定律的三种模型：<br />
 [[文件:ScalabilityLaw2.png|600px|缩略图|居中|线性扩展、Amdahl扩展及USL扩展定律]]
-==11.2扩展MySQL==
+==扩展MySQL(11.2)==
-===11.2.4向外扩展===
+===向外扩展===
 ;3.选择分区键:
 [[文件:PatitionTheoryDemo.png|500px|缩略图|居中|两个数据模型，一个易于分片，另一个则难以分片]]
@@ 第281行： / 第281行： @@
 '''另外几个集群中间件''' [http://blog.csdn.net/lichangzhen2008/article/details/44708227 TDDL、Amoeba、Cobar、MyCAT架构比较]
-===11.2.6通过集群扩展===
+===通过集群扩展(11.2.6)===
 ;1.MySQL Cluster:当使用MySQL来控制NDB时，行的主键就是键，其他的列是值。
 :需要 高速连接设备+大量内存（服务器间需要大量内存）
@@ 第291行： / 第291行： @@
 ;3.ScaleBase:是一个软件代理。相似的还有 ScaleArc、dbShards
-===11.2.7内向扩展===
+===内向扩展===
 *如果应用层认为关联表具有层次关系，那么归档的顺序也应该和它一样
 *当解除归档时，可以设置一检查点。如用户的最后登录时间
@@ 第303行： / 第303行： @@
 ::可以使用动态分片轻松实现这种策略。如：分片目录表可能定义如下：
 [[文件:ActiveUserShard.png|300px|缩略图|居中|active shard]]
-==11.3负载均衡==
+==负载均衡(11.3)==
-===11.3.1直接连接===
+===直接连接===
 ;基于会话分离（推荐）:可以在会话层设置一个标志位，表明用户做了更新，就将该用户的查询在一段时间内总是指向主库。
 ;基于版本的分离:这个基于会话的分离相似：你可以跟踪对象的版本号及/或时间戳，通过从备库读取对象的版本或时间以戳来判断数据是否足够新。如，在用户在发表了一篇文章后，可以更新用户的版本，这样就会从主库去读取数据了。
 ;基于全局版本/会话的分离:当写时执行一次SHOW MASTER STATUS，把日志坐标写到REDIS，然后在备上SHOW SLAVE STATUS，把结果同之前缓存比较，如果备库更新则可以安全写入。
 :pt-heartbeat可以监控延迟
-===11.3.2引入中间件===
+===引入中间件===
 如HAProxy
-===11.3.3一主多备间的负载均衡===
+===一主多备间的负载均衡===
 ;过滤和数据分区:可以使用复制过滤技术在相似的备库上对数据进行分区。
 :但没有内建的办法在行级别上进行复制过滤。你可以使用一些独创的技术实现，如用触发器和一些不同的表
 ;保证备库跟上主库:可以使用 MASTER_POS_WAIT(file, pos) ，直到备库跟上主库。见 10.6.6
 ;同步写操作:也可以用MASTER_POS_WAIT()函数来确保写操作已经被同步到一个或多个备库上。
 =第十二章高可用性=
 ==12.4避免单点故障==