SequoiaDB高可用的原理是什么？

1
包括；主要和次要结构以及集群架构；了解著名的RAFT算法；而最重要的是，红杉分布式数据库是如何实现一致性的，如何保证在集群环境下数据不丢失。

2

数据库高可用技术回顾

数据库系统存储着IT系统的业务数据，可以说是IT系统的大脑。数据库系统的可用性基本上决定了IT系统的可用性。如果数据库系统宕机，整个IT系统就会停止。即使数据库损坏，业务数据可能会丢失，造成巨大的经济损失。

传统的数据库系统，如Oracle、DB2、SQL Server、MySQL等，都是为单机环境设计的。通常的架构是服务器加磁盘阵列。在生产环境中，即使使用非常可靠的小型机和高端的磁盘阵列，也不能保证数据库系统会出现服务器宕机/断电/网络故障/磁盘阵列故障等问题。也就是说，数据库系统在运行过程中出现故障是肯定的。那我们该怎么办呢？ 0101训练出来的IT“攻城狮”脑子也比较直。如果某个网络出现故障，请添加另一个网络；如果一台服务器出现故障，则添加另一台服务器；如果一个磁盘阵列和一条数据出现问题，则添加另一个磁盘阵列和一条数据。 《攻城狮》：“我们的口号是消除单点故障，确保数据库24/7可用。”总理：“又需要更多的钱了！”。

经过“攻城狮”的实践，传统数据库的高可用分为三种架构：冷备架构/热备架构/集群架构。

2.1 冷备架构

冷备架构是主备架构的一种。它添加了冗余网络和服务器，并添加了集群管理软件。 ，如：IBM HACMP，消除网络和服务器单点故障。如图：

主备服务器上均安装了数据库软件和集群管理软件，并且都可以通过SAN网络访问磁盘阵列。正常情况下，主服务器启动数据库进程（备份服务器不启动数据库进程）并访问存储在磁盘阵列中的数据库；主备服务器均启动集群管理软件，监控服务器/网络/IO/数据库进程状态并提供虚拟 IP 地址（在主服务器上）以供应用程序访问。

如果集群管理软件发现主服务器不可用（不可用的情况有很多，比如断电/网络故障/内存CPU故障/无法访问磁盘阵列/数据库进程宕机等.)，它将开始切换过程。备用服务器：“哎呀，终于轮到我了，脚都麻了。”

卸载主服务器上原来挂载的磁盘阵列设备和文件系统。

检测数据库文件系统并将其挂载到备服务器上。

取消主服务器上配置的虚拟IP，并在备份服务器上配置虚拟IP。

在备服务器上启动数据库进程；数据库进程检查数据库日志并重新提交或回滚事务。

备用服务器数据库正常后开始提供服务，切换完成。

优点缺点

优点：架构和配置简单，成本相对较低。

缺点：需要重新挂载文件系统、启动数据库进程、检查数据库日志，切换时间以分钟为单位。如果需要回滚的事务太多，可能需要几十分钟，这对可用性要求比较高。生意难以承受；服务器冷备份浪费服务器资源；只有一个磁盘阵列是单点；只有一份数据副本是一个点。

2.2 双机热备架构

双机热备架构是主备架构的另一种形式。另一种是加入到冷备架构中。磁盘阵列存储数据库数据的额外副本，并启动备用服务器的数据库进程以不断重用主服务器发送的日志。双机热备架构的实现包括es：IBM DB2 HADR、Oracle DataGurd、MySQL Binglog Replication等。

如图：

正常情况下，业务应用访问主服务器通过虚拟IP，主服务器访问自己磁盘阵列中的主数据库；主服务器数据库进程启动日志复制功能，将事务日志复制到备服务器数据库进程；备服务器的数据库进程复用日志到备库完成数据同步。

如果主服务器不可用，集群管理软件将启动切换过程。

集群管理软件取消主服务器的虚拟IP配置，将虚拟IP配置给备份服务器。

服务器数据库进程进行切换操作，从备升级为主。

备机数据库进程完成日志复用后，即可启动prov查找服务。

