More Related Content Similar to OceanBase-破解数据库高可用难题 Similar to OceanBase-破解数据库高可用难题 (20) OceanBase-破解数据库高可用难题8. 集群的高可用
NNooddee 3 3
DataBase
Instance
InfiniBand: 40Gbit/s
Latency: 1us
v.s.
Ethernet: 250 us
InfiniBand: 40Gbit/s
Latency: 1us
v.s.
Ethernet: 250 us
NNooddee 1 1
DataBase
Instance
OOSS
DataBase
Instance
NNooddee 2 2
DataBase
Instance
DataBase
Instance
OOSS
DataBase
Instance
OOSS
SShhaareredd S Stotoraraggee
DDaatataBBaassee F Filieless
高端存储
高档服务器
12. 高可用集群++主备复制
Redo
Stream
Redo
Stream
NNoodde e1 1
DataBase
Instance
OOSS
DataBase
Instance
SShhaareredd S Stotoraraggee
NNoodde e2 2
DataBase
Instance
OOSS
SShhaareredd S Stotoraraggee
IDC-1 IDC-2
NNoodde e2 2
DataBase
Instance
OOSS
DataBase
Instance
DDaatataBBaassee F Filieless
NNoodde e1 1
DataBase
Instance
OOSS
DataBase
Instance
DataBase
Instance
DDaatataBBaassee F Filieless
太贵了!!
18. PPaaxxooss
"Time, Clocks, and
the Ordering of Events
in a Distributed
System"
Byzantine generals
Paxos
LaTeX
2013 ACM Turing
Award
24. 分布式选举基本原理
Paxos 协议的基本要求
成员不说假话( 非拜占庭式)
单个成员说话不自相矛盾:投票给A 了,就不能再投票给
B
任何修改需要多数成员同意:多个成员投票的同步
单个成员说话不自相矛盾
对投出的票进行持久化?
记住自己在一个lease 周期内的投票( 分布式选举)
重启后一个lease 周期内不投票
多个成员投票的同步
有协调者(leader)
无协调者?
25. 多个成员投票的同步
问题
系统刚启动或者原leader 异常lease 过期后,选举
leader 的时候,各个参与者的投票时间各不相同,每个参
与者收到选票的时间各不相同
投票后,参与者在一轮lease 周期内不得再次投票(“ 不得
自相矛盾” )
已有方案
各个参与者在发起投票时, 延迟某个随机时间
(100ms~300ms) ,最早发起者通常成为新的leader
时序逻辑与选举逻辑紧密耦合、业务规则难以融入选举中
容易出现选举失败(election split),下次选主要等Lease过期!!
29. 无主选举时序分析
接接收收预预投投票票接接收收投投票票接接收收广广播播
T1: 预投票T2: 投票T3: 计票&
广播
Step 3 :接收选票, T3 时刻计票,得票过半者
成功并广播
投票到达时间:[T2-Tdiff×2 ,T2+Tdiff×2+Tst=T3]
Step 4 :接收新任leader 广播并在T4 时刻结
束选举
新任leader 广播到达时间: [T3-
Tdiff×2 ,T3+Tdiff×2+Tst=T4]
选举耗时Telect=T4-T1=Tdiff×6+Tst×3
T4: 选举结
束
30. LLeeaassee及无主选举周期
T1: 预投票T2: 投票T3: 计票&
T1
接接收收预预投投票票接接收收投投票票接接收收广广播播
广播
T4: 选举结
束
Tlease Tlease Tcycle TT4 cycle
时钟偏差Tdiff=100ms ,网络单程传输Tst=200ms
选举耗时Telect=Tdiff×6+Tst×3=1200ms
扩展的选举耗时Telect2=Telect+200=1400ms
Tlease=4×Telect2=5600ms ,从TT11 开始
无主选举周期Tcycle=5×Tlease=7000ms
31. WWhhyy TTccyyccllee >> TTlleeaassee ??
接接收收预预投投票票接接收收投投票票接接收收广广播播
T1: 预投票T2: 投票T3: 计票&
5 个成员C1~C5 选举
广播
T1 时刻开始选举,选出新leader
C1
T4 时刻C2~C5 未收到C1 新任
leader 广播
Tcycle 时刻C2~C5 重新开始选举,选
出新leader C4
违背了“不自相矛盾”的要求
T4: 选举结
束
C
2
C
1
C
3C
5
C
4
Clien
t
T1
Tlease Tlease Tcycle TT4 cycle
33. 选举协议的鲁棒性
可能双主( 脑裂)
无主选举:若Tdiff > (Telect2+T3-T1)=2200ms
自动监控: A 在Ta 时刻发包, B 在Tb 时刻收到,则: -
2*Tdiff <= Tb-Ta <= 2*Tdiff + Tst
Tlease Tlease
Tcycle Tcycle
T1 T3
Leader
Tlease
Leader
Tlease
37. 分布式CCAAPP难题
Any networked shared-data system can
have at most two of three desirable
properties:
consistency (C) equivalent to having a single
up-to-date copy of the data;
high availability (A) of that data (for
updates); and
tolerance to network partitions (P).
如果发生了网络分区,高可用性和数据一致性不
可兼得
38. 投票协议
分布式投票和选举协议,以不可靠成员提供可靠服务
多数( 超过半数) 成员可用则服务可用
协议本身比较复杂,但基本原理并不复杂
1.成员不说假话( 非拜占庭式)
2.单个成员说话不自相矛盾
3.任何修改需要多数成员同意
基本做法
通常选出一个leader 作为协调者,但任何修改仍然需要多
数成员同意
Leader 在lease 时间内有效, lease 延长需多数成员同
意
39. 日志按事务顺序同步
DB1
DB2
DB3
主库执行事务,写磁盘,发送给备库,但不提交
备库按事务commit 顺序应答主库
收到#5 及之前的事务日志,未收到#6 号事务日志,但收
到#7,#8 号事务日志,只应答到#5
优点:备库日志中间不会有空洞,实现相对简单
缺点:对网络抖动和服务器性能抖动的抵抗能力较弱,事
务可能偶尔“顿住”
41. 按事务顺序同步--故障恢复((11..22))
故障恢复: 1. 日志最新者为主, 2. 事务日志到达超
半数的库,3.恢复过程中不对外服务
Case 1:DB1故障
空事务
Case 1.2:DB1未恢复,DB2成为主库
DB1
DB2
DB3
恢复过程可能被打断
未决事务:原主库(DB1) 最后未同步的若干事务
若原主库参与恢复,则未决事务被commit ,否则未决事
务被回滚
45. 有主选举::连任
接接收收预预投投票票接接收收投投票票接接收收广广播播
T1: 预投票T2: 投票T3: 计票&
广播
T4: 选举结
束
Tlease Tlease Tcycle TT4 cycle
Leader 连任
T1
1. 预投票:L1( 当前Leader) 在T1 时刻发起连任申请
2. 投票:成员收到leader 连任申请后在T2 时刻投票
3. 计票& 广播: T3 时刻计票,得票超过半数则选举成功并
广播,否则选举失败( 将在lease 过期后进入无主选举)
4. 选举结束:接收选举成功广播并在T4 时刻结束选举
46. 有主选举::改选
接接收收预预投投票票接接收收投投票票接接收收广广播播
T1: 预投票T2: 投票T3: 计票&
广播
Tlease Tlease Tcycle TT4 cycle
Leader 改选
T1
1. 预投票: L1( 当前Leader) 在T1 发起改选leader 为
L2 的申请
2. 投票:成员收到leader 改选申请后在T2 时刻投票
3. 计票& 广播: T3 时刻L1 计票,若L2 得票超过半数则
L1 卸任并广播( 含旧新leader) ,否则选举失败( 将在
lease 过期后进入无主选举)
4. 选举结束:接收选举成功广播(L2 收到广播后立刻把自己
设置为leader) ,在T4 时刻结束选举
T4: 选举结
束
47. 连任//改选时机
TTlease lease TT TT1
4
cycle cycle Lease 从T1 时刻起,共m×Telect2(m>=4)
Leader 自身扣除lease 的最后一个Telect2
Leader 在lease 开始后2×Telect2 时刻发起连任/ 改
选
Editor's Notes 开场白:
串场
个人介绍
分层:互联网服务的可用性要求&lt;数据库的可用性要求
提问:哪种故障最频繁?
Availability vs reliability
统计周期很重要
故障频率-》可靠性
提问:哪种统计周期的要求更高?
冗余
Oracle Exadata
纠错码,RAID等
No SPOF
镜像数据量大
距离限制,通常部署在一个IDC中
实现冗余的手段是复制,复制的问题是如何保证一致性;进而在保证一致性的情况下提供最大可用性。
日志以事务为单位
Group commit
光纤100km/ms rtt
贵!主机宕机可用性,备机宕机,网络隔离情况下写不可用
需要多各个模块进行说明
通过云计算技术实现容错和故障恢复
银行转账的例子
分布式投票
调侃Lampson
Barbala Liskov
1. 十二届全国人大一次会议举行第四次全体会议代表在投票
2. 阿富汗总统选举
程序有bug,就可能说假话,导致协议失败
什么时候记不住自己一个lease周期内的投票?
后面有反例说明,如果不遵守“一轮lease后才可再次投票”的规则,可能出现双主
时序逻辑与选举逻辑紧密耦合:因为没有“协调者”,谁先发起选举谁就有可能被选为主
T1时刻:预投票,即每个成员广播自己的“投票权重”
T2(&gt;T1)时刻:投票,即每个成员向收到的“投票权重”最大者投票
T3(&gt;T2)时刻:计票&广播,即统计选票,得票过半者当选新任leader并向所有成员广播
T4(&gt;T3)时刻:选举结束(成员接收到新任leader广播)
如何确定T1?且听下文分解
从T1到T2:网络传输延迟、时钟误差
Tst=200ms=&gt;rt=400ms
杭州到美国RT:正常150ms,绕行香港时185ms (如中美直通专线异常会绕行中-港-美,需要增加35ms左右)。再极端点拥塞的话,那延迟会到250ms甚至丢包。
leader自己不使用最后一个Telect2
为什么不能在选举失败T4后立刻再选举?为什么Tcycle&gt;Tlease?
为什么不能在选举失败T4后立刻再选举?为什么Tcycle&gt;Tlease?
Leader监控到自身与多数选举者时钟错位,则终止自身的leader角色
到目前为止我们分析了Paxos投票协议,接下来看OceanBase多机群使用Paxos投票协议
任何数据复制方式不可突破的理论结果
选举:通过投票实现;投票:不只用于选举
DB1的最后两条事务是否提交?要看具体情况
空事务投票完成后系统才可继续服务。为什么要写空事务?请看下回分解。
为什么要写一条空事务?