MySQL复制（三） --- 高可用性和复制

实现高可用性的原则很简单：

1. 冗余(Redundancy)：若是一个组件出现故障，必须有一个备用组件。这个备用组件能够是standing by的，也能够是当前系统部署中的一部分。
2. 应急计划(Contigency plans)：若是一个组件出现故障，你必须知道作什么。这依赖于哪一个组件出现故障以及如何发生故障。
3. 程序(Procedure)：若是一个组件出现故障，你可以及时发现并迅速有效的执行你的计划。

冗余(Redundancy)

只要有单点故障(SPOF:Single Point of Failure)的存在，就没法保证系统的高可用性（关于单点故障能够参考Fenng的这篇文章，比较通俗易懂）。

为了搞清楚哪里须要冗余机制，咱们须要找到部署中全部潜在的单点。虽说起来简单，可是须要一点想象力，以确保真正找到所有单点。交换机，路由器，网卡甚至电缆都是单点，除了这些，电源和物理设施也很重要。还有一些也为成为单点，好比只有一个员工知道如何处理某种类型的故障，全部的网络都被集中到一个web页面进行管理等。但定位到全部的单点并不意味着你必需要所有消除它们，由于有些单点或许由于经济上，技术上或者地理上的缘由而没法彻底消除，但知道这些单点的存在将有助于出错时排错。

在考虑要不要消除某个单点，有些因素须要考虑：复制组件的成本，不一样组件发生故障的几率，替换组件的时机以及修复组件时的担当的风险。好比你替换一个组件须要一周时间，在这一周期间，运行中的备用组件也有可能出现故障，这些你都必需要考虑到。

一旦肯定要消除的单点，接下来就须要考虑如何创建冗余机制，有两种方案可供选择：1）为每个组件创建一个备用组件，若是原始组件发生故障，当即启用备用组件；2）系统自己有额外的容量，当一个组件出现故障时仍能hold住。第一种方案，虽然看起来简单，可是成本高。你必须让备用组件处于standby状态，一直和主组件保持一致。其优势就是在切换组件的时候不会损失性能，并且切换到standby组件所花的时间一般要比从新构建组件快。方案二为系统构建额外容量的方案可让你使用全部组件(资源)来运行系统，这样系统能够处理更高的瞬间峰值负载。但有一点必须明白，这种方案时，系统必须拥有额外的容量以保证在某些组件出现故障时系统仍然能hold住。有时候只为一个服务器发生故障留有余地还不够，这个时候你须要权衡，以及这种状况出现的几率是多少。好比安装了100台服务器，其中一台服务器发生故障的几率是1%，那么1台，2台，3台服务器发生故障的几率会是多少呢？根据二项式定理计算可获得依次为100%，20.33%，16.17%。

 

应急计划(Contigency plans)

只作冗余仍是不够，当你一个组件发生故障时，你还须要知道如何去应对。在以前的例子里，当Slave服务器出现故障时很容易去处理，由于只需把新的链接所有重定向到能工做的Slave服务器，同时你须要考虑：1）现有的链接怎么处理？仅仅停止程序并给用户返回一个出错信息明显不是一个好主意。一般状况下，在用户和数据库之间有一个应用层，这个时候应该让应用层向别的服务器提交查询；2）若是Master发生故障怎么处理？假设你已经提供了一个额外的Master作冗余，你还必须提供机制让全部Slave重定向新的Master。

下面介绍一下如何处理各类拓扑结构下MySQL服务器宕机的技术。通常来讲，须要考虑三种角色：Master，Slave，Relay。

