深度干货 如何兼顾性能与可靠性?一文解析YashanDB主备高可用技术

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 数据库高可用(High Availability,HA)是指在系统遇到故障或异常情况时,能够自动快速地恢复并保持服务可用性的能力。如果数据库只有一个实例,该实例所在的服务器一旦发生故障,那就很难在短时间内恢复服务。长时间的服务中断会造成很大的损失,因此数据库高可用一般通过多实例副本冗余实现,如果一个实例发生故障,则可以将业务转移到另一个实例,快速恢复服务。

  背景

  数据库高可用(High Availability,HA)是指在系统遇到故障或异常情况时,能够自动快速地恢复并保持服务可用性的能力。如果数据库只有一个实例,该实例所在的服务器一旦发生故障,那就很难在短时间内恢复服务。长时间的服务中断会造成很大的损失,因此数据库高可用一般通过多实例副本冗余实现,如果一个实例发生故障,则可以将业务转移到另一个实例,快速恢复服务。

  常见的高可用架构有两种,一种是主备架构,另一个是多活架构。

1.jpg

  

图1 两种常见的高可用架构

  主备架构中,有一个实例是主库,其他实例是备库。主库发送日志给备库,备库通过回放日志来同步主库的数据,一旦主库发生故障,可以选择其中一个备库升主,接管业务。主备架构根据日志类型分两种,物理主备和逻辑主备。

  • 物理主备**:传输物理日志,备库只读,不可执行写业务,比如Oracle Dataguard;

  • 逻辑主备**:传输逻辑日志,备库可以执行写业务,比如MySQL。多活架构中,每个实例都可以执行读写业务,一个实例宕机后,业务可以转移到其他实例。

  多活架构有基于共享存储的共享集群,比如Oracle RAC,也有基于逻辑日志的多活架构,比如MySQL的双主多活。

  YashanDB目前支持物理主备和共享集群两种高可用方案,本文将聚焦于物理主备的高可用介绍。

  主备高可用方案挑战

  主备高可用方案的挑战通常有以下几点:

  • 性能开销:主备高可用方案会对主数据库的性能产生一定的开销,包括增加网络传输、归档IO等资源消耗等。在部署主备环境时,需要权衡可用性和性能之间的平衡,还需要考虑部署成本。

  • 同步延迟:主备数据库之间的数据同步存在一定的延迟,主要由于网络延迟和日志应用的处理时间所导致。延迟会影响备库只读性能,在主库发生故障时,备库中的数据也可能不是最新的。

  • 故障切换:在主备高可用环境中,当主库发生故障时,需要手动或自动进行故障切换,将备库切换为主库。故障切换过程中,需要尽量减少服务中断时间,还要确保数据的完整性和一致性。

  • 数据一致性:主备同步至少要保证最终一致性,如果备库需要支持只读,还要保证备库查询的瞬时一致性。

  YashanDB主备针对上述挑战,做了深度优化,使得主备同步性能和自动切换能力达到极致。下面将介绍YashanDB高性能主备复制,以及自动故障转移的技术解析。

  YashanDB高性能主备复制

  01 整体架构

2.jpg

  

图2 YashanDB物理主备架构图

  YashanDB的物理主备架构如上图所示,左边是主库的组件,右边是备库的组件。

  各组件解释如下:

  • Log Cache:日志缓存。主库上Redo日志会首先写入日志缓存,备库收到Redo日志后也会写入日志缓存。

  • logFlush:日志刷盘线程。将日志缓存里的Redo日志持久化到磁盘。

  • logSend:日志发送线程。依次从日志缓存,Redo文件,归档日志里读取Redo日志,发送给备库。

  • logRecv:日志接收线程。接收来自主库的Redo日志,写入日志缓存。

  • archProc:归档线程。在Redo文件被复用前,将其拷贝为归档日志文件。

  • stbyRcy:备库日志回放线程。依次从日志缓存,Redo文件,归档日志里读取Redo日志,回放Redo日志,更新备库数据。

  • archSvr:归档发送线程。当备库请求归档日志时,主库将归档日志发送到对端。

  • archCli:归档接收线程。当备库出现归档GAP时,系那个主库发起请求,并接收来自主库的归档日志文件。

  02 主备部署

  YashanDB支持一主多备部署,最多可达32个备库。备库可以在线添加,并且一次可以并行添加多个备库。在并行创建备库的过程中,主库只从磁盘读取一次数据,然后将数据转发给多个备库。

  YashanDB还支持级联备库,即备库可以从另一个备库接收Redo日志,无需和主库建立连接。级联备可以减少主库的压力,可用于异地容灾。YashanDB的每个备库可以连接多个级联备库。


3.jpg

  