优点：由于备机数据库进程启动，事务日志不断复用，所以切换时间短（秒级）；数据两份，无需磁盘阵列和数据单点；备服务器一般不能写，但可以提供读服务。缺点：增加磁盘阵列会增加成本。

2.3集群架构

前两种架构解决了高可用问题，但数据库系统只能垂直扩展（增加单台CPU）服务器、内存），无法通过水平扩展（增加服务器）来实现性能扩展。

客户：“我想横向扩展。”

攻城狮：“这对我来说太难了，但我能做到。”

通过在数据库系统（例如IBM DB2 pureScale和Oracle RAC）中提供共享存储功能，多个服务器上的数据库进程可以访问多个服务器上的数据库数据。并行共享存储。

如图：

正常情况下，业务应用可以连接任意数据库服务器，进行数据库读写操作；数据库进程通过并行访问控制实现共享磁盘阵列中数据库的并行读写。

如果一台服务器不可用，连接到该服务器的应用程序将自动重新连接到另一台数据库服务器以实现高可用性。

优点：

切换时间短（秒级）；可实现横向扩展；负载均衡能力；

缺点：

水平扩展能力有限。一般2台服务器的情况较多，3台以上的情况很少。如果服务器太多，性能不但不会提升反而会下降；成本高；配置管理复杂，对DBA要求非常高的数据库管理能力。

3

红杉分布式数据库高可用技术

有朋友可能会问：“传统数据库已经实现了高可用和水平扩展，为什么还要使用分布式数据库？”

攻城狮：“答。”首先，传统数据库的水平扩展能力有限。一般2-3台服务器已经无法应对当前的大数据场景。其次，它们价格昂贵。使用2台小型机、高端磁盘阵列、ORACLE RAC搭建核心数据库，耗资数百万。为了稳定性就好了，但是一个需要处理数百TB数据和几十上百台服务器的数据库系统呢？”

红杉数据库：“轮到我了。无需磁盘碎片整理，无需SAN网络，采用PC服务器+内置磁盘+分布式数据库软件，实现低成本/高可用/高扩展/高性能ance数据库系统。哦耶！”

由于采用PC服务器加内置磁盘，数据一致性和高可用性是分布式数据库设计最重要的方面。这里我们将讨论红杉数据的高可用实现技术红杉数据库的高可用技术原理与RAFT算法类似，是在RAFT选举算法的基础上进行优化，以更好地支持分布式数据库场景。

3.1 Raft算法

RAFT是一种管理复制日志一致性的算法，那么RAFT算法从何而来，在RAFT算法出现之前，Paxos算法在共识算法邻域中占据主导地位，但是显着的Paxos 的缺点是“非常难以理解”，当然也很难实现。2013 年，斯坦福大学的 Diego Ongaro 和 John Ousterhout 设计了 ​​RAFT 共识算法，目标是为了易于理解，发表了论文《寻找可理解的共识算法》。 RAFT算法易于理解和实现，使其在业界得到广泛应用，并且算法的正确性在这些实践中得到了证明。向大人物竖起大拇指，他们的想法是“如果世界不能给我我想要的，那么我就改变世界。”

这里将简单介绍一下RAFT算法的原理，帮助大家了解红杉分布式数据库的高可用。如果想进一步了解RAFT算法，可以参考github上的文章：

https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md

RAFT算法的设计思想是将复杂问题简单化，将一组服务器的数据一致性问题分解为三个小问题。这 3 个小问题包括：

Leader 选举：当现有的 Leader 下线时，新的 Leader 需要选举。eds选举

日志复制：必须从客户端下载leader端接收日志，然后复制到集群中的其他节点，并强制其他节点的日志保持不变和自己的一样。

安全性：Raft 中安全性的关键是状态机安全性：如果任何服务器节点已将某个日志条目应用到其状态机，那么其他服务器节点就无法将不同的指令应用于日志索引位置。

Raft通过解决以上三个小问题，解决了一致性这个大问题。
Raft算法还简化了复制状态机的数量。每个服务器必须处于三种状态：Leader、Candidate 和 Follower。状态转换如图：

Followers只响应其他服务器的请求。如果关注者没有收到任何消息，则成为候选人并开始选举。获得大多数服务器选票的候选人将成为新的 l领导者。领导者仍然是领导者，直到他们失败。