• Slave故障：这是最简单处理的故障。由于Slave仅仅是用于读查询，只需通知负载均衡器该Slave出故障，而后负载均衡器就会把新的请求都重定向到工做中的其余Slave。这就须要剩下的Slave可以处理这些额外的负载。除了这以外，发生故障的Slave通常来讲不会影响复制机制的拓扑结构，也就不用去考虑特殊的拓扑结构以保证在Slave发生故障时易于管理。当Slave发生故障时，对于已经提交给该Slave并等待响应的查询，须要从新向工做的其余Slave提交查询请求。
• Master故障：若是Master发生故障，就必须用备用的Master替换以保证部署的系统能正常运行，而且要快。当Master发生故障时，全部的写请求当即终止，所以首先要作的就是启用新Master并把全部的写请求重定位过去。由于主Master发生故障了，全部的Slave都失去了Master链接。这就意味着Slave上数据已不是最新的，虽然还可以继续响应读请求。尽管如此，若是有些请求须要监听到达Slave的变化，这些请求可能会被阻止，而有些请求或许把本身写进Slave中继日志，并最终由Slave执行，这类请求就无需考虑。Master发生故障时，对于那些正在Master上等待某个事件的请求来讲状况更加糟糕。对于这种状况，须要进行处理，通常来讲就是用户被通知请求失败，而后须要从新发送请求。
• Relay故障：Relay服务器发生故障时须要进行一些特殊处理。若是Relay服务器发生故障，其余的Slave必须被重定向到其余的Relay服务器或者直接定向到Master。由于Relay服务器是用于缓解Master的负载，那么有可能出现Master没法处理Relay上的负载。
• 灾难恢复：在高可用性的世界里，灾难并不意味着地震或者洪水，它只是表示服务器发生了极坏的情况，并非局部的情况。好比说数据中心断电了。灾难的本质在于不少事情都同时出现故障，没法在一个数据中心经过备份服务器提供冗余解决问题。所以有必要要确保数据被保存在另一个安全的地方。不少公司会把不一样的组件放在不一样的办公室，即便公司相对较小的时候也这么干。

程序(Procedure)

若是你管理一个小站点，你能够不用规划并手动管理这些服务器，可是随着服务器数量的快速增加，自动化就变得颇有必要。特别是下列的这些工做：

• 追加新Slave：追加新Slave的方法有不少。通常的步骤是先获取现有一个服务器的快照，一般是一个Slave服务器，而后在新服务器上恢复快照，并在正确的位置开始复制。这个里须要注意的是获取服务器快照这一步，由于这将直接决定你能够多长时间让一个新Slave服务器上线。获取快照的方法有如下几种：
  • 使用mysqldump：使用mysqldump安全但比较慢。这种方法容许你用与以前不一样的存储引擎去恢复数据。若是使用InnoDB表的话，还能够获得一致性快照，这也意味着你不须要脱机进行快照。
  • 复制数据库文件：这个相对来讲要快一点，可是须要脱机。
  • 使用在线备份方法：有不一样的方法，好比InnoDB的热备份（Hot Backup）
  • 使用LVM获取快照：在Linux系统，可使用Logical Volume Manager(LVM)来得到卷快照。它要求你事先建立好特殊的LVM卷。
  • 使用文件系统的快照方法：Solaris ZFS文件系统支持内置快照，这种方法用于备份很是快。除了mysqldump之外，这些方法都不能使用一个不一样的存储引擎来重建数据。
• 删除Slave：删除Slave只须要通知负载均衡器该Slave不可以使用便可。
• 切换Master：对于平常维护，将连在Master上的全部Slave切换到备份Master上，并通知负载均衡器该Master不可以使用，是一件很日常的事。这个过程应该能够无须宕机处理。这个能够经过Slave提高来完成，也能够采用更简单的host standby来解决。
• 处理Slave故障：Slave会出现故障，这只是一个频率问题。因此处理Slave故障在任何部署中都必须做为一个常规事件来对待。若是检测到Slave不在，通知负载均衡器该Slave不可以使用便可。
• 处理Master故障：当Master忽然出现故障时，你必须检测到这个故障，并把全部的Slave都连到一个备用服务器上，或者把其中一个Slave提高为新Master。
• Slave升级：把Slave升级到一个新版本通常不会有问题，但会暂时不可以使用，跟删除Slave操做差很少。
• Master升级：为了升级Master，常常有必要首先升级全部的Slave。但这也不必定。升级的时候，Master确定不可用，这跟处理Master故障操做差很少。

 热备份(Hot Standby)

最简单的复制服务器的拓扑就是热备份的拓扑。该拓扑结构里面包括一个Master和一个被称做热备份的专用服务器。工做原理就是当Master发生故障时，热备份当即充当Master的镜像服务器，全部的客户端和Slave服务器所有切换到热备份服务器进行工做。不过切换的时候须要考虑一些细节的问题：1）当切换到热备份的服务器时，你须要从新定位须要从哪里开始复制二进制日志，通常热备份的日志位置信息和Master不同；2）某个Slave可能须要的二进制日志在热备份服务器上不必定有；3）当修好的Master切换回来的时候，它上面的有些修改可能任何其余Slave都将来得及复制。

首先，问题简单化，咱们看看从Master切换到热备份服务器的过程，该过程Master并不宕机。默认状况下，slave线程执行的事件并不写入二进制日志，可是做为热备份的slave明显是须要这些二进制日志的，因此为热备份服务器增长这样一个参数。

