本文共 3722 字，大约阅读时间需要 12 分钟。

MySQL内建的复制功能是大规模、高性能应用的基础，应用“水平扩展”的架构，为服务器配置一个或多个备库，建设支持高性能、可扩展、灾难恢复、备份以及数据仓库的应用，这也是MySQL快速流行的关键原因。

MySQL的高可扩展是当应用的规模变得越来越庞大时还能保证快速、高效并且经济，可扩展能力也就是表明该系统当需要增加资源以执行更多工作时系统能够获得划算的等同的提升，不会出现系统收益递减转折点之后无法进一步增长。

第十章 复制

MySQL复制概述

简单说就是一台主库的数据可以同步到多台备库上，备库本身也可以被配置成另一台主库，主库和备库之间可以由多种组合方式。

MySQL的复制是通过在主库上记录二进制日志，在备库重放日志的方式来实现异步的数据复制，这意味着主备库一致性不能保证，存在一致延迟。

复制过程可以简述为：首先主库把数据更改记录到二进制日志，然后备库将主库上的日志复制到自己的中继日志中，备库读取中继日志中的事件，将其重放到备库数据上。

复制的原理

• 基于语句的复制

主库会记录那些造成数据更改的查询，备库实际上只是把主库上执行过的SQL再执行一遍

• 基于行的复制

实际数据记录在二进制日志中，可以正确的复制数据库中的每一行。

MySQL能够在这两种复制模式间动态切换，默认情况下使用的是基于语句的复制，但如果语句无法被正确复制时，就会切换到基于行的复制模式。

复制拓扑

复制拓扑的主要原则：

• 一个MySQL备库实例只能有一个主库
• 每个备库都有一个唯一的服务器ID
• 一个主库可以有多个备库
• 如果打开了log_slave_updates选项，备库直接可以传递主库的变更

现有的常见的复制拓扑结构：

• 一主库多备库
• 主动-主动模式，互为主库备库
  同时修改数据时容易产生数据一致，无法正常复制的问题，很难做好数据划分和权限。
• 主动-被动模式下的主-主复制
  执行ALTER TABLE时会锁住整个表，阻塞读写甚至导致服务中断，这时可以选择在被动库上操作，停止主动服务器上的备库复制线程，然后在被动服务器上执行修改，然后交换主被动角色，在先前的服务器上启动复制线程，在不影响正常业务的情况下完成大规模修改。
• 各自都拥有备库的主-主结构
• 环形复制
  双主的结构实际上就是环形结构的一种特例，环形结构是三个或更多的主库，每个服务器都是它之前服务器的备库，是它之后服务器的备库。环形结构要求每个节点都可用，所以非常脆弱，不应该得到提倡。
• 主库、分发主库以及备库
  主库和备库之间有一个分发主库来管理
• 树形或金字塔形
  主库分发到几个备库，这几个备库又各自分发到更多备库。

复制和容量规划

如果要增加数据库的性能到原来的两倍，不是简单的线性扩两倍机器那么简单，因为补充了备库，每一台备库做复制操作都是要消耗部分性能的，只有剩下的性能才能用来进行读操作，因此可能存在性能要求翻倍服务器翻三四倍的情况，并且随着要求越高需要新增的服务器远远不是线性扩展。

上述情况发生时就要考虑增加集群的写入能力，惟一的办法也就是对数据进行分区，这将会在后续的内容中讲到。

在构建大型应用时，有意让服务器不被充分使用，构建这样冗余容量也是实现高可用性的最佳方式之一，当然也可以让应用在降级模式下运行，第12章将会介绍更多。

复制的问题及解决方案

MySQL中的复制实现简单、配置容易，所以面对因为各种意外情况可能会导致停止，陷入混乱并中断，导致数据不一致等等。

常见的一些复制问题例如：

主备库关闭，主备库二进制日志损坏，备库中继日志损坏，使用了非事务型表，事务型和非事务型表混合使用，通过一些不确定的方式更改数据（例如带LIMIT的更新或者）可能会导致主备不一致，主备库使用的不同的存储引擎，不唯一的服务器ID，未定义的服务器ID，主-主的复制结构，过大的复制延时，受限制的复制带宽等等问题。

上述的复制过程中可能存在的问题在以后设计中都应该尽量避免出现，及时无法避免也应该仔细调研寻找一个较为平衡的方法解决。

第十一章 可扩展的MySQL

在MySQL扩展策略上，典型的应用在增长到非常庞大时，通常是从单个服务器转移到向外扩展的拥有读备库的架构，再到数据分片/或者按照功能分区。

可扩展性概述

从较高层次说，可扩展性就是能够通过增加资源来提升容量的能力，系统容量也就是在一定时间内能够完成的工作量，或可以简单的认为是处理负载的能力。

在进行资源扩充时，升级到两倍所需要的付出常常不只是最初开销的两倍，服务器数量和容量之间的关系远不是线性扩展那么简单，服务器数量到一定程度时甚至投入反而会带来负回报。

扩展MySQL