3.1.1 Leader选举

RAFT算法建议一组服务器至少包含5台服务器，这样如果有2台服务器宕机， ,集群仍然可以提供服务。服务器的状态只能是三种状态之一，并且集群中只能有一个leader。集群服务器通过心跳信息了解彼此的状态并触发选举。当服务器程序启动时，它们都具有跟随者状态。只要服务器节点收到来自领导者或候选者的有效 RPC，服务器节点就会继续保持追随者状态。 Leader 周期性地向所有 follower 发送心跳包（即不包含日志条目内容的附加日志条目 RPC）以维护其权限。如果一个follower在一段时间内没有收到任何消息，即选举超时，那么它会认为系统中没有可用的leader并发起选举选举新的领导人。

要开始选举过程，追随者必须首先增加当前的任期编号并过渡到候选人状态。然后，他将并行地向集群中的其他服务器节点发送请求投票的 RPC，为自己投票。候选人将保持当前状态，直到发生以下三种情况之一：（a）他自己赢得选举，（b）另一台服务器成为领导者，（c）一段时间过去并且没有人赢得人。候选人必须获得集群中一半以上服务器的投票才能成为领导者。

3.1.2 日志复制

一旦选举出领导者，他就开始为客户端提供服务。来自客户端的每个请求都包含一条由复制状态机执行的指令。领导者将此命令作为新的日志条目附加到日志中，然后并行向其他服务器发出附加条目 RPC，允许它们复制该日志条目。当日志条目被安全复制时ed（如下所述），领导者将日志条目应用到其状态机并将执行结果返回给客户端。如果追随者崩溃或速度缓慢，或者网络丢失数据包，领导者将反复尝试追加日志条目 RPC（尽管已经回复客户端），直到所有追随者最终存储了所有日志条目。

领导者决定何时可以安全地将日志条目应用到状态机；这样的日志条目被称为已提交。 Raft算法保证所有提交的日志条目都是持久的，并且最终将被所有可用的状态机执行。 当领导者将创建的日志条目复制到大多数服务器时，该日志条目将被提交。 同时，领导者日志中之前的所有日志条目也都被提交，包括其他领导者创建的条目。领导者跟踪将被提交的最大日志条目的索引，索引值为包含在所有未来附加日志 RPC（包括心跳包）中，以便其他服务器最终可以知道领导者的提交位置。一旦跟随者知道日志条目已被提交，它也会将该日志条目应用到本地状态机（按日志顺序）。

日志复制机制表现出一致性属性：只要大多数机器都在工作，Raft 就可以接受、复制和应用新的日志条目；正常情况下，新的日志条目可以通过RPC被复制到集群中的大多数机器上；并且单个慢跟随者不会影响整体性能。

3.1.3 安全性

但是，到目前为止描述的机制并不能完全保证每个状态机执行相同的指令以相同的顺序。例如，一个follower可能会进入不可用状态，而leader已经提交了几条日志条目，然后follower可能会被选举为leader并退出改写这些日志条目；因此，不同的状态机可以执行不同的指令序列。

本节改进了 Raft 算法，在领导者选举过程中添加了一些限制。此限制可确保给定任期的任何领导者都拥有先前任期的所有已提交日志条目。通过添加这个选举限制，我们也有了更明确的提交规则。最后，我们将提供领导者完整性属性的简要证明，并展示领导者完整性属性如何指导复制状态机的正确行为。

选举安全性

Raft采用了更简单的方法，可以保证上一term号已经提交的所有日志条目都被选举。会出现在新的leader中，不需要将这些日志条目发送给leader。这意味着日志条目的传输是单向的，仅从领导者到追随者，并且领导者永远不会覆盖已经存在的条目在它自己的本地日志中。

Raft 使用投票来阻止候选人赢得选举，除非候选人包含所有提交的日志条目。为了赢得选举，候选人必须联系集群中的大多数节点，这意味着每个提交的日志条目必须存在于这些服务器节点中的至少一个上。如果候选者的日志至少与大多数服务器节点一样新（这个新定义将在下面讨论），那么它必须保存所有已提交的日志条目。请求投票RPC实现了这个限制：RPC包含候选人的日志信息，然后投票者将拒绝那些没有自己日志的新投票请求。

