OpenGauss是华为基于PostgreSQL内核开发的国产集中式数据库系统，自开源以来社区用户活跃，深受关注。本文简要介绍OpenGauss数据库的基本特性、主要的高可用部署架构，以供参考。
1、OpenGauss集中式数据库特性
1.1 OpenGauss数据库特性
高性能：面向多核架构的并发控制技术结合鲲鹏硬件优化，在两路鲲鹏下TPCC Benchmark达成性能150万tpmc。
高可靠：支持主备同步、异步和级联备机多种部署模式。数据页CRC校验，损坏数据页通过备机自动修复。备机并行恢复，10秒内可升主提供服务。
高安全：支持全密态计算、访问控制、加密认证、数据库审计和动态数据脱敏等安全特性，提供全方位端到端的数据安全保护。
运维管理便捷性：多维性能自监控视图，实时掌控系统的性能表现。
开源开放社区共建：采用木兰宽松许可证协议，允许对代码自由修改、使用和引用。数据库内核能力全开放，开源社区与用户共建数据库。
图1 OpenGauss数据库特性
1.2 PostgreSQL数据库技术特点
支持复杂数据类型：除了常见的数据类型外，PostgreSQL还支持JSON、数组、范围、几何图形、全文搜索等多种复杂数据类型。
多版本并发控制（MVCC）：PostgreSQL使用多版本并发控制来管理事务，每个事务都可以看到一致的快照数据。
复杂查询：PostgreSQL支持复杂查询，包括联接、子查询、窗口函数等，因此能够灵活地查询和分析数据。同时内置了全文搜索功能，能够进行高效的文本搜索和分析。
复制和高可用性：PostgreSQL提供了复制和高可用性解决方案，包括流复制、逻辑复制和自动故障转移。
性能优化工具与度量信息丰富：PostgreSQL数据库中有大量的性能视图，可以方便地定位问题。设计了专门架构和进程用于收集性能数据，既有物理I/O方面的统计，也有表扫描及索引扫描方面的性能数据。
图2 PostgreSQL数据库架构图
PostgreSQL是多进程单线程的架构，如图所示包括客户端进程、后端进程postgres和后台进程。作为一款企业级的数据库，PostgreSQL功能强大并且稳定可靠，相比于Oracle传统的集中式数据库来说，更为轻量级、安装和维护也更为简单，并且在功能上和性能上也满足大部分应用的需求。因此在数据库国产化的技术演变中，使用PostgreSQL数据库或者基于PostgreSQL开源改造的国产数据库也成长起来，像OpenGauss就是基于PostgreSQL技术发展的成功案例。
1.3 OpenGauss数据库与PostgreSQL对比
图3 OpenGauss和PostgreSQL数据库架构对比
执行模型：OpenGauss优化了线程池模型，满足高并发的访问需求
NUMA改造：OpenGauss支持信创服务器的Numa适配，提升服务器的性能
存储引擎优化：OpenGauss支持列存和内存引擎，满足HTAP类业务场景需求
优化器优化：结合实际的应用场景支持CBO对复杂查询场景的优化能力
对比PostgreSQL可以看到，OpenGauss对数据库引擎的性能和架构做了适配性改造，更符合国产化的需求，以满足信创环境下大规模和复杂的数据处理请求。
2、OpenGauss集中式数据库架构
2.1 OpenGauss单节点架构介绍
图4 OpenGauss数据库逻辑架构图
运维管理模块OM（Operation Manager）：提供数据库日常运维、配置管理的管理接口、工具等
数据库管理模块CM（Cluster Manager）：管理和监控数据库系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行。CM提供数据库主备的状态监控、网络通信故障监控、文件系统故障监控、故障自动主备切换等能力。
OpenGauss实例：负责存储业务数据、执行数据查询任务以及向客户端返回执行结果。在高可用架构下通常部署一主多备，并部署在不同的服务器上。
存储Storage：服务器的本地存储，用于数据持久化，支持集中式存储
客户端驱动：负责接收来自应用的访问请求，并向应用返回执行结果。客户端驱动负责与openGauss实例通信，发送应用的SQL命令，接收openGauss实例的执行结果。
cm_agent：部署在数据库每个主机上，用来启停和监控各个数据库实例进程的数据库管理组件。功能包括：1）数据库实例启动和停止时负责拉起和停止本主机上部署的实例进程；2）监控本主机上运行的实例状态并将状态上报发送给CM Server；3）执行CM Server仲裁下发的命令。
cm_server：进行数据库实例管理和实例仲裁的组件。主要功能包括：1）接收各个节点上cm_agent发送的数据库各实例状态；2）提供数据库实例整体状态的查询功能；3）监控实例的状态变化并进行仲裁命令的下发
图5 CM服务组件架构图
2.2 OpenGauss高可用架构
Quorum 模式：基于多数派模式仲裁，选出同步备。当DN分片处于无主场景时，CM在多数派DN redo完成后，选择term和lsn最大的节点(同步备)发送failover升主
DCF（Distributed Consensus Framework）模式：基于Paxos协议的选主模式，该模式下DN自动选主，CM不再进行对DN选主，只负责数据采集，假死检测等。
图6 CM选主仲裁协议
2.2.1 OpenGauss主备复制原理
图7 OpenGauss主备复制原理
WAL：Write-Ahead Logging，也称为XLog，预写日志系统。实现事务日志的标准方法，是指对数据文件（表和索引的载体）持久化修改之前必须先持久化相应的日志。
WAL Receiver：数据库复制时备机创建的一个线程的名称。此线程用于从主机接收数据、命令，并反馈确认信息至主机。一个备机只有一个WALReceiver线程。
WAL Sender：数据库复制过程中，主机接受到备机的连接请求后创建的一个线程的名称。此线程用于发送命令、数据到备机，并从备机接收信息。一个主机可能会有多个WAL Sender线程，每一个WAL Sender线程对应一个备机的一个连接请求。
WAL Writer：数据库启动时创建的一个写Redo日志的线程，用于将内存中的日志写入到持久性设备中。
REDO日志：记录对数据库进行操作的日志，这些日志包含重新执行这些操作所需要的信息。当数据库故障时，可以利用REDO日志将数据库恢复到故障前的状态。
2.2.2 本地1主1备和1主多备架构
图8 OpenGauss数据库本地1主1备和1主多备架构图
OpenGauss数据库在本地AZ内1主1备和1主多备部署，至少保证一个备节点同步复制RPO=0，其它备节点可以采用异步复制的方式。主备节点是等价的，当主节点故障后自动切换到备节点对外提供服务。本地一主多备的高可用架构适合一般的业务系统。
2.2.3 同城双中心高可用架构
图9 OpenGauss数据库生产同城双中心架构
生产和同城双AZ部署，当生产站点故障时能够切换到同城站点继续提供服务，保证业务的连续性。生产和同城站点至少有一个备节点是同步复制，保证RPO=0。同时DN主节点多数派选主或者Paxos协议，两个站点主备节点配置为奇数。另外在应用的竖井式架构中，同城站点只有只读服务，如果想同步读写操作，需要应用交互式访问生产中心的数据库实例。生产同城双中心架构适合于有业务连续性质保障要求的一般重要系统。
2.2.4 多中心高可用架构
图10 OpenGauss数据库1主6备多中心高可用架构
该架构在两地三中心部署，每个AZ保证至少有一个同步复制的备节点，具备异地容灾的能力。但是由于异地和生产站点物理距离的限制，实际上灾备站点配置了同步复制的节点会影响交易的性能，一般在生产环境不建议使用这种部署架构。
2.2.5 多中心流式容灾架构
图11 OpenGauss数据库1主7备多中心高可用架构
这种架构将生产同城站点和灾备站点分为两个独立的集群，灾备站点的集群会选出首备连接主集群的主DN，灾备集群内都以级联备方式连接首备，灾备集群RPO>0。主集群和灾备集群可以选择不同的组网，满足容灾切换的要求，同时也不会影响到应用性能。两地三中心的架构适合系统可靠性高的核心重要业务系统。
2.3 分布式数据库高可用架构对比
图12 分布式数据库多中心高可用架构
应用改造成本低：应用不需要针对分布式进行单元化或者分片等改造，降低了开发成本以及开发难度。
交易链路更短：分布式架构下应用需要经过网关路由等组件，整个交易链路冗长，增加了应用的访问开销。在集中式数据库中，应用直接访问数据库，减少了中间的链路，提升了应用的性能。
分布式事务规避：分布式架构下涉及到跨中心的访问应用通过分布式事务算法保证事务的一致性，数据库内由分布式数据库实现数据的一致性。集中式数据库则规避了分布式访问，所有数据集中存储和访问。
基础设施部署成本：在分布式架构下多个分片和节点意味着更多的服务器（每个分片*N副本），同时计算节点的负载均衡需要额外的网络负载均衡设备实现。在集中式数据库中单个数据库实例满足业务需求，多份副本保证系统可用性，并且不需要额外的网络设备支撑。
数据存储的限制：核心系统分布式数据库单个数据库实例一般部署在PC物理机上，受限于单台服务器的存储限制，存储的数据量是有限制的，随着业务增长存在扩分片的需求。集中式数据库可以使用集中式存储设备，能够支撑更多的数据存储，不用担心数据增长横向扩容对业务的影响。
运维管理复杂性：分布式数据库管理组件和网元架构更为复杂，对运维监控、故障应急、问题定位等日常的运维管理也提出了更高的要求。集中式数据库继承了传统集中式数据库的运维管理经验，和现有的运维监控平台对接更为简便。
当然和分布式数据库对比，集中式数据库存在受限于单台服务器的处理能力不能支撑高并发的业务请求以及集群故障对业务的全局影响等缺点，在具体的应用实践过程中结合实际的业务场景和需求进行统筹分析。
以上是基于OpenGauss国产集中式数据库的高可用架构分析，限于个人理解仅供参考。
参考资料：
http://www.postgres.cn/docs/12/index.html
https://docs.opengauss.org/zh/docs/latest/docs
https://blog.csdn.net/xili2532/article/details/127007987