图3 级联备库

  03 保护模式

  YashanDB主备对数据的保护是基于事务级别的。一个事务提交前,如果这个事务的日志已经在备库落盘,那么该事务就不会在主库故障后丢失。

  为方便用户对数据的保护程度和可用性进行权衡配置,YashanDB提供3种不同的保护模式:

  • 最大性能:主机事务提交无需等待备机收到Redo,备机对主机性能影响最小。该模式下如果主机故障,备机升主后可能丢失数据。

  • 最大保护:主机事务提交前,至少有一个备机将日志刷盘。这种模式能保证数据不丢失,但是对主机性能有影响,并且所有备机都断连后,主机事务将阻塞。

  • 最大可用:在正常情况下,最大可用和最大保护是一样的。如果所有备机断连,会降级为最大性能模式,不阻塞主机事务。

  04 日志发送和接收

  YashanDB在日志发送方面,做了很多优化,来提高日志发送的性能:

  • 优先从日志缓存读取Redo日志,不产生磁盘读IO。主备同步正常的情况下,待发送的Redo基本都在日志缓存里,因此不会对Redo磁盘产生IO争抢。只有当日志缓存里的Redo被淘汰时,才会从Redo文件或归档日志里读取Redo。

  • 日志批量发送,多条Redo一次发送,只回一次ACK(Acknowledgment)。一段时间内产生的Redo日志批量发送,这一批Redo只需要一个ACK,这样可以减少网络交互次数,提高吞吐量。

  • 异步接收备库的ACK。每执行一次Redo日志发送,并不会等待这批日志的ACK,而是异步的接收备库的ACK,不阻塞下一次发送。

  • Redo缓存则发送,不等主库落盘。数据库产生的Redo优先写入日志缓存,然后进行本地刷盘,在本地刷盘的同时,日志发送即可进行,减少了一次等IO的时间。不过这种方式会带来一个问题,就是在主库发生故障后,备库的Redo可能比主库多,这就需要通过一些机制来判断备库的多余Redo,在后面的未决日志这一章节将介绍这个机制。

  • 备库在日志落盘前返回ACK。如果在备库落盘前返回ACK,则性能可进一步提升,但是在主备同时故障的情况下,可能有数据丢失的风险。该模式在大部分场景下能做到数据不丢失,同时性能更好,不过因为在极端场景下有丢失数据的风险,所以仅支持最大可用模式下使用。

4.jpg

  

图4 日志发送与接收流程

  05 归档GAP

  备库停机一段时间后,会落后主库较多Redo文件。

  YashanDB的备库重连后,直接从主库日志缓存接收最新Redo,其余未接收到的Redo,将通过归档日志拉取线程补齐,这部分归档称为归档GAP。

  由于最新Redo是通过日志缓存发送的,所以不会产生额外的Redo磁盘IO,对主库性能影响较小,同时归档拉取线程逐个获取主库归档,可加速备库追赶主库。


5.jpg

  

图5 归档GAP修复流程

  06 未决日志

  在最大保护模式下,主库的Redo日志没有被备库接收前,这部分日志对应的事务提交将阻塞。如果此时主库宕机,备库升主,新主库不包含这部分日志,旧主库降备后,需要将这部分日志回退,这部分日志称为未决日志。

  未决日志可能会回退,其对应的事务不可提交,相应的脏页不能刷盘(如果脏页刷盘后,日志被回退了,就会违反WAL原则)。

  未决日志不能被备库回放,因为主库上可能没有提交对应的事务。

  如果日志被主库和所有同步备持久化,则这部分日志不会被回退,这个日志点称为commit index。主库维护commit index识别未决日志,同时主库会将commit index同步给备库。

6.jpg

  

图6 未决日志场景1

  上图场景中,主备处于最大保护模式,备库还没有收到主库的log 4和log 5这两条日志。虽然这两条Redo日志在主库落盘了,但是如果主库此时发生故障,备库升主,旧主库降备后,这两条日志将会被回退。


7.jpg

  

图7 未决日志场景2

  上图场景中,主库的log 4这条日志已经写入主库的日志缓存,并且被发送到备库,但是主库还没有将log 4落盘。如果主库此时发生宕机重启,主库上不会包含log 4这条日志,备库上这条日志将会被回退。

  07 并行回放

  YashanDB的备库支持并行回放,来提高备库回放Redo的性能。

  备库通过一个协调线程读取和分析Redo日志,然后将Redo按照会话ID哈希分配给后台回放线程,让这些后台线程并行回放Redo。

  并行回放大大提高了回放速率,使得备库Redo不积累,备库查询延迟低,并且故障切换的RTO很低。

  YashanDB的备库并行回放,复现了主库的session执行顺序,可以保证事务瞬时一致性,解决备库读一致性和回放性能难以兼顾的痛点问题。即使主库在高并发业务下,备库查询延迟也可以做到很低。

