CAP定理是分布式系统理论的基石。 当然，围绕它的争议并没有平息：其中的定义并不规范，也没有严格的证明……然而，坚定地站在日常常识™的立场上，我们直观地了解到该定理是正确的。
唯一不明显的是字母“P”的含义。 当集群被划分时，它决定是在达到法定人数之前不响应，还是返回可用的数据。 根据此选择的结果，系统被分类为 CP 或 AP。 例如，Cassandra 可以采用任何一种方式，甚至不取决于集群设置，而是取决于每个特定请求的参数。 但如果系统不是“P”并且分裂了，那又怎样呢？
这个问题的答案有些出人意料：CA集群不能分裂。
这是一个什么样的簇，不能分裂？
这种集群的一个不可或缺的属性是共享数据存储系统。 在绝大多数情况下，这意味着通过 SAN 连接，这限制了能够维护 SAN 基础设施的大型企业使用 CA 解决方案。 为了让多个服务器处理相同的数据，需要集群文件系统。 HPE (CFS)、Veritas (VxCFS) 和 IBM (GPFS) 产品组合中提供此类文件系统。
甲骨文RAC
真正应用集群选项首次出现于 2001 年 Oracle 9i 的发布。 在这样的集群中，多个服务器实例使用同一个数据库。
Oracle 可以使用集群文件系统和它自己的解决方案 - ASM（自动存储管理）。
每个副本都有自己的日记。 事务由一个实例执行并提交。 如果实例发生故障，幸存的集群节点（实例）之一会读取其日志并恢复丢失的数据 - 从而确保可用性。
所有实例都维护自己的缓存，相同的页面（块）可以同时位于多个实例的缓存中。 此外，如果一个实例需要一页并且该页位于另一个实例的缓存中，则它可以使用缓存融合机制从其邻居获取该页，而不是从磁盘读取。
但是，如果其中一个实例需要更改数据，会发生什么情况？
Oracle的奇特之处在于它没有专门的锁定服务：如果服务器想要锁定一行，那么锁定记录直接放在锁定行所在的内存页上。 由于这种方法，Oracle 成为单体数据库中的性能冠军：锁定服务永远不会成为瓶颈。 但在集群配置中，这种架构可能会导致大量的网络流量和死锁。
一旦记录被锁定，实例就会通知所有其他实例，存储该记录的页面具有独占保留。 如果另一个实例需要更改同一页上的记录，它必须等到该页的更改被提交，即将更改信息写入磁盘上的日志（并且事务可以继续）。 也可能发生这样的情况：一个页面会被多个副本顺序更改，然后当将该页面写入磁盘时，您必须找出谁存储了该页面的当前版本。
跨不同 RAC 节点随机更新相同页面会导致数据库性能急剧下降，甚至导致集群性能低于单个实例的性能。
Oracle RAC 的正确使用方法是对数据进行物理分区（例如使用分区表机制），并通过专用节点访问每组分区。 RAC的主要目的不是水平扩展，而是保证容错。
如果节点停止响应心跳，则首先检测到该心跳的节点会在磁盘上启动投票过程。 如果此处未注明丢失的节点，则其中一个节点将承担数据恢复的责任：
- “冻结”丢失节点缓存中的所有页面；
- 读取丢失节点的日志（重做）并重新应用这些日志中记录的更改，同时检查其他节点是否具有正在更改的页面的更新版本；
- 回滚待处理的事务。
为了简化节点之间的切换，Oracle提出了服务的概念——虚拟实例。 一个实例可以提供多个服务，并且服务可以在节点之间移动。 为数据库的某个部分（例如一组客户端）提供服务的应用程序实例与一个服务一起工作，当某个节点发生故障时，负责数据库的这部分的服务将移动到另一个节点。
IBM 纯交易数据系统
DBMS 集群解决方案于 2009 年出现在 Blue Giant 产品组合中。 从意识形态上讲，它是并行系统综合体集群的继承者，构建在“常规”设备上。 2009 年，DB2 pureScale 作为软件套件发布，2012 年，IBM 提供了一款名为 Pure Data Systems for Transactions 的设备。 不应将其与 Pure Data Systems for Analytics 混淆，后者只不过是更名为 Netezza。
乍一看，pureScale架构与Oracle RAC类似：同样，多个节点连接到一个公共数据存储系统，每个节点运行自己的DBMS实例，拥有自己的内存区域和事务日志。 但是，与 Oracle 不同的是，DB2 有一个由一组 db2LLM* 进程表示的专用锁定服务。 在集群配置中，该服务被放置在一个单独的节点上，在Parallel Sysplex中称为耦合设施（CF），在Pure Data中称为PowerHA。
PowerHA 提供以下服务：
- 锁管理器；
- 全局缓冲区高速缓存；
- 进程间通信领域。
为了将数据从 PowerHA 传输到数据库节点并返回，需要使用远程内存访问，因此集群互连必须支持 RDMA 协议。 PureScale 可以通过以太网使用 Infiniband 和 RDMA。
如果节点需要一个页面，并且该页面不在缓存中，则该节点会请求全局缓存中的页面，并且只有当该页面不存在时，才从磁盘中读取该页面。 与 Oracle 不同，请求仅发送至 PowerHA，而不发送至相邻节点。
如果实例要更改一行，它将以独占模式锁定该行，并以共享模式锁定该行所在的页面。 所有锁都在全局锁管理器中注册。 当事务完成时，节点向锁管理器发送消息，锁管理器将修改的页复制到全局缓存，释放锁，并使其他节点的缓存中的修改页无效。
如果修改的行所在的页已经被锁定，那么锁管理器将从进行更改的节点的内存中读取修改的页，释放锁，使其他节点的缓存中的修改页失效，并将页锁提供给请求它的节点。
“脏”，即已更改的页面可以从常规节点和 PowerHA（废弃）写入磁盘。
如果其中一个 pureScale 节点发生故障，则恢复仅限于故障时尚未完成的那些事务：已完成事务中该节点修改的页面位于 PowerHA 上的全局缓存中。 该节点在集群中的一台服务器上以精简配置重新启动，回滚挂起的事务并释放锁。
PowerHA 在两台服务器上运行，主节点同步复制其状态。 如果主 PowerHA 节点发生故障，集群将继续使用备份节点运行。
当然，如果通过单节点访问数据集，集群的整体性能会更高。 PureScale甚至可以注意到某个区域的数据正在由一个节点处理，然后与该区域相关的所有锁都将由该节点在本地处理，而无需与PowerHA通信。 但是，一旦应用程序尝试通过另一个节点访问此数据，集中式锁定处理就会恢复。
IBM 对 90% 读取和 10% 写入的工作负载进行的内部测试（与实际生产工作负载非常相似）显示几乎可以线性扩展至 128 个节点。 遗憾的是，测试条件并未公开。
HPE NonStop SQL
Hewlett-Packard Enterprise 产品组合还拥有自己的高可用性平台。 这是 NonStop 平台，由 Tandem Computers 于 1976 年向市场发布。 1997 年，该公司被康柏收购，康柏又于 2002 年与惠普合并。
NonStop 用于构建关键应用程序 - 例如 HLR 或银行卡处理。 该平台以软件和硬件复合体（设备）的形式交付，其中包括计算节点、数据存储系统和通信设备。 ServerNet 网络（在现代系统中 - Infiniband）既用于节点之间的交换，又用于访问数据存储系统。
该系统的早期版本使用彼此同步的专有处理器：所有操作均由多个处理器同步执行，一旦其中一个处理器出错，它就会关闭，第二个处理器继续工作。 后来，系统切换到传统处理器（首先是MIPS，然后是Itanium，最后是x86），并且开始使用其他机制进行同步：
- 消息：每个系统进程都有一个“影子”双胞胎，活动进程定期向其发送有关其状态的消息； 如果主进程失败，影子进程从最后一条消息确定的时刻开始工作；
- 投票：存储系统有一个特殊的硬件组件，它接受多个相同的访问，并且仅当访问匹配时才执行它们； 处理器不是物理同步，而是异步操作，并且仅在 I/O 时刻比较其工作结果。
自 1987 年以来，关系型 DBMS 一直在 NonStop 平台上运行 - 首先是 SQL/MP，后来是 SQL/MX。
整个数据库分为多个部分，每个部分负责自己的数据访问管理器（DAM）进程。 它提供数据记录、缓存和锁定机制。 数据处理由与相应数据管理器运行在同一节点上的执行服务器进程执行。 SQL/MX 调度程序在执行程序之间划分任务并聚合结果。 当需要进行商定的更改时，将使用TMF（事务管理工具）库提供的两阶段提交协议。
NonStop SQL 可以对进程进行优先级排序，以便长时间的分析查询不会干扰事务执行。 然而，其目的恰恰是处理短交易，而不是分析。 开发者保证NonStop集群的可用性达到五个“九”的水平，即每年停机时间仅为5分钟。
SAP-HANA
HANA DBMS (1.0) 的第一个稳定版本于 2010 年 2013 月发布，SAP ERP 软件包于 XNUMX 年 XNUMX 月切换到 HANA。 该平台基于购买的技术：TREX 搜索引擎（列式存储搜索）、P*TIME DBMS 和 MAX DB。
“HANA”一词本身是缩写，即高性能分析设备。 该 DBMS 以代码形式提供，可以在任何 x86 服务器上运行，但是，仅允许在经过认证的设备上进行工业安装。 HP、Lenovo、Cisco、Dell、Fujitsu、Hitachi、NEC 提供的解决方案。 某些 Lenovo 配置甚至允许在没有 SAN 的情况下进行操作 - 公共存储系统的角色由本地磁盘上的 GPFS 集群扮演。
与上面列出的平台不同，HANA 是内存 DBMS，即主数据映像存储在 RAM 中，只有日志和定期快照写入磁盘以便在发生灾难时进行恢复。
每个HANA集群节点负责自己的部分数据，数据映射存储在一个特殊的组件——Name Server中，位于协调器节点上。 节点之间的数据不重复。 锁定信息也存储在每个节点上，但系统有一个全局死锁检测器。
当 HANA 客户端连接到集群时，它会下载其拓扑，然后可以根据需要的数据直接访问任何节点。 如果一个事务影响单个节点的数据，那么它可以在该节点本地执行，但如果多个节点的数据发生变化，发起节点联系协调节点，协调节点打开并协调分布式事务，使用分布式事务提交它。优化的两阶段提交协议。
协调器节点是重复的，因此如果协调器发生故障，备份节点会立即接管。 但如果有数据的节点发生故障，那么访问其数据的唯一方法就是重新启动该节点。 通常，HANA 集群会维护一个备用服务器，以便尽快重新启动其上丢失的节点。
来源： habr.com