1. 项目背景
服务器芯片、操作系统、中间件、数据库都是国外公司产品，存在诸多的底层技术、信息安全、数据保存方式被限制的风险。为了规避技术风险、提升自主可控能力、降低外部依赖，满足监管要求，根据2022年IT工作计划，现启动国产化全栈软硬件信息技术应用创新（信创）试点项目。
羲和Halo提供系统架构设计
2. 方案设计
羲和（Halo）数据库支持透明读写分离架构，整体架构接近Oracle RAC，因而是替换以Oracle为数据底座的系统的理想选择。在持透明读写分离架构中，DLB（Database Load Balancer）充当最终服务者的角色，即应用只跟DLB节点交互，下层的数据库节点对应用是不可见的。DLB节点实现命令的读或者写的识别，当应用发送过来的命令是只读的（如SELECT命令），则DLB节点会将命令发送给任意一个可用的数据库节点。当应用发送过来的命令是写命令（如INSERT或者UPDATE），则DLB节点将这条命令只会发送给主数据库节点。DLB节点是无状态的，因而可以非常容易的实现水平扩展。
主数据库节点，也叫做RW（Read Write）节点，即既接受读请求又接受写请求；从数据库节点，也叫做RO（Read Only）节点，即只接受读请求。主从采用日志同步的方式高效的实现数据的复制。同时主从之间采用2阶段提交协议（2PC）实现分布式事务的原子操作，从而保证主从之间数据的强一致性。
当从节点发生故障时，该节点会被自动剔除出集群，对整个数据库集群无任何影响。当主节点出现故障时，从数据库间采用Raft协议进行选举，选举出一个新的主节点，从而保证整个数据库集群正常工作。
同城灾备中心实施一个灾备库，同时采用羲和数据库独有的分组复制技术，在保证整体集群高效运行的同时保证RPO=0。
在整体架构中，由于写只发生在主节点（RW节点），从而避免了分布式锁的开销。同时由于数据变更是单向的，使得缓存融合也变得更加简单且高效，从而获得比Oracle RAC更优的性能表现，且更易扩展。
3. 实施部署
3.1 高可用部署方案
为了做好本项目，提供的部署方案有两种，分别是高可用部署，读写分离部署方案，用户和集成商可以根据应用模块的数据量，并发数，安全性和可靠性要求进行选择
3.2 高可用部署模式
为保证用户能够7×24小时不间断的访问数据，支撑系统中关键业务的运行，提供了高可用解决方案。可以实现主机宕机之后备机及时接管，保证系统的软硬件出现故障时，系统得以快速恢复使用，及时提供服务。
4. 方案技术原理
Halo Shield是一套自动管理羲和主备数据库的高可用解决方案。该方案包含以下几部分：
4.1 ETCD
ETCD是分布式键值数据库，需要技术节点（最少需要三个节点）来进行Leader选举，一般可以和羲和数据库部署在相同的服务器上，ETCD集群之间会进行心跳检测，当发生网络故障时，节点数少于ETCD集群会不可用，从而避免脑裂现象。
4.2 Patroni
Patroni是流复制创建、管理、监控和自动故障故障转移进程。利用ETCD集群存储、检测Halo主备检点的状态与配置信息，当由于故障使得某个节点无法工作，Patroni会自动侦测节点，并通过ETCD更新节点信息，从而通知所有其他节点。如果该故障节点时主节点，Patroni会自动切换，并重新绑定VIP到新的主节点，从而减少对应用系统的影响。通过连接ETCD对其他节点做心跳检测，当主节点无法更新ETCD中的leader lock，patroni会终止当前节点的Halo数据库，从而避免脑裂。
5. 读写分离集群实施方案
羲和数据库为保证用户能够7×24小时不间断的访问数据，提供了基于WAL日志传输复制技术的读写分离集群管理系统。
采用日志传输技术的集群方案是通过在多台羲和数据库服务器间进行日志传输来实现数据的高可用性，各节点之间的数据在物理上是完全独立的。正常情况下，数据库主服务器(即Master)以活动服务器的身份对外提供数据访问服务，同时数据库备份服务器(即Slave)获取主服务器上的更新日志与主服务器保持数据同步。如果主服务器发生故障，备份服务器推选出新的主服务器并继续对外提供服务。在故障服务器被修复后，原主服务器仍可以备用服务器身份继续进行与主服务器进行日志同步工作。
羲和读写分离集群系统支持最多九个节点，各节点的地位都是平等的，在系统启动时多个节点之间推选出一个节点作为Master，其它节点作为Slave，Master和Slave之间通过心跳检测来监控集群系统的健康状态。在羲和读写分离集群系统正常工作状态下，Master及时将自己产生的日志同步到Slave，以保证主备之间的数据一致性，用户对Master所作的任何更新操作，都会在Slave上得到体现。如果Slave长时间收不到Master的心跳信息，将会在集群节点之间发起选举操作，选出新的Master，并继续对用户提供数据服务，而这种切换对于用户而言是基本透明的。如果Slave端发生故障，而Master仍处于活动状态时，只要故障节点小于集群节点总数的二分之一，集群系统仍继续对外提供数据服务，对用户不会产生任何影响，只需DBA及时对Slave进行故障排除即可。
羲和读写分离集群系统中的备机是可读的，在此基础上提供了读写分离功能。一方面用户可以直接连接备机执行只读查询操作，另一方面也可以通过驱动进行读写分离：驱动自动对用户执行的SQL语句进行读写分类，将写操作发送到主机执行，将只读操作发送到备机执行，驱动按照一定的算法进行负载均衡，以达到提升系统整体性能的目的。
5.1 方案技术原理
羲和读写分离集群为了保障数据库真正的高可用，将节点分为同步组和异步组，同步组中的节点能通过日志同步实时反应数据变化，在Master中的操作，必须在同步组中的Salver节点都执行成功后才返回；异步组中Slave节点数据不实时的从Master节点同步，会定期的做同步。
集群启动时，会从同步组中的节点中随机选举一个正常节点作为Master节点；当Master节点故障时，会从同步组中的节点中随机选举一个正常节点作为Master节点；异步组节点因无法做到实时同步，不允许作为Master节点运行。
5.2 方案技术特点
高可用性
羲和读写分离集群中同步组中配置了多个节点，且都处于运行状态，Master故障下能实现秒级切换，切换时间都在6秒以下。
读写分离
羲和读写分离集群基于事务级别的读写分离方案，如果事务中只有读操作，通过驱动分发器将事务分发到Slave节点中执行；如果事务中写操作，通过驱动分发器将事务分发到Master节点中执行；如果事务中开始是读，后续有写操作，则将开始的读操作分发到Slave节点中执行，直到写操作后，该事务中的所有SQL将在Master节点中执行；对于无法识别读写类型的，将发送到Master节点中执行；对于将写事务识别为度事务时，先在Slave节点中执行，执行错误，发现有写操作，将自动返回在Master节点中重新执行。
负载均衡
羲和读写分离集群中所有的Slave节点用于读操作，当我们读取操作较多时，驱动分发器将通过分发算法，将读操作均衡分布在所有正确的Slave节点中执行，降低Master节点读写冲突，通过Slave节点负载均衡，提高查询性能。
在线扩展
当Slave节点出现加大压力导致性能下降时，羲和读写分离集群可以在线增加Slave节点，增加的Slave节点会自动被集群所识别，然后进行日志同步，读操作负载均衡。
性能提升
在读比例比较大的应用系统中，同步部署羲和读写分离集群，能大大的提升数据库的响应能力，比如：应用系统中的读操作占了70%，则通过部署3个节点的读写分离，能将数据库的整体性能(事务吞吐量)提高2倍以上；随着读操作的比例越高，性能提升倍数约趋向于节点数。
方案核心指标
支持硬件平台：X86、龙芯(3A/3B)、飞腾(FT1000A/FT1500A)、申威(SW1600/SW1610/ SW410)；
支持操作系统：WINDOWS、主流LINUX(REDHAT、CENTOS等)、国产操作系统银河麒麟、中科方德等；
故障切换能力：实现故障秒级切换；
事务支持：支持OLTP、OLAP应用，保障ACID一致性。
6. 迁移适配
羲和数据库提供迁移工具，能将oracle8i、9i、10g、11g、12c、mysql以及EXCEL、CSV、TXT文本数据迁移到羲和数据库中：
为了保障数据的完整性，迁移工具遵循如下迁移流程：
迁移结果正确性验证
数据迁移完成后，需要对迁移数据的正确性进行验证。使用脚本可以非常简单的对数据库对象个数和表数据量进行验证。
1) 验证数据库对象个数
在Oracle数据库和羲和数据库中分别执行以下SQL并比对对象个数。
2) 验证表数据量
将Oracle和羲和数据库输出结果，放入Excel进行数据量比较