8.jpg

  

图8 备库并行回放

  自动故障转移技术解析

  当主库发生故障时,需要将某个备库切换为主库,并将业务转移到新的主库上。除了手动执行故障切换,YashanDB还支持自选主、仲裁切换两种方式的自动故障切换。

  01 RAFT自动切换

  YashanDB的自选主切换是基于Raft算法实现的。Raft是一种共识算法,能确保节点故障或网络分区下保持强一致性。

  主备通过心跳检测对方是否存活,主库定期会给所有备库发送心跳,如果备库在超时时间内没有主库的心跳,那么备库就认为主库发生了故障。主库事务提交,要等待多数派节点将Redo落盘,除了主库节点,至少要有节点总数/2(下取整)个备库收到主库Redo 。主库故障,备库心跳超时后,会发起选举投票,如果收到多数派节点的投票,则升为新的主库。投票算法可保证,新主是多数派里Redo最多的,而事务提交要等待多数派落盘,因此新主库一定落盘了所有已提交事务的Redo,不会丢数据。

  Raft的每次选举都会产生一个新的任期(term),在一个任期内,最多只有一个主库。

  Raft将系统中的角色分为Leader、Follower和Candidate。工程上为了提高系统稳定性,加入了PreCandidate角色:

  • Leader:对应于主库,向Follower发送Redo日志;当日志同步到多数派节点上后,通知Follower更新commit index。

  • Follower:对应于稳态下的备库,接受并持久化Leader发送的日志,并回放commit index之前的日志。

  • Candidate:对应于选举中的备库,从PreCandidate到Leader的中间角色。

  • PreCandidate:对应于选举中的备库,从Follower到Candidate的中间角色。

9.jpg

  

图9 Raft节点状态转移图

  如上图所示,数据库启动后都是Follower角色,如果没有收到Leader的心跳,到达超时时间后,会发起预选举。预选举成功后,会增加自己的任期然后发起正式选举,正式选举成功后,就成为Leader,即从备库升为主库。在选举过程中,如果遇到任期比自己高的节点,或者发现当前任期的Leader,则会中断选举,回到Follower角色。

  02 仲裁切换

  Raft至少需要3个节点,不适合一主一备的自动切换,为此YashanDB提供了基于外部组件的一主一备仲裁切换功能。

  yasom是YashanDB的轻量级的数据库管理进程,一般部署在非数据库服务器,可对主备状态进行监控。yasom和数据库之间有个yasagent进程进行代理通信,yasagent部署在数据库所在服务器。

  yasom检测到主库异常后,在满足切换条件的情况下,给备库下发failover命令进行切换。切换条件为yasom和备库都感知不到主库,如果其中任一个能感知到主库,说明主库正常。

10.jpg

  

图10 OM仲裁切换场景

  如上图3种情况,情况1表示主库所在服务器故障,yasom和备库都感知不到主库,可以切换。情况2表示主库进程故障宕机,yasom和备库都感知不到主库,可以切换。情况3表示yasom和主库所在服务器网络异常,但是主库和备库之间网络正常,此时不会切换。

  零丢失模式

  零丢失模式下,只有确定备库不丢失数据的情况下,才可以升主,牺牲一定的可用性,但是不会丢失数据。

  • 主备优先使用最大保护模式,保证数据全部同步到备库。

  • 当备库异常时,yasom将主库切换为最大可用模式,保证数据库可用,不阻塞业务。

  • 主库故障时,如果处于最大保护模式,则yasom进行自动切换。

  • 主库故障时,如果处于最大可用模式,则yasom不会切换,因为有数据丢失的风险,此时需要人工介入。

  脑裂自动修复

  非零丢失模式下,旧主库和新主库的数据可能不一致,旧主库降备后,与新主库发生脑裂。

  yasom发现备库脑裂后,将下发脑裂修复命令,修复备库不一致的数据,使主备复制恢复正常。

  首先找到主备的日志分歧点,然后扫描备库Redo得到分歧点之后修改过的页面,将这些页面的ID发给主库,从主库获取对应页面并覆盖备库本地文件。再以分歧点lsn为基线,将主库上大于该lsn的数据页面发送到备库覆盖,最后将主库分歧点之后的Redo发送到备库,进行回放。回放完成后,主备将正常同步Redo,脑裂修复完成。


11.jpg

  