Raft通过比较两个日志中最后一个日志条目的索引值和term号来定义谁的日志更新。如果两个日志中的最后条目具有不同的术语编号，则术语编号较大的日志较新。如果两个日志中的最后条目具有相同的术语编号，则较长的日志是最近的。

提交上一个term的日志条目

RAFT中的领导者知道当前term的日志记录只要被存储就可以被提交在大多数服务器上。如果领导者在提交日志条目之前崩溃，则未来的领导者将继续尝试复制该日志条目。 RAFT的leader选举机制保证新leader的日志必须包含最新的term号以及已经复制到大多数服务器上的上一term的最新日志条目，这样新的leader就可以使用日志匹配功能来匹配之前term的日志条目复制到其他服务器以实现间接提交。

3.2红杉数据库的高可用实现

既然分布式数据库必须具备数据库的ACID（原子性、一致性、隔离性、持久性）和分布式事务能力，还需要提供高性能的并行计算能力。场景narios 比 RAFT 算法中提到的要复杂得多。

例如：RAFT算法通过保证日志的顺序来保证各个节点上数据的一致性。然而，在数据库事务并行执行过程中，每个事务可能会生成多条日志记录。日志记录可能是交错生成的，而不是顺序生成的。为了在分布式环境中保持事务的原子性，要求事务产生的所有日志记录都是可追溯的。这些日志必须存在于每个节点上。这样，在事务提交或回滚时，可以在每个节点上保持原子性。事务执行过程中，可能会更新大量数据（批量事务）。在分布式数据库中，不可能等待这些更新操作在主节点上完成后再复制到从节点上。该方法的执行性能非常差。太穷了，无法做生意的需求。红杉数据库的做法是，事务中的每次写操作都会生成一条日志记录。主节点会将这些日志记录复制到从节点进行重做。它不会等到事务提交才开始复制和重做，然后事务提交后，就会在复制组内部实现两阶段提交算法，保证事务的原子性和一致性在复制组中。

另外，RAFT算法中命令提交成功的条件是：集群中大多数服务器都保存有该命令的日志记录。 RAFT算法可以保证集群最终一致，但不能保证集群在某一时刻一致。这种机制在实施集群容灾时会出现问题。例如：在一个由 5 台服务器组成的集群中，3 台服务器位于 A 中心，2 台服务器位于 B 中心。der在中心A，那么A中的3台服务器在同一个网络中。通常情况下，日志复制时间较长。比远程中心B的两台服务器短，也就是说不能保证中心B的服务器保存最新的日志记录。如果A中心发生灾难并且无法恢复，那么B中心服务器的数据将不完整。这种情况对于某些企业（银行账户）来说是不可接受的。红杉数据库的做法是设置写副本数量参数，强制多少个节点保存最新的日志记录，然后复制才会成功。

因此，巨杉分布式数据库在节点选举的实现上对RAFT算法进行了优化，在数据同步/日志复制方面完全开发了自己的算法。在红杉分布式数据库的架构中，主节点对应RAFT算法中的leader，从节点对应follower，且候选人相同； Sequoia数据库的复制日志对应RAFT算法中的日志记录； Sequoia数据库的复制组对应于RAFT算法中的一组服务器。红杉数据库支持集群中的多个复制组，每个复制组可以看成是一组RAFT算法服务器。

巨杉分布式数据库的节点类型分为：协调节点、目录节点、数据节点。其中，多个协调节点的任务是接收命令并将命令分发给目录节点和数据节点。它们本身不保存数据，彼此之间没有关系，因此不需要考虑可用性问题。目录节点实际上是一种特殊的数据节点，其高可用性与数据节点相同。协调节点可以被认为是数据节点复制组的客户端。

Sequoia分布式数据库也sol通过解决三个小问题解决了集群数据一致性的大问题。

3.2.1 节点选举

红杉数据库的复制组可以包含1到7个数据节点，但是如果要提供高可用的复制组内节点数必须大于等于3。每个复制组同时只有一个主节点，其他为从节点。如果是在主选择阶段，每个从节点都可以作为候选节点。红杉数据库也采用同组节点投票的方式来选举Master。获得过半票数的节点成为主节点。

