数据库高可用性

Questions
• 对性能影响较大
– 数据必须被对端接收才能返回
• 被TCP接收即返回 • 被缓冲池接收即返回 • 被日志写入磁盘即返回
• 冷备节点
– 备节点不能读写
• 热备节点
– 备节点只读
• 锁问题难以处理，一般仅支持脏读
最终一致下的Sharding
• 对性能影响较小
– 异常处理逻辑相对复杂
• 备节点数据可能与主节点不同步
每日 16.8小时 8.4小时 5.04小时 3.36小时 1.68小时 50.4分钟 20.16分钟 10.1分钟 5.04分钟 1.01分钟 6.05秒 0.605秒 0.0605秒
如何做到高可用
• 系统设计时在软硬件层面避免SPOF（Single Point Of Failure）
• 自动化监控系统 • 制定紧急切换方案
– 需要强一致的应用程序通过主节点读写 – 或者使W + R > N
• 可能存在数据丢失
– 设置检查点的概念
分片的难点
• 一致性如何保障
– 正常流程中的一致性 – 崩溃恢复的一致性 – 重新选举的一致性 – 对象版本的一致性 – 状态的一致性
• 如何进行心跳检测 • 如何动态增减节点 • 如何选举
每年 36.5天 18.25天 10.96天 7.30天 3.65天 1.83天 17.52小时 8.76小时 4.38小时 52.56分钟 5.26分钟 31.5秒 3.15秒
每月 72小时 36小时 21.6小时 14.4小时 7.20小时 3.60小时 86.23分钟 43.8分钟 21.56分钟 4.32分钟 25.9秒 2.59秒 0.256秒
对等复制集群（P2P）
• Cassandra
Share Nothing + Replication = Sharding
• 数据分片 • 无共享架构 • 每个分区进行数据复制 • 优势
– 高可用 – 线性水平扩张 – 读写分离
• 缺点
– 一致性和高可用的抉择 – 管理复杂
强一致下的Sharding
• 无共享架构 • 优势
– 线性水平扩张 – 并行处理
• 缺点
– 可靠性
数据复制Replication
• 数据复制
– 主被模式（Master/Slave）
• 实现简单 • 读写分离 • 需要重新选取 • 管理相对复杂
– 对等模式（Master/Master）
• 管理简单 • 无重新选举时间 • 实现复杂 • 性能相对较低 • 网络压力大
SequoiaDB – HA
2013/10/07
wenku.baidu.com
高可用
• 高可用（HA）是一种系统，经过专门的设计，从而减少 停机的时间，保证其服务的高度可用性
• 尽可能缩短因日常维护和突发情况所导致的停机时间
计划停机时间
• Scheduled Downtime • 一般由系统维护时所必须的停机时间决定 • 包括
– 升级软件 – 重启 – 备份
非计划停机时间
• Unscheduled Downtime • 计划外的停机时间 • 包括
– 软件崩溃 – 硬件失效 – 网络断连 – 电源故障
SLA
• Service Level Agreements
• 代表一段时间内系 统在线提供服务时 间的比例
可用性% 90 95 97 98 99 99.5 99.8 99.9 99.95 99.99 99.999 99.9999 99.99999
架构层级
• 应用程序 • 中间件 • 数据库 • 网络 • 硬件
传统数据库架构
应用程序 中间件
数据库
SPOF
应用程序 中间件 数据库
Share Disk
应用程序 中间件
数据库
数据库
Share Disk
• 优势
– Workload Balance – 实现相对简单
• 劣势
– 数据的可靠性完全依赖存储 – 可扩展性受限
• 例如
– DB2 for z/OS – Oracle RAC – DB2 PureScale
Share Disk
• 难点
– 一致性 – 全局锁 – 共享内存
• 实现方式
– 对等模式
• Oracle RAC • 缺点：扩展性极差
– 中央调度
• DB2 • 缺点：对初始配置带宽要求高
Share Nothing