图11 脑裂修复流程

  总结及未来规划

  在客户实际运用数据库的过程中,性能与业务连续性无疑是最为重要的两大考量因素。尽管主备高可用方案在业界极为普遍,但在真实业务场景中仍面临多重挑战。我们在架构技术与编程实现等方面进行了深入的优化工作,以提升主备部署模式的同步性能及高可用保障。接下来,我们会继续丰富功能和性能,还将在以下几个方面继续打磨和增强:

  • 逻辑主备:主要用于逻辑复制,滚动升级,HTAP场景;

  • 条件故障切换:非网络故障,比如文件损坏,服务器资源异常时自动切换。

目录
相关文章
|
10月前
|
Python
使用pycharm 开发streamlit的项目启动
要在 PyCharm 中配置 Streamlit 环境并调试应用,请按以下步骤操作:1. 确保 PyCharm 配置了 Python 解释器并安装 Streamlit 包(File -> Settings -> Project -> Python Interpreter)。2. 配置调试运行设置(Run -> Edit Configurations,添加 Python 配置并命名)。3. 选择新配置并点击调试按钮启动应用。
915 23
|
8月前
|
移动开发 前端开发 API
React 音频播放器组件 Audio Player
本文介绍如何使用React创建音频播放器组件,涵盖核心功能如播放/暂停、进度条、音量控制和时间显示。通过HTML5 `<audio>` 元素和React的声明式状态管理,实现交互式音频播放。常见问题包括控件不响应、进度条无法更新和音量控制失灵,并提供解决方案。此外,还讨论了浏览器兼容性、异步错误处理和性能优化等易错点及避免方法。
604 123
|
8月前
|
Web App开发 人工智能
UC伯克利:给大模型测MBTI,Llama更敢说但GPT-4像理工男
UC伯克利研究团队推出VibeCheck系统,自动比较大型语言模型(LLM)的输出特征,如语调、格式和写作风格。该系统通过迭代挖掘特征并利用LLM法官量化其实用性,验证结果显示其能有效捕捉模型的独特“vibes”。VibeCheck应用于对话、摘要、数学和字幕生成等任务,揭示了不同模型的行为差异,并在预测模型身份和用户偏好方面表现出色。尽管存在主观性和测试范围有限的局限性,VibeCheck为改进LLM评估提供了新视角。论文地址:https://arxiv.org/abs/2410.12851
208 98
|
7月前
|
人工智能 物联网
ART:匿名区域布局+多层透明图像生成技术,生成速度比全注意力方法快12倍以上
ART 是一种新型的多层透明图像生成技术,支持根据全局文本提示和匿名区域布局生成多个独立的透明图层,具有高效的生成机制和强大的透明度处理能力。
175 8
ART:匿名区域布局+多层透明图像生成技术,生成速度比全注意力方法快12倍以上
|
10月前
|
运维 监控 Cloud Native
一行代码都不改,Golang 应用链路指标日志全知道
本文将通过阿里云开源的 Golang Agent,帮助用户实现“一行代码都不改”就能获取到应用产生的各种观测数据,同时提升运维团队和研发团队的幸福感。
501 146
|
7月前
|
机器学习/深度学习 人工智能 开发框架
《破局之路:跨学科协作研发AI项目的技术与理解破壁》
在AI项目研发中,跨学科协作至关重要,但也面临技术壁垒和理解差异的挑战。不同学科如计算机科学、数学、心理学等各具专长,但工具与术语的差异导致沟通障碍。为解决这些问题,需建立知识共享平台、制定通用沟通规范,并培养复合型人才。通过共同努力,打破壁垒,推动AI技术创新,助力社会发展。
217 14
|
9月前
|
SQL 存储 Oracle
【YashanDB观点】论Oracle兼容性,我们需要做什么
Oracle兼容性是目前国产数据库的关键任务之一,其直接影响到商业迁移的成本和竞争力。
149 8
|
7月前
|
安全 API Go
如何实现和调试REST API中的摘要认证(Digest Authentication)
本文介绍如何实现和调试REST API中的摘要认证(Digest Authentication),涵盖其原理、优势及Java和Go语言的实现示例。摘要认证通过哈希算法处理密码,避免明文传输风险,并使用nonce防止重放攻击,确保数据完整性。文中还提供了Postman、cURL和Insomnia等工具的测试方法,帮助开发者轻松验证API的安全性。总结指出,摘要认证相比基本认证更安全,适合需要高安全性的API应用。
|
7月前
|
存储 传感器 缓存
java变量与数据类型:整型、浮点型与字符类型
### Java数据类型全景表简介 本文详细介绍了Java的基本数据类型和引用数据类型,涵盖每种类型的存储空间、默认值、取值范围及使用场景。特别强调了`byte`、`int`、`long`、`float`、`double`等基本类型在不同应用场景中的选择与优化,如文件流处理、金融计算等。引用数据类型部分则解析了`String`、数组、类对象、接口和枚举的内存分配机制。
192 15