分布式数据库系统之【故障恢复与数据复制】

content

1. 故障恢复
2. 数据复制

 
 
 

故障恢复

▍两阶段提交协议中的故障

• 场地故障——在协调者场地/参与者场地发生的故障（下面的5处）
• 通信故障——在发出命令/应答时发生的故障（下面的4处）
  

▍场地故障的恢复

• 协调者场地故障：启动终结协议，选举出一个参与者作为新的协调者；新上任的协调者再次访问所有参与者并作出决定（提交/废弃？）
• 参与者场地故障：写日志和发送报文是两个动作且一前一后，因此故障恢复需要具体情况具体分析（重发？忽视？直接启动终结协议？）

▍通信故障的恢复

1. 丢失P报文：由于参与者收不到预提交命令，而不予应答，最终导致协调者超时，视为废弃
2. 丢失R/A报文：协调者位能收到所有参与者的应答，显然应该视为废弃
3. 丢失C/A报文：参与者收不到协调者的命令，可能进行询问可否重新发送，或者直接启动终结协议
4. 丢失ACK报文：协调者得不到确定，会重新发送C/A报文，要求参与者必须给予应答

 
 
 

数据复制

▍知识点

1. 数据的 一致性 和 可用性 是相互矛盾的，进行合理的数据复制可以对其进行权衡与协调
2. 即使进行了数据复制，物理上产生多个副本，在逻辑上一定依旧保持唯一副本（复制透明性）
3. 数据复制的最大问题是数据不一致问题，这涉及到复制的时机、内容、系统的结构

▍强/弱一致性

• 强一致性： 客户A修改了数据N，客户A、B、C后续的读写操作访问的保证是最新的N
• 弱一致性： 客户A修改了数据N，客户A、B、C后续的读写操作访问的不能保证是最新的N
• 最终一致性： 需要过一段时间(不一致窗口)后才能保证——这是CAP妥协的结果

▍最终一致性的变体

1. 读自己之所写(read-your-writer)：A修改数据后可以保证自己读到最新值，但对于B、C不能保证
2. 会话(session)：客户端与服务端的一整个会话中保证数据一致，建立的新会话不能保证
3. 单调读(monotonic read)：如果A读了某个数据的值，那么可以保证A不会读到该数据更早的值
4. 单调写(monotonic write)：可以保证A的写操作一定按顺序完成，这很重要，因为写操作会发生覆盖

▍同步复制 / 异步复制

• 同步复制——所有节点同时更新。优点是高一致性；缺点是频繁通信与速度问题
• 异步复制——主节点更新，从节点在之后的某个时刻更新。优点是高可用性；缺点是可能读到过时数据

▍对象复制 / 事务复制

• 对象复制——传输的是数据值本身
• 事务复制——传输的是对数据值的操作

▍主从复制 / 对等复制 / 级联复制

• 主从复制——主副本的改变传播到从副本
• 对等复制——无主副本，副本改变在彼此之间等同传播
• 级联复制——类似于“三角结构”，主从+从从对等

 
 
 
 
 
 
 
 
 
 
 
 

$More$