在扩展的过程中，自身使用更强悍的机器称为“向上扩展”，将任务分配到多台计算机上称为“向外扩展”，内部将一些很少使用或者不需要的数据清理或者归档称为“向内扩展”。

提前规划可扩展性

①应用的功能完成了多少 ②规划需要承担的负载有多少，预期的最大负载是多少 ③考虑系统依赖了其他部分来分担负载，例如备库，如果他们生效时，是否还能正常运行？是否需要禁用部分功能。

向上扩展

也可以叫垂直扩展，替换为性能更强的硬件，简单高效，无需关心一致性等问题。但向上扩展总会是有限制的，会存在性能的天花板，不断增长的业务会使得CPU内存一个个成为瓶颈，触及到向上扩展的天花板时就需要考虑向外扩展。

向外扩展

也可以叫水平扩展，策略主要分为三部分：复制、拆分、数据分片。

复制也就是将数据进行分发，备库用于读查询，另外就是将工作负载分布到多个“节点”，如何分布工作负载是一个复杂的话题。

1. 按功能划分

   这样划分不能无限地进行扩展，一个功能被捆绑到单个MySQL节点，只能进行垂直扩展。

2. 数据分片

   通常会对一些增长的非常庞大的数据进行分片，把数据分割成一小片或者一小块，存储到不同的节点。
   （分片一般实现较难，如果不是必要，尽量不要选择分片，尽可能的先通过性能调优或者更好的数据库设计来推迟分片。）

3. 选择分区键

   分区键决定了每一行分配到哪一个分区中，而可扩展性的一大原则就是避免不同分片节点间的交互，因此在保证分片足够小的同时，还要避免跨分片查询的情况出现。
   一个好的分区键常常是数据库中一个比较重要的实体的主键，尽量把相关联的实体靠的更近，并且一块块之间很少或几乎没有什么关联操作。

4. 多个分区键

   某些应用存在两个或更多个“维度”数据的时候，可能拥有多个分区键，这也意味着某些数据可能在系统中至少需要存储两份。

5. 跨分片查询

   一条查询语句如果需要获取多个分片上的数据的话，就需要将一条查询拆分成多条并行执行的查询，每个分片上执行一条。
   或者也可以借助汇总表来执行，也就是多一分冗余数据在全局节点中，并使用缓存来分担负载。

6. 节点、分片、数据的分配

   分片和节点不一定是一对一的关系，应尽可能在单个节点上存储多个分片，分片的大小应该是易于管理的足够小，小的分片是的数据备份和恢复更加容易。

通过多实例扩展

研究和经验表明MySQL并不能完全发挥现代硬件的性能，当扩展到超过24个CPU核心或者是128GB内存时，MySQL的性能趋于平缓不再上升。

可以在一台服务器上运行多个实例，然后划分服务器的硬件资源分配给每个实例。

向内扩展

对不再需要的数据进行归档和清理。将活跃数据和非活跃数据进行隔离。

负载均衡

负载均衡主要五个目的：①可扩展 ②高效性 ③可用性 ④透明性 ⑤一致性

• 直接连接

  应用直接和MySQL服务器相连，主要可以采用这些方法实现负载均衡：主备库的读/写分离；直接修改应用的配置，例如连接的数据库；为不同的服务器定不同的DNS；利用服务器间转移虚拟地址。

• 引入中间件

  中间件作为网络通信的代理，一边接受通信请求，一边将这些请求派发到指定的服务器上，中间件可以是硬件设备或者是软件。

第十二章 高可用性

“高可用性”简单来说意味着更少的宕机时间，容易与冗余、数据完整性，负载均衡混淆。

从以下两方面思考：

• 增加两次故障的正常运行时间
  防止故障发生，故障根源分析，事后检验。
• 减少从故障中恢复的时间
  建立冗余，让系统具备故障转移能力。

什么是高可用性

通常用百分比表示，可用性应该包括服务器正在运行的时间段和是否能以足够好的性能处理请求。

高可用性实际上是在宕机造成的损失与降低宕机所花费的成本之间去的一个平衡。

如何实现高可用性

高可用性的度量维度：平均失效时间、平均恢复时间

对系统变更保持管理，及时监控核心流程，建设具备提供冗余和故障转移能力的系统架构。

所有的宕机事件都是有多方面的失效联合到一起导致的，可以利用合适的方法确保单点的安全。

避免单点失效

冗余、备用组件的切换机制，或者是优秀的负载均衡器。

• 共享存储或磁盘复制
• MySQL主备库同步复制
• 基于复制的冗余

故障处理

故障转移和故障恢复，分别代表新的服务器替换和修复故障服务器重新再替换回来。

故障转移最重要的部分是故障恢复，要求服务器之间能够自如切换，也可以说是对称的复制布局。

• 提升备库或切换角色
• 虚拟IP地址或IP接管
• 代理、端口转发、网络地址切换、硬件负载均衡实现故障转移和恢复
• 在应用中处理故障转移

参考博文：

转载地址：https://blog.csdn.net/xiamaocheng/article/details/104577625 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！