bitsCN.com
mysql cluster的高可用性 - 1
使用mysql cluster，能达到99.999的高可靠性，在这一章节，主要介绍一些基本概念：
Network Partitioning
在一个mysql集群中，如果几个节点之间网络出问题了，mysql cluster能决定哪些节点应该继续提供服务。比方有两个Node Group共四个节点：SN1, SN2，SN2, SN4。
SN1和SN2在Node Group1, SN3和SN4在Node Group2。如果{SN1, SN3}与{SN2, SN4}失去联系，那么他们中的任何两个都拥有完整数据，都能对外提供服务。为了数据完整性，我们必须隔离一半。根据配置，一个或者几个管理节点能够提供仲裁，帮助我们选择哪一对节点继续存活。假如我们配置了两个管理节点（MGM1, MGM2)都能提供仲裁服务，我们要避免以下这样的配置：
路由器1： MGM1, SN1, SN3
路由器2: MGM2, SN2, SN4
如果你有这样配置，路由器1与路由器2之间出了问题，而MGM1, MGM2都能仲裁，那么有可能两边都在对外提供服务。结果你懂的。
Synchronous Replication: 同步复制。
这比较好理解，在同一个Node Group内部，事务提交为two-phase commit，而且是同步的。每个数据节点内的数据都同步复制到另一个节点上。MySQL Cluster 配置通常至少有 2 个全部数据的副本，存放在不同主机上。为避免整体系统故障，系统会根据可配置的频率在磁盘上定期保存事务日志和检查点文件。如果某个节点发生故障，至少有另一个数据节点存储着相同的信息。
注意:同步复制只是内存的复制,对于mysql cluster来说，他可能还没有写到硬盘（与Checkpoint和Redo, UNDO log相关）。如果同一个Node Group同时下电，那么我们就可能丢数据。Mysql cluster的数据一致性是说我们几乎没有两个节点同时over，所以我们进行部署时最好不要同一个Node Group的data node在同一个机架。
Failure Detection 错误检测。
通常有两种错误，communication loss 和 heartbeat failure。一是通讯丢失,可以通过tcp,共享内存等方式在各存储节点之间通讯来侦测节点是否正常这种方式是最快的故障检测方式,
二是心跳失败,通讯丢失的检测方法在某些特殊情况下无效,例如磁盘故障等问题.所有的存储节点通过组成一个环路,每个节点向下一个节点发送心跳信号,如果下一个节点没有收到心跳信号,则认为上一个存储节点故障,并依次向下下个节点广播此故障信息
Logging:
正常情况下，不管什么类型的数据库，都会有日志，它包含所有的insert/update/delete。在系统出现故障的时候我们用它来辅助恢复数据库。
Local Checkpoints:
Redo log是一个环形日志文件，随着数据库的操作，redo log也在增长，如果不及时清理的话，log空间很快就会用光，我们需要及时地把snapshot image写到disk，然后把redo log的tail指针向前挪。NoOfFragmentLogFiles用来控制redo log的大小，TimeBetweenLocalCheckpoints控制cluster local checkpoint的频率。这儿的Time并不指时间，而是指操作的个数，它是以指数形式增长的，比方20是4M的写操作，但是21就是8M。
Global Checkpoints:
Mysql cluster是一个in-memory数据库，为了性能的关系，事务都是先同步到内存，然后后面写log。GlobalCheckpoints就是每隔一段时间TimeBetweenGlobalCheckpoints，我们把一组提交的事务写到disk。Global Checkpoint就是定时将Redo log写到disk。
Global Checkpoint是写Redo log，Local Checkpoint是截Redo log的尾。
Local check需要时间，为了能够恢复的时候LCP image与LCP开始时间完全一致，mysql cluster引入Undo log。
System Recovery 系统恢复：
当恢复的时候，LCP image是LCP stop点的数据，我们执行undo log使系统回退到LCP start点。然后执行Redo log到Global checkpoint点。
跨地域复制 — 跨地域复制使节点能镜像到远程数据中心以便进行灾难恢复
限制
不支持磁盘上的持续提交。提交将被复制，但不保证在提交时会将日志写入磁盘。
不能在线增加或舍弃节点（此时必须重启簇）