为了保证主选举成功，并且选出的主节点包含最新的数据库日志，红杉数据库在RAFT算法的基础上做了一些优化，特别是在候选节点的资格选择上。

从节点必须具备的条件满足成为候选节点并发起选举请求的条件是：不是主节点、能与自己心跳通信的剩余节点数必须超过一半、自己的LSN（日志序列号）比主节点新其他节点的LSN。主节点上存在复制组，无法自动发起选举请求（可手动切换主节点）。只有当主节点不可用时，从节点才能发起主选举请求。如果集群分裂，例如5个节点分裂成2节点集群和3节点集群，由于网络原因，两个节点之间没有连接。如果当前master节点处于3节点集群中，那么由于这个集群中存活的节点数量大于一半，因此不会发生master选举。如果当前主节点在2节点集群中，主节点会自动降级为从节点，3节点集群会发起主节点选举重选主节点的请求。

当复制组内所有节点都正常时，各个节点会通过共享心跳信息shared-beat来共享状态信息。共享的心跳信息包括：心跳ID、自身起始LSN、自身结束LSN、时间戳、数据组版本号、自身当前角色和同步状态。如图所示：

每个节点维护一个状态共享表，记录节点状态。每隔2秒发送一次sharing-beat来收集响应信息。如果连续两次没有收到响应信息，则认为该节点宕机。节点进程中的ReplReader（复制监听线程）负责接收和发送节点状态信息。

从节点发起主选举之前，会检查共享心跳信息中自身节点的LSN以及其他从节点的LSN。如果其LSN大于或等于其他从节点的LSN，则可以发起吃了一个master选举请求。否则，不启动。

在Master选举中，如果多个候选Slave节点的LSN相同且都发起请求，则会比较各个Slave节点的权重配置参数（权重）。复制组中的每个节点可以单独配置不同的权重，从0到100。数字越大，权重越高。对于LSN相同的从节点，权重较高的节点将成功选举出Master。

如果多个从节点的LSN相同且权重配置相同，则比较这些从节点的节点号。创建节点时，每个节点的节点号不同，节点号较大。获胜者将被成功选出。

从上面可以看出，巨杉分布式数据库在RAFT算法的基础上，优化了master选择流程，增加了权值和节点数判断，使得RAFT算法不会出现。多个节点拥有相同票数来选举 Leader 的情况会导致失败。

下面通过一个简单的例子来描述红杉数据库的主选过程。

如图所示，一个3节点的复制组包括：主节点A、从节点B、从节点C。正常情况下，三个节点通过心跳共享状态信息。如果主节点A由于某种原因出现故障（服务器断电/网络故障/磁盘故障等），它将自动降为从节点，集群将开始重新选举主节点。

两个从节点发现没有收到主节点的心跳信息，则认为主节点宕机了。

从节点B：“哎，主节点挂了，我有机会当老大，我看看，我是从节点，LSN是最新的。嗨，C哥，我的LSN是XXX，我想当老板，你同意吗？”

从节点C：“嘎嘎，老大死了！已经很多年没当大哥了，有点想念。我看看，我是从节点，LSN是最新的，还有机会。你好，B哥，我的LSN是XXX，我想当老大，你同意吗？”

来自节点B：“C哥也想当老大，LSN与矿。你好C哥，我的LSN也是XXX，我的体重是80，我应该是那个吗？”

从节点C：“B哥，对不起，我的体重也是80，我要也成为那个人。我的节点号是1008。”

来自节点B：“C哥的节点号是1008，我的是1006；输了，输了，C哥，你是老大。”

来自节点C：“我给自己投了票，B哥给我的文章投了票。现在是2票，大于3/2+1。这就够了。 B哥您好，我是老大。”

从节点B：“收到，老大。”

Master重选成功后，新的Master节点将通知目录节点更换主节点信息;协调节点会从目录节点同步节点状态信息，并连接到新的主节点；协调节点也可以通过遍历节点来获取新的主节点信息。这样就实现了主节点宕机后的高可用。原主节点A恢复后，自动成为从节点。

3.2.2 日志复制

