【Day 17】分散式资料库 High Availability 初探

对於分散式资料库的高可用性，
在前面【Day 3】分散式系统模型、容错、高可用的後段已经提过衡量的标准、服务不能用等於$$$飞走等，
这篇整理 3 大可达成 HA 的 replication 架构：single-leader / multi-leader / leaderless
以及收集目前常见的 HA 实作（尽量啦，就还没开始工作），也就是一些备援机制，以有个初步认识。

但还是比较着重於基础知识，毕竟每个 HA 方案的实作都有大量的细节，
不太可能研究完或是能够很简单的分为一类。

本篇会使用 leader / follower 代替歧视性字眼

使用 leader follower 是为了与前面的分散式系统课程保持一致。
我会避免使用 Master Slave 等用词，以支持这些正名运动。
何况我们有那麽多可以使用的替代词！
虽然确实已经用习惯、行之有年，可能会有人说「干嘛那麽敏感？」
但我希望多花一点心力，转换成没有歧视意味的用词，让这个世界多一分善意。
况且，会觉得没关系的人，都只是刚好，过得太幸福而已。

1. single-leader

这边定义 leader 为可被读写，
follower 只能提供读。
leader 决定处理 write request 的顺序，follower 跟随 leader 的决定。
希望减少歧义。

synchronous vs asynchronous

一个 write request 传给 leader 时：

• sync: 只有当 follower 都更新好回报 leader，leader 才跟 client 説这个请求成功

• async: leader 不等 follower 回报就跟 client 説这个请求成功
  显而易见，sync 情况下，可以确保每个 follower 们都有最新的资料，但这不现实，
  毕竟如果 follower 数量一多，就可能要等很久。

• semi-synchronous：让少数 follower synchronous 就好，如果其他 follower 发现自己不是最新的可以跟他们要。

replication 不一致会碰到的问题前面分散式系统的笔记都有提到，
有兴趣建议多看看。

2. multi-leader

• 有多个 leaders 可接受 write request，再同步给其他节点
• 通常是在每个 data center 各自有一个 leader，在同 dc 就像只有一个 leader 一样，但 leader 之间会做 replication。

concurrent write on different leaders?

问题在不同 leaders 出现冲突的时候，他们都已经告诉 client 写入成功，这该怎麽解决？

• 从一开始就避免冲突（conflict avoidance）
  例如如果有两个 clients 都在更动同份文件，就把他们分到同一个 dc
• 解决冲突
  参考 【Day 6】Replication

3. leaderless

• 没有 leader，需使用 Quorum 来确保 client 读写到最新资料
  参考 【Day 7】Replica 的 Quorum 、State machine replication
• 并靠 read repair、anti-entropy 来保持 replicas 一致
  Day 7 也提过。

实例：Amazon Dynamo

MySQL HA 方案

没用过的东西真的不太好写..
主要参考：
常见的高可用MySQL资料库解决方案
一文了解数据库高可用容灾方案的设计与实现

Heartbeat + 共享存储（SAN/NAS）

• heartbeat 侦测到 leader 挂掉时，把共享的存储设备挂载到备用机上
• 成本高、可能 split-brain

MySQL replication

• 注意名词歧异，这里代表 MySQL 的其中一种 HA 方式
• 主要也算 leader/follower，但 MySQL replication 同步的是 log，而 DRBD 是传资料过去

希望没理解错

Heartbeat + DRBD

• Distributed Replicated Block Device（DRBD）：Linux 上的软件，可以说是分散式系统中的 RAID 1，通常是一台 leader + 一台 follower，平常 leader 的更新会传给 follower，只要 leader 挂了，就把服务转到一直有在同步资料的 follower 上。
• heartbeat：确认节点还存活的机制，

MMM（通常做双主架构）

• Master-Master Replication Manager for MySQL（MMM）
• 双主架构：业界流行？两台都可读写，互为 leader / follower。
• 听说是比 DRBD 稍微新的技术

MySQL Cluster

• 设置麻烦？
• 目前理解应该是 leaderless