一、概述
MySQL的集群方案有多种，按照实现途径可以分为MySQL官方和第三方。
1）官方实现方式包括：主从方式、一主多从方式、cluster集群方式等。
2）第三方实现方式包括：MMM（双主多从）方式、MHA（多主多从）方式、Galera Cluster（多主结构）方式等。
二、MySQL官方实现
1. 主从方式-MySQL Replication
…
原理
写在master，读在slave。
通过重放binlog实现主库数据的异步复制。即当主库执行了一条 sql 命令，那么在从库同样的执行一遍，从而达到主从复制
的效果。在这个过程中， master 对数据的写操作记入二进制日志文件中(binlog)，生成一个 log dump 线程，用来给从库的 i/o 线程传 binlog。而从库的 i/o 线程去请求主库的binlog，并将得到的 binlog 日志写到中继日志（ relaylog）中，从库的 sql 线程，会读取 relaylog 文件中的日志，并解析成具体操作，通过主从的操作一致，而达到最终数据一致。
…
目的
实现数据的多点备份（没有故障自动转移和负载均衡）。
…
优势
相比于单个MySQL，优势有：
- 从master写数据，从slave读数据，可以起到读写分离的作用，多个从数据库可以做负载均衡。
- 可以在某个数据库中暂时中断复制进程，来备份数据，从而不影响主数据的对外服务（如果在master上执行备份，需要让master处于readonly的状态，意味着write请求需要阻塞）。
相比于各个集群方案来说，优势有：
- 主从复制是MySQL自带的，无需借助第三方。
- 数据被删除，可以从binlog中恢复。
- 配置较为简单方便。
…
劣势
- slave库需要从binlog获取数据并重放，与master库写入数据存在时间延迟，slave库的数据总是滞后于master库。
- 对master库与slave库之间的网络延迟要求较高，若网络延迟太大，将加重第1点的滞后，造成最终的数据不一致。
- 单一的主节点挂了，将不能对外提供写服务。
…
应用场景
这种方式在日常业务中，读操作多于写操作。
…
搭建实现
安装MySQL，安装完成后，需要对配置文件进行配置。
1）配置主机
a）打开/etc/mysql/mysql.conf.d/mysqld.cnf里的log-bin和server-id=101。
$sudo vim /etc/mysql/my.cnf //不同版本，配置文件位置可能不一样
添加 server-id, log-bin
修改并开启：bind-address=0.0.0.0
b）然后启动MySQL：sudo /etc/init.d/mysql restart
c）进入MySQL后，创建一个Replication用于与slave同步数据。
mysql > create user replication@'%' identified by '123456';
mysql > grant all privileges on *.* to 'replication'@'%' identified by '123456' with grant option;
mysql > show master status;
这里的mysql-bin.000001文件用于同步数据，Position为位置偏移量。
2）配置从机
从机的配置数据需要与主机的配置对应。
a）对于从机，不需要开启log-bin，但需要开启server-id=100。
b）然后启动MySQL：sudo /etc/init.d/mysql restart
c）设置master_ip，binlog，pos，master_port，master_use，master_password。
mysql > change master to master_host='192.168.189.133', master_port=3306, master_user='replication', master_password='123456', master_log_file='mysql-bin.000001', master_log_pos=380;
d）启动从机：mysql > start slave
e）查看从机状态：mysql> show slave status\G
如果看到下图中的Running为Yes，说明主从已经开始同步工作了。
2. 一主多从-MySQL Fabirc
问题引出：一主多从方式，主机出现问题应该怎么办？
…
原理
依旧是一主多从的结构，在MySQL Replication基础上，增加了故障检测与转移，自动数据分片功能。
MySQL Fabirc只有一个主节点，区别是当主节点挂了以后，会从从节点中选择一个来当主节点。
…
优势
相比于各个集群方案来说，优势有：
- 主从复制是MySQL自带的，无需借助第三方。
- 数据被删除，可以从binlog中恢复。
- 主节点挂了以后，能够自动从从节点中选择一个来当主节点，不影响持续对外提供写服务。
…
劣势
- slave库需要从binlog获取数据并重放，与master库写入数据存在时间延迟，slave库的数据总是滞后于master库。
- 对master库与slave库之间的网络延迟要求较高，若网络延迟太大，将加重第1点的滞后，造成最终的数据不一致。
- 该集群方式为2014年5月份推出的产品，数据库资历较浅，应用案例不多，网上各种资料相对较少。
- 事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
- 节点故障恢复30秒或更长（采用InnoDB存储引擎的都这样）。
3. cluster集群-MySQL Cluster
问题引出：主机宕机了，有些数据没有传到slave应该怎么处理？
…
原理
该方式为多主多从结构。MySQL分为2层，一层是mysql shell（每一个对应的IP地址），包含网络、SQL语句的解析、优化等。下一层是存储引擎。
Cluster多出了一层NDB存储引擎。
每一集群中可能有多个机器，每一个节点就是NDB节点，它们之间会进行同步，相当于每一段管理一段数据，没有所谓的主从。
…
优势
相比于各个集群方案来说，优势有：
- 主从复制是MySQL自带的，无需借助第三方。
- 高可用优秀，可达99.999%的可用性，可以自动切分数据，能跨节点冗余数据（其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能会被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性）。
- 可伸缩性优秀，能自动切分数据，方便数据库的水平拓展。
- 负载均衡优秀，能自动切分数据，方便数据库的水平拓展。
- 多个主节点，没有单点故障的问题，节点故障恢复通常小于1秒。
…
劣势
- 架构模式和原理很复杂。
- 只能使用存储引擎 NDB ，与平常使用的 InnoDB 有很多明显的差距。比如在事务（其事务隔离级别只支持 Read Committed，即一个事务在提交前，查询不到在事务内所做的修改），外键（虽然最新的 NDB 存储引擎已经支持外键，但性能有问题，因为外键所关联的记录可能在别的分片节点），表限制上的不同，可能会导致日常开发出现意外。
- 作为分布式的数据库系统，各个节点之间存在大量的数据通讯，比如所有访问都是需要经过超过一个节点（至少有一个 SQL Node 和一个 NDB Node）才能完成，因此对节点之间的内部互联网络带宽要求高。
- Data Node 数据会被尽量放在内存中，对内存要求大，而且重启的时候，数据节点将数据 load 到内存需要很长时间。
三、第三方实现
1. MMM-双主多从方式
MMM （ Master Replication Manager for MySQL）是双主多从结构， MMM 是在 MySQL Replication的基础上，对其进行优化。 这是 Google 的开源项目，使用 Perl 语言来对 MySQL Replication做扩展，提供一套支持双主故障切换和双主日常管理的脚本程序，主要用来监控 mysql 主主复制并做失败转移。
MMM(Master-Master replication manager for Mysql)是一套灵活的脚本程序，用来监控和故障切换，管理mysql Master-Master复制的配置 (同一时间只有一个节点是可写的)。
两个主机共用一个虚拟IP，外部在与MySQL交互的时候，只需要与虚拟IP进行交互，具体内部与哪个master交互，不确定。
MMM主要的功能通过三个脚本实现：
1）mmm_mond
监控进程，负责所有的监控工作，决定和处理所有节点角色活动。
2）mmm_agentd
运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。
3）mmm_control
一个简单的脚本，提供管理mmm_mond进程的命令。
注意：这里的双主节点，虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热。
…
优势
相比于各个集群方案来说，优势有：
- 自动的主主 Failover 切换，一般 3s 以内切换备机。
- 多个从节点读的负载均衡。
…
劣势
- 无法完全保证数据的一致性。如主 1 挂了， MMM monitor 已经切换到主 2 上来了，而若此时双主复制中，主 2 数据落后于主 1（即还未完全复制完毕），那么此时的主 2 已经成为主节点，对外提供写服务，从而导致数据不一。
- 由于是使用虚拟 IP 浮动技术，类似 Keepalived，故 RIP（真实 IP）要和 VIP（虚拟 IP）在同一网段。如果是在不同网段也可以，需要用到虚拟路由技术。但是绝对要在同一个 IDC机房，不可跨 IDC 机房组建集群。
2. MHA
MHA（ Master High Availability）是多主多从结构， MHA 是在 MySQL Replication 的基础上，对其进行优化。 这是日本 DeNA 公司的 youshimaton 开发，主要提供更多的主节点，但是缺少VIP（虚拟 IP），需要配合 keepalived 等一起使用。
要搭建MHA，要求一个复制集群中必须最少有3台数据库服务器，一主二从，即一台充当master，一台充当master，另外一台充当从库。
…
优势
相比于各个集群方案来说，优势有：
- 可以进行故障的自动检测和转移。
- 具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性。
…
劣势
- MHA 架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入 SQL Proxy。但无论如何都需要改动代码。
- 关于读负载均衡可以使用 F5、 LVS、 HAPROXY 或者 SQL Proxy 等工具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可，建议使用 LVS。
3. Galera Cluster
Galera Cluster 是由 Codership 开发的 MySQL 多主结构集群，这些主节点互为其它节点的从节点。不同于 MySQL 原生的主从异步复制， Galera 采用的是多主同步复制，并针对同步复制过程中，会大概率出现的事务冲突和死锁进行优化，就是复制不基于官方 binlog 而是 Galera复制插件，重写了 wsrep api。 异步复制中，主库将数据更新传播给从库后立即提交事务，而不论从库是否成功读取或重放数据变化。这种情况下，在主库事务提交后的短时间内，主从库数据并不一致。 同步复制时，主库的单个更新事务需要在所有从库上同步 更新。换句话说，当主库提交事务时，集群中所有节点的数据保持一致。
对于读操作，从每个节点读取到的数据都是相同的。对于写操作，当数据写入某一节点后，集群会将其同步到其它节点。
…
优势
相比于各个集群方案来说，优势有：
- 多主多活下，可对任一节点进行读写操作，就算某个节点挂了，也不影响其它的节点的读写，都不需要做故障切换操作，也不会中断整个集群对外提供的服务。。
- 拓展性优秀，新增节点会自动拉取在线节点的数据（当有新节点加入时，集群会选择出一个 Donor Node 为新节点提供数据），最终集群所有节点数据一致，而不需要手动备份恢复。
…
劣势
- 能做到数据的强一致性，毫无疑问，也是以牺牲性能为代价。
四、MySQL同步到Redis
- 同步方式1
业务实现，先把数据写到MySQL，再把数据写到redis。
func()
{
write_to_mysql();
write_to_redis();
}
-
同步方式2
只写到MySQL，MySQL同步数据到redis。
采用MySQL的UDF：对表设置触发器，当表增删改数据时，触发回调，回调UDF用户定义的函数。限制与数量不多，性能也不怎么样。
-
同步方式3
MySQL通过binlog同步（与主从同步方法是一样的）。
做一个中间件，相当于从机，然后把数据写到redis。
组件组成：mysqlslave，redisclient
