MySQL-MMM

MySQL-MMM工作原理

MMM(Master-Master replication manager for Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。

mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。
mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。
mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。

mysql-mmm的监管端会提供多个虚拟IP（VIP），包括一个可写VIP，多个可读VIP，通过监管的管理，这些IP会绑定在可用mysql之上，当某一台mysql宕机时，监管会将VIP迁移至其他mysql。

在整个监管过程中，需要在mysql中添加相关授权用户，以便让mysql可以支持监理机的维护。授权的用户包括一个mmm_monitor用户和一个mmm_agent用户，如果想使用mmm的备份工具则还要添加一个mmm_tools用户。



MySQL-MMM优缺点
优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。

缺点：Monitor节点是单点，可以结合Keepalived实现高可用，对主机的数量有要求，需要实现读写分离，对程序来说是个挑战。




Mycat的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分
片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。


应用场景
Mycat发展到现在，适用的场景已经很丰富，而且不断有新用户给出新的创新性的方案，以下是几个典型的应用场景：
单纯的读写分离，此时配置最为简单，支持读写分离，主从切换
分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片
多租户应用，每个应用一个库，但应用程序只连接Mycat，从而不改造程序本身，实现多租户化
报表系统，借助于Mycat的分表能力，处理大规模报表的统计
替代Hbase，分析大数据
作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查
询，还可能存在范围查询或其他属性查询，此时Mycat可能是最简单有效的选择


keepalived可以提供双机浮动的vip，类似于一个 layer3,4,5交换机制的软件，3ip层，4tcp层，5应用层交换
作用：检测web服务器的状态。
layer3:keepalived会定期向服务器群中的服务器发送一个icmp的数据包（即我们平时用的ping程序），如果发现某台服务的ip地址没有激活，keepalived便报告这台服务器失效，并将它从服务器群中剔除，
layer5:复杂且占用网络带宽大，，，，，keepalived将根据用户的设定检查服务器程序的运行是否正常，如果与用户的设定不相符，则keepalived将把服务器从服务器集群中剔除
layer4:主要以tcp端口的状态来决定服务器工作正常与否


vip即虚拟ip，是附在主机网卡上的，即对主机网卡尽心虚拟，此ip仍然是占用了此网段的某个ip




Haproxy仅仅，而且专门是一款的用于均衡负载的应用代理。其自身并不能提供http服务
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。
HAProxy 实现了一种事件驱动，单一进程模型，此模型支持非常大的并发连接数

同一客户端访问服务器，HAProxy保持回话的三种方案：

1 HAProxy将客户端ip进行Hash计算并保存，由此确保相同IP访问时被转发到同一真实服务器上。

2 HAProxy依靠真实服务器发送给客户端的cookie信息进行回话保持。

3 HAProxy保存真实服务器的session及服务器标识，实现会话保持功能。










### PXC/Galera Cluster集群优缺点
优点：
1.高可用性。集群多个节点功能平等，提供负载和冗余，避免单点故障
2.强一致性。集群所有节点同步修改数据，真正同步读写，不存延迟。
3.易扩展。增加新节点，只需扔进集群，会自动完成SST全量同步，和后续IST增量同步
缺点：
1.任何更新事务都需要全局验证通过，才会在每个节点库执行。集群性能受限于性能最差的节点
2.galera/pxc集群保证数据一致性，必须所有节点验证通过。多点并发写入，锁冲突严重。
例如：多台同时有写操作，每个更新操作时，都会锁库来验证
3.新节点或延后较大的节点重新加入时，会进行全量拷贝数据SST，作为donor（提供同步文件的节点）的节点在同步过程中无法提供读写，显示状态为donor。完成后的状态为syncd

###当galera cluster集群单个节点或所有节点停机情况分析
单个节点停机
节点停机重启，重新加入集群，通过IST增量同步数据，来保持集群数据的一致性。IST的实现由wsrep_provider_options="gcache.size=1G"参数决定，一般设置为1G。参数大小由什么决定，根据停机时间，若停机一小时，需要确认一小时产生多大的binlog来算出参数大小。
1.1 停机时间过长，部分数据gcache没有，此时该节点SST全量同步数据。
2. 所有节点关闭，应采用轮巡滚动关闭的方式：a节点关闭修复，加回集群；b节点关闭修复，加回集群...
原则就是保持cluster中最少一个成员存活，进行滚动重启。
2.1 集群所有节点都关闭了，没有存活的节点的情况
每个节点数据库关闭后，都会保存最后一个GTID，启动集群时要先启动最后一个关闭的节点，启动顺序和关闭顺序相反。
3. 避免关闭和启动节点时数据丢失
3.1 原则保持cluster集群中最少有一个成员存货，然后进行滚动重启
3.2 利用主从的概念，把一个从节点转化为PXC/Galera集群中的节点

### 常见问题汇总
如果主节点（负责写入的节点）写入过大，apply_cd时间过长，导致数据更新操作时间过长，怎么处理?
Wrep_slave_threads参数配置成cpu的个数或者1.5倍。

脑裂
任何命令执行出现unknown command，表示出现脑裂，集群中任意两个节点间通信的4567端口不通，并且无法对外提供服务。SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";

并发写
如果在集群多个节点进行写/更新操作，有可能同时不同节点update同一行操作时就会出现锁死问题，出现:Error：1213 SQLSTATE:4001.解决：指定更新和写入都在都一个节点操作。

DDL全局锁
采用pt-online-schema-change
只支持innodb引擎，表结构必须要有主键，不然会造成集中每个节点的data page里的数据不一致。
不支持表级锁，即不能lock/unlock tables，使用行级锁

新节点加入加入&故障节点恢复加入集群，此时不能有写操作，不然会导致被写入的那台库DDL死锁。所以需要暂停集群业务写操作，等数据一致后在开启写操作。



1.1提供的特性:

多写，写冲突检测
良好的扩展能力，可动态增删节点，组成员自动管理
组内高可用
确保组内数据最终一致性【重要】(通过分布式协议和分布式recovery机制保证)

1.2组复制的两种模式

在单主模式下，组复制具有自动选主功能，每次只有一个 server成员接受更新。
在多主模式下,所有的 server 成员都可以同时接受更新.

1.3组复制的限制

仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测；
必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set
COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景
目前一个MGR集群最多支持9个节点
不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚
二进制日志不支持binlog event checksum


3.MySQL 组复制实现了基于复制协议的多主更新。
1)复制组由多个 server成员构成，并且组中的每个 server 成员可以独立地执行事务。但所有读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不需要在冲突检测，可以立即提交。