[mysqld]
log-slave-updates

切换时的主要问题在于，如何使得从热备份服务器开始复制的位置和从Master中止复制的位置彻底相同。有不少缘由可使得热备服务器和Master服务器的二进制日志位置信息不一致，好比Master启动的时候热备份服务器并无连上，即便这个没问题，也不能保证同一个事件写入Master和热备份服务器二进制日志的过程和时机彻底同样。

切换的基本思路是：确认让slave和热备份服务器在同一点上中止复制，而后让salve连到热备份服务器。

standby>SHOW SLAVE STATUS\G
...
Relay_Master_Log_File: master-bin.000096
...
Exec_Master_Log_Pos: 756648

slave>SHOW SLAVE STATUS\G
...
Relay_Master_Log_File: master-bin.000096
...
Exec_Master_Log_Pos: 743456

# 从上可知说明热备份服务器的日志位置要领先于Slave，因此须要让Slave从Master继续复制到和热备份同样的位置

slave>START SLAVE UNTIL MASTER_LOG_FILE = 'master-bin.000096' MASTER_LOG_POS = 756648;
slave>SELECT MASTER_POS_WAIT('master-bin.000096', 756648);

# 如今Slave和热备份服务器都在同一个点中止复制，就可让Slave连到热备份服务器上，可是指定从哪一个文件和位置开始复制呢。对于同一个复制点在Master上的文件和位置和热备份上的文件和位置是不同的。
standby>SHOW MASTER STATUS\G
                      File: standby-bin.000019
               Position: 56447
      Binlog_Do_DB:
Binlog_Ignore_DB:

slave>CHANGE MASTER TO
              MASTER_HOST = 'standby-1',
              MASTER_PORT = 3306,
              MASTER_USER = 'repl_user',
              MASTER_PASSWORD = 'xyzzy',
              MASTER_LOG_FILE = 'standby-bin.000019',
              MASTER_LOG_POS = 56447;
slave>START SLAVE;

若是Slave的复制位置在热备份服务器以前的话，咱们只需互换一下上面的步骤。下一节咱们将考虑如何处理Master意外中止的状况。

双Master(Dual Master)

双Master拓扑结构中，两个Master互相复制数据以保持同步。由于是对称的，这种设置容易使用。这种设置中，服务器能够是主动的(active)，也能够是被动(passive)的。主动的服务器是指接受写操做，而后这些变化经过复制传播到其余Slave上。被动的服务器是指不接受写而仅仅是跟随主动Master，随时准备切换。两个服务器有两种设置，一种是active-active，一种是active-passive，第二种很像热备份的的拓扑，带是因为是对称，切换起来比较方便。在双Master配置中，passive服务器并不必定要求接受读请求，这个时候其实就是一个冷备份。在双Master的拓扑中，并不必定非要经过复制来保证两个Master的同步。

active-active型双Master的经常使用的一个场景就是让服务器在物理上接近不一样的用户组。用户使用本地服务器，更改会被复制到另一台服务器来保持二者同步。因为事务是在本地提交的，因此响应比较快。但因为事务是本地提交的，两个服务器并非时时刻刻彻底一致的。这就会有些问题：1）若是同一个信息在两台服务器上更新，将会服务器将会产生冲突，复制也会终止。你能够只让其中一台接受写操做，能够在某种程度上避免冲突的发生。2）若是两台服务器在处于不一致状态下发生故障，有些事务将会丢失，这也是异步复制的硬伤，不过你能够经过使用半同步复制(MySQL 5.5引入)来限制事务丢失的个数。

对于active-passive型的来讲，你可能使用passive的Master来作服务器升级这样的管理工做。active-passive有一个根本性的问题须要解决。split-brain syndrome：当网络链接短期内中断，从而使得从服务器主动升级为主服务器，而后网络又恢复了。若是在他们各自为主服务器的时间里，更改在两台服务器上都执行就会产生冲突。当使用共享磁盘的方式时，两台服务器同时写磁盘会产生有趣的问题。

对于如何实现双Master直接的同步，有几种方案。

共享磁盘(Shared Disks)

 

 这是最直接的双Master方案：两个Master经过一个像SAN(Storage Area Network)的共享磁盘架构链接在一块儿，并被设置成使用相同的文件。由于其中一个是passive，它不会写任何东西到文件中，

使用DRBD复制磁盘(Replicated disks using DRBD)

 

双向复制(bidirectional replication)

 

半同步复制(Semisynchronous Replication)

 

Slave提高(Slave Promotion)