1.背景
MySQL的cluster方案有很多官方和第三方的选择，选择多就是一种烦恼，因此，我们考虑MySQL数据库满足下三点需求，考察市面上可行的解决方案：
- 高可用性：主服务器故障后可自动切换到后备服务器
- 可伸缩性：可方便通过脚本增加DB服务器
- 负载均衡：支持手动把某公司的数据请求切换到另外的服务器，可配置哪些公司的数据服务访问哪个服务器
需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点：
综合考虑，决定采用MySQL Fabric和MySQL Cluster方案，以及另外一种较成熟的集群方案Galera Cluster进行预研。
2.MySQLCluster
简介：
MySQL Cluster 是MySQL 官方集群部署方案，它的历史较久。支持通过自动分片支持读写扩展，通过实时备份冗余数据，是可用性最高的方案，声称可做到99.999%的可用性。
架构及实现原理：
MySQL cluster主要由三种类型的服务组成：
- NDB Management Server：管理服务器主要用于管理cluster中的其他类型节点（Data Node和SQL Node），通过它可以配置Node信息，启动和停止Node。
- SQL Node：在MySQL Cluster中，一个SQL Node就是一个使用NDB引擎的mysql server进程，用于供外部应用提供集群数据的访问入口。
- Data Node：用于存储集群数据；系统会尽量将数据放在内存中。
缺点及限制：
- 对需要进行分片的表需要修改引擎Innodb为NDB，不需要分片的可以不修改。
- NDB的事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改；而Innodb支持所有的事务隔离级别，默认使用Repeatable Read，不存在这个问题。
- 外键支持：虽然最新的Cluster版本已经支持外键，但性能有问题（因为外键所关联的记录可能在别的分片节点中），所以建议去掉所有外键。
- Data Node节点数据会被尽量放在内存中，对内存要求大。
数据库系统提供了四种事务隔离级别：
A.Serializable（串行化）：一个事务在执行过程中完全看不到其他事务对数据库所做的更新（事务执行的时候不允许别的事务并发执行。事务串行化执行，事务只能一个接着一个地执行，而不能并发执行。）。
B.Repeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他其他事务对已有记录的更新。
C.Read Commited（读已提交数据）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新。
D.Read Uncommitted（读未提交数据）：一个事务在执行过程中可以看到其他事务没有提交的新插入的记录，而且能看到其他事务没有提交的对已有记录的更新。
3.MySQL Fabric
简介：
为了实现和方便管理MySQL 分片以及实现高可用部署，Oracle在2014年5月推出了一套为各方寄予厚望的MySQL产品 -- MySQL Fabric, 用来管理MySQL 服务，提供扩展性和容易使用的系统，Fabric当前实现了两个特性：高可用和使用数据分片实现可扩展性和负载均衡，这两个特性能单独使用或结合使用。
MySQL Fabric 使用了一系列的python脚本实现。
应用案例：由于该方案在去年才推出，目前在网上暂时没搜索到有大公司的应用案例。
架构及实现原理：
Fabric支持实现高可用性的架构图如下：
Fabric使用HA组实现高可用性，其中一台是主服务器，其他是备份服务器， 备份服务器通过同步复制实现数据冗余。应用程序使用特定的驱动，连接到Fabric 的Connector组件，当主服务器发生故障后，Connector自动升级其中一个备份服务器为主服务器，应用程序无需修改。
Fabric支持可扩展性及负载均衡的架构如下：
使用多个HA 组实现分片，每个组之间分担不同的分片数据（组内的数据是冗余的，这个在高可用性中已经提到）
应用程序只需向connector发送query和insert等语句，Connector通过MasterGroup自动分配这些数据到各个组，或从各个组中组合符合条件的数据，返回给应用程序。
缺点及限制：
影响比较大的两个限制是：
- 自增长键不能作为分片的键；
- 事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
测试高可用性
服务器架构：
功能 | IP | Port |
Backing store(保存各服务器配置信息) | 200.200.168.24 | 3306 |
Fabric 管理进程（Connector） | 200.200.168.24 | 32274 |
HA Group 1 -- Master | 200.200.168.23 | 3306 |
HA Group 1 -- Slave | 200.200.168.25 | 3306 |
安装过程省略，下面讲述如何设置高可用组、添加备份服务器等过程
首先，创建高可用组，例如组名group_id-1，命令：
mysqlfabric group create group_id-1
往组内group_id-1添加机器200.200.168.25和200.200.168.23：
mysqlfabric group add group_id-1 200.200.168.25:3306
mysqlfabric group add group_id-1 200.200.168.23:3306
然后查看组内机器状态：
由于未设置主服务器，两个服务的状态都是SECONDARY
提升其中一个为主服务器：
mysqlfabric group promote group_id-1 --slave_id 00f9831f-d602-11e3-b65e-0800271119cb
然后再查看状态：
设置成主服务器的服务已经变成Primary。
另外，mode属性表示该服务器是可读写（READ_WRITE)，或只读(READ_ONLY)，只读表示可以分摊查询数据的压力；只有主服务器能设置成可读写（READ_WRITE)。
这时检查25服务器的slave状态：
可以看到它的主服务器已经指向23
然后激活故障自动切换功能：
mysqlfabric group activate group_id-1
激活后即可测试服务的高可以性
首先，进行状态测试：
停止主服务器23
然后查看状态：
可以看到，这时将25自动提升为主服务器。
但如果将23恢复起来后，需要手动重新设置23为主服务器。
实时性测试：
目的：测试在主服务更新数据后，备份服务器多久才显示这些数据
测试案例：使用java代码建连接，往某张表插入100条记录，看备份服务器多久才能同步这100条数据
测试结果：
表中原来有101条数据，运行程序后，查看主服务器的数据条数：
可见主服务器当然立即得到更新。
查看备份服务器的数据条数：
但备份服务器等待了1-2分钟才同步完成（可以看到fabric使用的是异步复制，这是默认方式，性能较好，主服务器不用等待备份服务器返回，但同步速度较慢）
对于从服务器同步数据稳定性问题，有以下解决方案：
- 使用半同步加强数据一致性：异步复制能提供较好的性能，但主库只是把binlog日志发送给从库，动作就结束了，不会验证从库是否接收完毕，风险较高。半同步复制会在发送给从库后，等待从库发送确认信息后才返回。
- 可以设置从库中同步日志的更新方式，从而减少从库同步的延迟，加快同步速度。
在mysql中运行
install plugin rpl_semi_sync_master soname 'semisync_master.so';
install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_master_enabled=ON;
SET GLOBAL rpl_semi_sync_slave_enabled=ON;
修改my.cnf ：
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
sync_relay_log=1
sync_relay_log_info=1
sync_master_info=1
稳定性测试：
测试案例：使用java代码建连接，往某张表插入1w条记录，插入过程中将其中的master服务器停了，看备份服务器是否有这1w笔记录
测试结果，停止主服务器后，java程序抛出异常：
但这时再次发送sql命令，可以成功返回。证明只是当时的事务失败了。连接切换到了备份服务器，仍然可用。
翻阅了mysql文档，有章节说明了这个问题：
里面提到：当主服务器当机时，我们的应用程序虽然是不需做任何修改的，但在主服务器被备份服务器替换前，某些事务会丢失，这些可以作为正常的mysql错误来处理。
数据完整性校验：
测试主服务器停止后，备份服务器是否能够同步所有数据。
重启了刚才停止主服务器后，查看记录数
可以看到在插入1059条记录后被停止了。
现在看看备份服务器的记录数是多少，看看在主服务器当机后是否所有数据都能同步过来
大约经过了几十秒，才同步完，数据虽然不是立即同步过来，但没有丢失。
1.2、分片：如何支持可扩展性和负载均衡
fabric分片简介：当一台机器或一个组承受不了服务压力后，可以添加服务器分摊读写压力，通过Fabirc的分片功能可以将某些表中数据分散存储到不同服务器。我们可以设定分配数据存储的规则，通过在表中设置分片key设置分配的规则。另外，有些表的数据可能并不需要分片存储，需要将整张表存储在同一个服务器中，可以将设置一个全局组（Global Group）用于存储这些数据，存储到全局组的数据会自动拷贝到其他所有的分片组中。
4.Galera Cluster
简介：
Galera Cluster号称是世界上最先进的开源数据库集群方案
主要优点及特性：
- 真正的多主服务模式：多个服务能同时被读写，不像Fabric那样某些服务只能作备份用
- 同步复制：无延迟复制，不会产生数据丢失
- 热备用：当某台服务器当机后，备用服务器会自动接管，不会产生任何当机时间
- 自动扩展节点：新增服务器时，不需手工复制数据库到新的节点
- 支持InnoDB引擎
- 对应用程序透明：应用程序不需作修改
架构及实现原理：
首先，我们看看传统的基于mysql Replication（复制）的架构图：
Replication方式是通过启动复制线程从主服务器上拷贝更新日志，让后传送到备份服务器上执行，这种方式存在事务丢失及同步不及时的风险。Fabric以及传统的主从复制都是使用这种实现方式。
而Galera则采用以下架构保证事务在所有机器的一致性：
客户端通过Galera Load Balancer访问数据库，提交的每个事务都会通过wsrep API 在所有服务器中执行，要不所有服务器都执行成功，要不就所有都回滚，保证所有服务的数据一致性，而且所有服务器同步实时更新。
缺点及限制：
- 由于同一个事务需要在集群的多台机器上执行，因此网络传输及并发执行会导致性能上有一定的消耗。
- 所有机器上都存储着相同的数据，全冗余。
- 若一台机器既作为主服务器，又作为备份服务器，出现乐观锁导致rollback的概率会增大，编写程序时要小心。
- 不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…
- 不支持XA Transaction
目前基于Galera Cluster的实现方案有三种：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。
我们采用较成熟、应用案例较多的Percona XtraDB Cluster。
应用案例：
超过2000多家外国企业使用：
包括：
集群部署架构：
功能 | IP | Port |
Backing store(保存各服务器配置信息) | 200.200.168.24 | 3306 |
Fabric 管理进程（Connector） | 200.200.168.24 | 32274 |
HA Master 1 | 200.200.168.24 | 3306 |
HA Master 2 | 200.200.168.25 | 3306 |
HA Master 3 | 200.200.168.23 | 3306 |
4.1、测试数据同步
在机器24上创建一个表：
立即在25 中查看，可见已被同步创建
使用Java代码在24服务器上插入100条记录
立即在25服务器上查看记录数
可见数据同步是立即生效的。
4.2、测试添加集群节点
添加一个集群节点的步骤很简单，只要在新加入的机器上部署好Percona XtraDB Cluster，然后启动，系统将自动将现存集群中的数据同步到新的机器上。
现在为了测试，先将其中一个节点服务停止：
然后使用java代码在集群上插入100W数据
查看100w数据的数据库大小：
这时启动另外一个节点，启动时即会自动同步集群的数据：
启动只需20秒左右，查看数据大小一致，查看表记录数，也已经同步过来
5.对比总结
MySQL Fabric | Galera Cluster | |
使用案例 | 2014年5月才推出，目前在网上暂时没搜索到有大公司的应用案例 | 方案较成熟，外国多家互联网公司使用 |
数据备份的实时性 | 由于使用异步复制，一般延时几十秒，但数据不会丢失。 | 实时同步，数据不会丢失 |
数据冗余 | 使用分片，通过设置分片key规则可以将同一张表的不同数据分散在多台机器中 | 每个节点全冗余，没有分片 |
高可用性 | 通过Fabric Connector实现主服务器当机后的自动切换，但由于备份延迟，切换后可能不能立即查询数据 | 使用HAProxy实现。由于实时同步，切换的可用性更高。 |
可伸缩性 | 添加节点后，需要先手工复制集群数据 | 扩展节点十分方便，启动节点时自动同步集群数据，100w数据（100M）只需20秒左右 |
负载均衡 | 通过HASharding实现 | 使用HAProxy实现负载均衡 |
程序修改 | 需要切换成jdbc:mysql:fabric的jdbc类和url | 程序无需修改 |
性能对比 | 使用java直接用jdbc插入100条记录，大概2000+ms | 跟直接操作mysql一样，直接用jdbc插入100条记录，大概600ms |
6.实践应用
综合考虑上面方案的优缺点，我们比较偏向选择Galera 如果只有两台数据库服务器，考虑采用以下数据库架构实现高可用性、负载均衡和动态扩展：
如果三台机器可以考虑：
7.参考文档
MySQL各种集群解决方案的对比：https://www.acquia.com/blog/high-availability-database-tools
Percona XtraDB Cluster 搭配 HAProxy：http://itindex.net/detail/47688-percona-xtradb-cluster
MySQL Fabric : http://dev.mysql.com/doc/mysql-utilities/1.6/en/fabric.html
MySQL Cluster: http://dev.mysql.com/tech-resources/articles/mysql-cluster-7.3.html
Percona XtraDB Cluster: http://www.percona.com
======================================
前言
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用方案是一直以来的讨论热点，今天就各种的高可用方案，谈一下个人的一些看法，如有错误，还请指正！！
一、MySQL主从架构
此种架构，一般初创企业比较常用，也便于后面步步的扩展
1、成本低，布署快速、方便
2、读写分离
3、还能通过及时增加从库来减少读库压力
4、主库单点故障
5、数据一致性问题（同步延迟造成）
二、MySQL+DRDB架构
通过 DRBD 基于 block 块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题
1、高可用软件可使用 Heartbeat, 全面负责 VIP、数据与 DRBD 服务的管理
2、主故障后可自动快速切换，并且从库仍然能通过 VIP 与新主库进行数据同步
3、从库也支持读写分离，可使用中间件或程序实现
三、MySQL+MHA架构
MHA 目前在 Mysql 高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在 mysql 故障切换过程中，MHA 能做到快速自动切换操作，而且还能最大限度保持数据的一致性
1、安装布署简单，不影响现有架构
2、自动监控和故障转移
3、保障数据一致性
4、故障切换方式可使用手动或自动多向选择
5、适应范围大（适用任何存储引擎）
四、MySQL+MMM架构
MMM 即 Master-Master Replication Manager for MySQL（mysql 主主复制管理器），是关于 mysql 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），这个套件也能基于标准的主从配置的任意数量的从服务器进行读负载均衡，所以你可以用它来在一组居于复制的服务器启动虚拟 ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。
MySQL 本身没有提供 replication failover 的解决方案，通过 MMM 方案能实现服务器的故障转移，从而实现 mysql 的高可用。
1、安全、稳定性较高，可扩展性好
2、 对服务器数量要求至少三台及以上
3、 对双主（主从复制性要求较高）
4、 同样可实现读写分离
=============================
第一种：主从复制+读写分离
客户端通过Master对数据库进行写操作，slave端进行读操作，并可进行备份。Master出现问题后，可以手动将应用切换到slave端。
对于数据实时性要求不是特别严格的应用，只需要通过廉价的pc server来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力要比写压力大的多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似的方案解决数据库瓶颈问题。
第二种：Mysql Cluster
MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括 MySQL 服务器，NDB Cluster的数据节点，管理服务器，以及（可能）专门的数据访问程序。
由于MySQL Cluster架构复杂，部署费时（通常需要DBA几个小时的时间才能完成搭建），而依靠 MySQL Cluster Manager 只需一个命令即可完成，但 MySQL Cluster Manager 是收费的。并且业内资深人士认为NDB 不适合大多数业务场景，而且有安全问题。因此，使用的人数较少。
第三种：Heartbeat+双主从复制
heartbeat 是 Linux-HA 工程的一个组件,heartbeat 最核心的包括两个部分：心跳监测和资源接管。在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务
第四种：HeartBeat+DRBD+Mysql
DRBD 是通过网络来实现块设备的数据镜像同步的一款开源 Cluster 软件，它自动完成网络中两个不同服务
器上的磁盘同步，相对于 binlog 日志同步，它是更底层的磁盘同步，理论上 DRDB 适合很多文件型系统的高可
用。
第五种：Lvs+keepalived+双主复制
Lvs 是一个虚拟的服务器集群系统，可以实现 LINUX 平台下的简单负载均衡。keepalived 是一个类似于
layer3, 4 & 5 交换机制的软件，主要用于主机与备机的故障转移，这是一种适用面很广的负载均衡和高可用方
案，最常用于 Web 系统。
第六种:MariaDB Galera
MariaDB Galera Cluster 是一套在mysql innodb存储引擎上面实现multi-master及数据实时同步的系统架构，业务层面无需做读写分离工作，数据库读写压力都能按照既定的规则分发到 各个节点上去。在数据方面完全兼容 MariaDB 和 MySQL。
该架构主要有以下几种特性：
(1).同步复制 Synchronous replication
(2).Active-active multi-master 拓扑逻辑
(3).可对集群中任一节点进行数据读写
(4).自动成员控制，故障节点自动从集群中移除
(5).自动节点加入
(6).真正并行的复制，基于行级
(7).直接客户端连接，原生的 MySQL 接口
(8).每个节点都包含完整的数据副本
(9).多台数据库中数据同步由 wsrep 接口实现
其局限性体现在以下几点：
(1).目前的复制仅仅支持InnoDB存储引擎,任何写入其他引擎的表，包括mysql.*表将不会复制,但是DDL语句会被复制的,因此创建用户将会被复制,但是insert into mysql.user…将不会被复制的.
(2).DELETE操作不支持没有主键的表,没有主键的表在不同的节点顺序将不同,如果执行SELECT…LIMIT… 将出现不同的结果集.
(3).在多主环境下LOCK/UNLOCK TABLES不支持,以及锁函数GET_LOCK(), RELEASE_LOCK()…
(4).查询日志不能保存在表中。如果开启查询日志，只能保存到文件中。
(5).允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。如大型的LOAD DATA操作。
(6).由于集群是乐观的并发控制，事务commit可能在该阶段中止。如果有两个事务向在集群中不同的节点向同一行写入并提交，失败的节点将中止。对 于集群级别的中止，集群返回死锁错误代码(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
(7).XA事务不支持，由于在提交上可能回滚。
(8).整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
(9).集群节点建议最少3个。
(10).如果DDL语句有问题将破坏集群。
==========================================
在这篇文章中，我们将看到不同的MySQL高可用性解决方案，并且检查它们的优势与不足。
高可用性环境为数据库必须保持可用性提供大量的好处。高可用性数据库环境是跨多台机器共同部署的一个数据库，其中任何一个都可以假定数据库的功能。通过这种方式，数据库将不会有“单点故障”。
这儿有很多HA策略和解决方案，那么如何在无数选项中选择最好的解决方案。首先你要考虑的第一个问题是：你要解决的问题是什么？答案归结为冗余、扩展和高可用性，这些并不一定都一样！
- 在灾难事件中需要数据的多个副本
- 需要增加读/写的吞吐量
必须尽量减少停机时间
当你规划你的数据库环境时，你重要的是要记住CAP定理的应用。CAP定理将问题分成三个类别：一致性、可用性和分区容忍性。从这三个中，你可以选择任意两个，并牺牲第三个。
- 一致性。所有节点同时看到相同的数据。
- 可用性。每个请求不管成功或者失败都有响应。
- 分区容忍性。尽管任意分区会导致网络故障，但系统仍继续运作。
无论你选择何种解决方案，它应该最大限度的保持一致性。问题是，虽然MySQL复制是伟大的，它本身并不能保证所有节点的一致性。总有潜在的数据不同步，因为事务可能会在故障转移中丢失或由于其他原因。Galera-based集群如Percona XtraDB集群是以认证为基础，来防止这种情况发生！
数据丢失
你应该问自己的第一个问题是：我能承受丢失数据吗?
这通常取决于应用程序。应用程序应该检查事务中的状态码，以确保他们数据不丢失。然而，很多人却不这样！那么，后果是它有可能在故障转移期间丢失事务。在故障转移时，简单的复制方案会有丢失数据的可能性
不一致的节点是另一个问题。如果没有冲突检测和有效的解决方案，则不一致的节点是不可避免的。一个解决方案是运行pt-table-checksum，并经常跨复制节点检查不一致的数据。另一个选择是使用一个Galera-based分布式集群，如Percona XtraDB集群，来认证过程。
避免单点故障
看你的系统是什么？或者是任何站准备干预失败？对于复制，看看MHA和MySQL协调器。两者都是来执行一个副本故障转移的伟大工具。还有其他。
对于Percona XtraDB集群，故障转移通常更快，但它并不是适用于每个案例的完美解决方案。
我能承受丢失事务？
很多MySQL DBA担心设置innodb_flush_log_at_trx_commit到1为ACID Compliance和sync_binlog，但使用复制没有一致性检查！这在逻辑上是一致的吗？通过认证Percona XtraDB集群保持一致性。
冲突检测与解决方案
所有的解决方案都必须有一些冲突检测和解决方案。Galera的认证过程遵循以下方法：
- 事务继续作为正常节点，直到达到提交阶段。
- 更改收集到一个writeset中。
- Writeset发送到所有节点进行认证。
- PKs是用来确定writeset是否可以应用。
- 如果认证失败，writeset下降，事务回滚。
- 如果它成功，事务提交和writesets被应用到所有的节点。
- 所有的节点将在每一次事务中都会做出同样的决定，因此确定。
我想做故障转移或分布式系统？
另一个重要考虑因素是是否应该有一个故障转移或分布式系统。故障转移系统在一段时间内运行一个实例，并且当出现问题时，“故障转移”将到另一个实例中。一个分布式系统在同一时间内运行多个实例，并且处理不同的数据。
- 故障转移陷阱：
- 故障转移系统监控检测失败的节点和移动服务在其他地方是否可用
- 故障转移需要时间！
- 分布式系统：
- 分布式系统最小化故障转移的时间
另一个问题是：你的故障转移应该自动还是手动?
- 利用手动故障转移
- 手动故障转移的主要优点是，人类通常可以做出更好的决定是否有必要做故障转移。
- 系统很少能让它完美，但他们可以关闭！
- 利用自动故障转移
- 更多的9由于最小化中断
- 不需要等待一个DBA执行
进一步的问题是如何快速使故障转移发生？显然，它发生的速度越快，潜在数据丢失的时间就越少。
- 复制/MHA/MMM
- 取决于需要多长时间来等待副本事务完成之前发生故障转移
- 通常约30秒
- DRBD
- 通常15至30秒
- XtraDB集群/ MySQL集群
- VERY 快速故障转移。通常小于1秒取决于负载均衡器
你有多少9是真的需要的？
“9”测量的精度是为了如何完善系统的一个标准。当涉及到“多少个9”，“每个9的数量级是更准确的。99.99是4个9，而99.999是5个9。
每个管理者一直都会回答多少个9的问题，“尽我所能。“这听起来不错，但现实是需要权衡！许多应用程序可以忍受几分钟的停机时间。下面的表显示了对每个9相关的宕机时间 ︰
我需要进行大规模的读和/或写操作？
当在看你的环境时，重要的是要了解你的工作负载。到底你的工作量沉重的原因是由于读取还是写入或者二者都有？选择你的HA解决方案，最重要的是要知道你读取或写入的规模：
- 规模读取
- 大多数解决方案提供从多个节点读取或副本的能力
- MHA，XtraDB集群，MySQL集群和其他都非常适合
- 规模写入
- 很多人错误地通过写入 XtraDB Cluster 中的多个节点来尝试规模写入，最终导致冲突
- 其它人尝试主主复制也是有问题的
- 这一点可能是关于MySQL集群最好的解决方案
配置新节点呢？
万事皆三
XtraDB集群，尝试每件事物有三个。如果你跨越数据中心，它有三个数据中心。如果你的节点是在一个交换机上，尝试有三个交换机。
XtraDB集群至少需要三个集群中的节点。由于投票的原因奇数是首选。忘掉在故障期间试图与只有两个数据中心保持群集。你最好做一个DR网站。试图通过在两个数据中心来忘记自定义权重。
有多少数据中心?
知道有多少数据中心参与你搭建的环境是一个关键因素。运行多个数据中心会影响你采用 HA 解决方案。
如果我只有一个数据中心呢？你可以获得保护单个失败的节点或者更多，这取决于集群大小。如果你有两个数据中心，你或许应该考虑作为DR解决方案的第二个数据中心。当使用Galera-based集群如XtraDB集群时，有三个或更多的数据中心是最健壮的解决方案。
如何进行故障恢复计划？
灾难恢复计划在HA环境中是至关重要的。确保DR节点(s)可以处理交通，即使在最小的性能水平。
- 从XtraDB集群复制到一个DR网站
- 异步复制从XtraDB集群到单个节点
- 异步复制从XtraDB集群复制拓扑
- 从集群XtraDB异步复制到另一个XtraDB集群
需要什么存储引擎？
尤其是现在，还有大量的存储引擎可用于数据库环境。为了你的HA解决方案，你应该使用哪一个？你的解决方案将帮助你确定可以使用哪些存储引擎。
- 不依赖于存储引擎。适用于所有的存储引擎
- XtraDB集群。需要InnoDB。支持MyISAM 是实验性的，并不应在生产中使用
- MySQL集群。需要NDB存储引擎
负载平衡器的选择
负载平衡器提供了一种手段，将你的工作量分布到您的环境资源中去，以免在任何一个特定点造成瓶颈。以下是一些负载平衡选项：
- HAProxy
- 开源软件解决方案
- 不能读和写。如果这是一个前提，这个应用程序需要去使用它！
- F5 BigIP
- 典型的硬件解决方案
- MaxScale
- 可以读/写拆分
- 弹性负载均衡器(ELB)
如果群集重新启动，会发生什么?
为了更改应用，某些更改要求集群被重新启动。例如，更改参数组的参数值仅适用于群集后重新启动的群集。群集可能也由于电源中断或其他技术故障而重新启动。由于电源中断或其他技术故障，集群也可以重新启动。
- 断电在单个数据中心可能会导致问题
- XtraDB集群为自动启动可以进行配置
- 在所有节点同时失去权力时，可能不总是工作。当服务器正在运行时，grastate.dat文件显示了序号 1
- 幸存的重新启动
- 如果节点是关机重启或其他此类过程，对系统管理员很有帮助
- 正常关机设置正确的序号
需要能够读取后写入吗？
异步复制跨节点并不能保证数据的一致视图。XtraDB集群提供了因果读取。副本将等待该事件用于处理其他查询，保证一致的跨节点读取状态。
如果做很多数据加载呢?
在过去，这是传统的智慧，在这样的场景中使用复制的XtraDB集群。MTS对数据分布在多个模式下有所帮助，但不适合所有的情况。XtraDB集群现在是一个可行的选择，因为我们发现了一个错误，在Galera不能正确地拆分大事务。
对Split Brain采取预防措施
脑裂发生在集群的节点划分，通常由于网络信号，其会形成两个或两个以上的节点新的和独立的集群。XtraDB集群配置进入无主状态，并拒绝接受。一个更新的设置与XtraDB集群将允许脏读取非主节点
我的应用程序需要高并发吗？
新方法来复制允许并行线程(XtraDB集群已经开始)，如多线程服务器(MTS)。MTS允许复制多个SQL线程都有自己的中继日志。由于无法信任SHOW SLAVE STATUS获得中继日志位置，它通过Percona XTRABackup安全使GTID备份。
有限的内存？
一些分布式解决方案比如MySQL集群需要大量的内存，即使基于文件表。一定要适当地计划。XtraDB集群工作更像是一个独立的节点。
我的网络有多稳定？
网络是没有100%的可靠。一些“网络问题”是由于外部因素导致的，如系统资源争用(特别是在虚拟机)。网络问题导致不恰当的故障转移问题。使用局域网段XtraDB集群跨WAN来减少网络流量。
结论
做出正确的选择取决于：
- 知道你真正需要的！
- 知道你的选择。
- 了解你的约束！
- 了解每种解决方案的优缺点。
- 设置正确的期望值！
================================
什么是高可用
高可用指的是通过尽量缩短因日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性
导致不可用的可能因素
- 服务器磁盘空间耗尽
- 性能糟糕的SQL
- 表结构和索引没有优化
- 主从数据不一致
- 人为的操作失误
- ……….
如何实现高可用
- 建立完善的监控和报警系统
- 对备份数据进行恢复测试
- 正确配置数据库环境（从服务器建议只读）
- 对不需要数据进行归档和清理
- 增加系统的冗余，保证系统发生不可用时尽快的恢复
- 避免存在单点故障
- 主从切换和故障转移
如何避免单点故障
- 利用SUN共享存储或DRDB磁盘复制解决mysql单点故障
利用多写集群或NDB集群来解决mysql单点故障
- NDB很少使用在生成环境中
- 如果内存不足，NDB集群的性能就会非常差
利用mysql主从复制来解决单点故障
- 主服务器切换后，如何通知应用新的主服务器的IP地址
- 如何检查MYSQL主服务器是否可用
- 如何处理从服务器和新主服务器的复制关系
MMM架构介绍
MMM的主要作用
监控和管理mysql的主主复制拓扑，并在当前的主服务器失效时，进行主和主备服务器之间的主从切换和故障转移等工作
MMM的提供了什么功能
- MMM监控主从复制健康情况
- 在主库出现宕机时进行故障转移并自动配置其他从服务器对新主服务器的复制
- 如何找到从库对应的新的主库日志中的同步点
- 如果存在多个从库出现数据不一致的情况，如何处理
- 提供了主，写 虚拟IP，在主从服务器 出现问题时，可以自动迁移虚拟IP
MMM部署所需资源
MMM部署步骤
- 配置主主复制 和主从同步集群
- 安装主从节点所需要的支持包
- 安装和配置MMM工具包
MMM工具的优点
- 使用Perl语言开发并完全开源
- 提供了读写虚拟IP，使服务器角色的变更对前端应用透明
- 在从服务器出现大量主从延迟，主从链路中断时，可以把这台服务器上的读的虚拟IP，漂移到集群中其他正常的服务器上
- MMM提供了从服务器的延迟监控
- MMM提供了主数据库故障转移后，从服务器对新主服务器的重新同步功能
- 很容易对发生故障的主数据库重新上线
MMM工具的缺点
- 发布时间比较早，不支持MYSQL新的复制功能（只支持是基于日志点的复制）
- 注：基于gtid的复制可以保证日志不会重复在slave服务器上被执行
- 对于mysql5.6后所提供的多线程复制技术也不支持
- 没有读负载均衡的功能
- 在进行主从切换时，容易造成数据丢失
- MMM监控服务存在单点故障
MHA架构介绍
MHA的提供了什么功能
- 监控主数据库服务器是否可用
- 当主DB不可用时，从多个从服务器中选举出新的主数据库服务器
- 提供了主从切换和故障转移功能
MHA的主从切换过程
- 尝试从出现故障的主数据库保存二进制日志
- 从多个备选从服务器中选举出新的备选主服务器
- 在备选主服务器和其他从服务器之间同步差异二进制数据
- 应用从原主DB服务器上保存的二进制日志
- 提升备选主DB服务器为新的主DB服务器
MHA配置步骤
- 配置集群内所有主机的SSH免认证登录
- 安装MHA-node软件包和 MHA-manager软件包
- 建立主从复制集群
- 建立MHA管理节点
- 使用
masterha_check_ssh和masterha_check_repl对配置进行检验
MHA工具的优缺点
- 同样是由Perl语言开发的开源工具
- 可以支持GTID的复制模式
- MHA在进行故障转移时，更不容易产生数据丢失
- 同一个监控节点可以监控多个集群
- 需要编写脚本或借助第三方工具来实现虚拟IP的配置
- MHA启动后只会对主数据库进行监控
- 需要基于SSH免认证配置，存在一定安全隐患
- 没有提供从服务器的负载均衡功能
读写分离和负载均衡介绍
进行mysql主从复制配置的一个主要目的，是为了分担主库的读负载
为什么要读写分离呢？写负载是不能分担的，只能在主库操作，而读操作既可以在主库也可以在从库。
读写分离的方式
程序实现读写分离
- 优点： 由开发人员决定什么样的查询在从库执行，因此比较灵活
- 优点：由程序直接连接数据库，性能损耗比较少
- 缺点：增加了开发的工作量，是程序逻辑更加复杂
- 缺点：人为控制，容易程序错误
通过数据库中间件实现
- mysql-proxy（一直没有稳定版本）
- MaxScale (比较好)
由中间件实现读写分离的优缺点
- 由中间件根据查询语法分析，自动完成读写分离
- 对于程序透明，对于已有程序不用做任何调整
- 由于增加了中间层，所以对查询效率有损耗（有的达到50%）
- 对于（延迟）敏感业务无法自动在主库执行
如何实现负载均衡
- LVS
- Haproxy
- MaxScale
- F5（硬件）
9655
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