2)换句话说，对于任何 RW 事务，提交操作并不是由始发 server 单向决定的，而是由组来决定是否提交。准确地说，在始发 server 上，当事务准备好提交时，该 server 会广播写入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后会为该事务建立一个全局的顺序。最终，这意味着所有 server 成员以相同的顺序接收同一组事务。因此，所有 server 成员以相同的顺序应用相同的更改，以确保组内一致。

3)组复制使您能够根据在一组 server 中复制系统的状态来创建具有冗余的容错系统。因此，只要它不是全部或多数 server 发生故障，即使有一些 server 故障，系统仍然可用，最多只是性能和可伸缩性降低，但它仍然可用。server 故障是孤立并且独立的。它们由组成员服务来监控，组成员服务依赖于分布式故障检测系统，其能够在任何 server 自愿地或由于意外停止而离开组时发出信号。

4)他们是由一个分布式恢复程序来确保当有 server 加入组时，它们会自动更新组信息到最新。并且多主更新确保了即使在单个服务器故障的情况下也不会阻止更新，不必进行 server故障转移。因此，MySQL 组复制保证数据库服务持续可用。

5)值得注意的一点是，尽管数据库服务可用，但当有一个 server 崩溃时，连接到它的客户端必须定向或故障转移到不同的 server。
这不是组复制要解决的问题。连接器，负载均衡器，路由器或其他形式的中间件更适合处理这个问题。
总之，MySQL 组复制提供了高可用性，高弹性，可靠的 MySQL 服务。


特点
高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；

高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。