红杉数据库的日志复制机制与RAFT不同。首先，RAFT算法的日志总是从leader发送到follower，follower之间不交换日志数据；而红杉数据库的日志复制是在源节点（发送日志的节点）和目标节点（请求日志的节点）之间进行的，目标节点主动向源节点请求日志数据。大多数情况下，源节点是主节点，但其他从节点也可以是源节点e个节点，目标节点只能是从节点。其次，在RAFT算法中，如果leader没有follower的日志复制返回信息，则leader会持续向follower发送日志，直到收到返回信息，这就是增量复制；而红杉数据库的数据同步复制可以是增量日志复制，也可以触发全量数据同步。

红杉数据库的日志复制不使用RAFT算法，因为它不适合分布式数据库场景。例如，如果一个从节点宕机了，主节点继续根据RAFT算法向从节点发送日志信息，而日志数据非常大，会占用大量的CPU/内存/网络资源主节点的问题，这是严重的。影响主节点性能，可能造成拥塞；巨山数据数据库采用从节点请求方式。新的日志数据将be只有在从节点状态正常的情况下才会请求，并且会明确给出需要的日志数据。这样不会造成重复发送的问题，并且从节点可以作为源节点。可以大大减少主节点的工作量。另外，由于实际环境中，存储空间有限，数据库中可配置的日志空间也有限，因此红杉数据库的数据同步方式分为日志增量同步和数据全量同步两种方式。如果目标节点要同步的数据包含在源节点的复制日志空间中，则进行增量日志同步；如果数据不再位于复制的日志空间中，则需要完全同步。最重要的是分布式数据库需要支持ACID和事务的能力，其场景比RAFT alg描述的日志复制场景更加复杂正交。 Sequoia数据库采用两阶段提交算法来支持复制，同时兼顾性能和事务一致性。集团内的交易能力。

日志增量同步模式

在数据节点和目录节点中，任何数据的增删改查操作都会写入日志。 SequoiaDB首先将日志写入日志缓冲区，然后异步写入本地磁盘。

每次数据复制都会在两个节点之间进行：

源节点：是包含新数据的节点。主节点并不总是必须是复制的源节点。

目标节点：请求数据复制的节点。

复制过程中，目标节点选择距离自己最近的节点（共享节点状态表包含每个节点的起始LSN和结束LSN，可以用来计算距离最近的节点）本身），然后向其发送复制请求。源节点收到复制请求后，会将目标节点请求的同步点之后的日志记录打包并发送给目标节点。目标节点收到数据包后，会重新处理日志中的所有操作。

节点之间的复制有两种状态：

对等状态（PEER）：当目标节点请求的日志仍然存在于源节点中时日志缓冲区，两个节点处于对等状态

远程追赶状态（RemoteCatchup）：当源节点的日志缓冲区中不存在目标节点请求的日志时，但源节点的日志文件中仍然存在，且两个节点处于远程追赶状态

如果源节点的日志文件中不再存在目标节点请求的日志节点，目标节点进入全量同步状态。

当两个节点处于对等状态时，同步同步请求可以直接从源节点的内存中获取数据。因此，当目标节点选择复制源节点时，它总是会尝试选择距离你当前日志点最近的数据节点，使其包含的日志尽可能位于内存中。

数据全量同步

分区组中，当有新节点加入分区组，或者故障节点重新加入分区组时（故障节点日志版本与其他节点差异过大，超过节点事务日志空间大小；或者故障节点重启后数据不一致），需要全量数据同步，保证新节点与现有节点数据一致节点。

两个节点参与数据全量同步：

源节点：包含有效数据的节点。主节点并不总是同步的源节点。任何位于的从节点与主节点sync可以作为源节点进行数据同步。

目标节点：新加入组或重新加入组的故障节点。同步时，该节点下的原始数据将被丢弃。

当发生全同步时，目标节点会定期向源节点请求数据。源节点将数据打包，作为大数据块发送到目标节点。当目标节点重做数据块中的所有数据时，它向源节点请求新的数据块。

为保证同步时源节点可以进行写操作，如果所有已发送到目标节点的数据页发生更改，它们的更新都会同步到目标节点，以保证所有数据页完全同步过程中更新的数据不会丢失。

同步副本数量

Se中实现数据同步时quoia数据库，为了适应不同的业务场景，可以为每个集合单独设置ReplSize（写操作的同步副本数量）参数。

ReplSize默认值为1，可选值如下：

-1：表示写请求需要同步到复制中的几个活跃节点组在数据库写操作返回响应给客户端之前。

0：表示在数据库写操作向客户端返回响应之前，写请求需要同步到复制组中的所有节点。

1 - 7：表示在数据库写操作向客户端返回响应之前，写请求需要同步到复制组中指定数量的节点。

实际项目中，为了保证数据不丢失，ReplSize需要设置为大于1，或者-1。例如，如果集合的 ReplSizeon设置为2，那么主节点写操作必须等到从节点返回成功后才向协调节点返回成功。这样就保证了如果此时主节点宕机了，至少有一个从节点还坚持了下来。有了成功的日志数据，重新选举master时，这个slave节点必然会根据最新的LSN规则成为候选者，从而保证数据不丢失。

3.3 安全性

为了保证数据不丢失，保证数据安全，红杉数据库的集群一致性算法也做了一些限制选举规则和复制规则。

选举限制

前面提到，在Sequoia数据库中，如果一个节点想要成为候选节点并发起Leader选举请求，则如下必须满足的条件： ：不是主节点，剩余能与自己心跳通信的节点数量必须大于等于e超过一半，并且自身的LSN（日志序列号）比其他节点的LSN更新。这些规则确保新主节点的数据是最新的，并且可以与一半以上的其他节点进行通信。

日志复制限制

红杉数据库在复制组内采用两阶段提交算法来支持事务能力，并使用表配置参数ReplSize（ write Number of replicas) 强制主节点有多少个从节点必须同步成功。通过这些手段，红杉数据库可以保证复制组内节点的数据和事务的一致性/完整性。

在日志复制方面，复制组的主节点会保证每条日志（包含唯一且增量的LSN）能够按照日志复制的规则复制到从节点上。例如，某表的ReplSize参数设置为2，则主节点gu保证至少收到从节点日志复制完成的确认后，向协调节点返回成功，否则返回失败；如果ReplSize设置为-1，则主节点在收到所有活动从节点发送的日志复制成功的确认后，将向协调节点返回成功，否则将返回失败。

在事务完整性方面，红杉数据库在复制组内的两阶段提交事务实现流程如下：

客户端使用 transBegin() 启动事务并发送发送给协调节点，协调节点再发送给主节点执行，主节点会生成唯一的交易ID。

主节点收到第一个写操作（如插入、更新、删除）后，会生成一条日志记录（日志记录中包含事务ID）。该日志记录将是发送给其他从节点，并根据规则（副本数，即使ReplSize设置为1，红杉数据库也必须保证某个从节点在执行事务时保存有事务ID的日志记录）成功。

主节点将继续完成其他操作。任何写操作都会生成一条新的日志记录，并根据复制规则发送到其他从节点并确认成功。

主节点收到transCommit()命令后，将开始第二阶段提交。

主节点首先执行第一阶段，预提交。在此阶段，将生成预提交日志记录并将其发送到从节点，并确保从节点确认收到。

然后主节点执行第二阶段，实际提交（Snd-Commit）。在这个阶段，会生成一条提交日志记录，并发送给从节点执行，并确保从节点成功接收。当这个阶段成功，则整个交易被确认成功，并返回给协调节点成功。

整个事务过程中，如果出现任何违反复制同步规则的情况，则事务无法进行（例如：插入数据时，数据所在表的ReplSize为3）由于某种原因，包括主节点在内的复制组只有2个活动节点，那么插入操作就会失败，衍生事务无法继续），那么事务就会回滚，恢复之前执行的操作。
如果交易过程中主节点宕机，红杉数据库会根据交易的执行情况自动判断是继续提交交易还是在新的主节点成功选举后回滚交易，以解决可疑问题交易问题。

答案关于SequoiaDB高可用原理的问题在这里分享。希望以上内容能够对大家有所帮助。如果您还有很多疑问没有解答，您可以关注行业资讯频道了解更多相关知识。