·2024-01-26 16:52

基础架构组长·西部某城商银行

某银行生产环境应用OB数据库运维管理规范及实践

字数 10479阅读 2105评论 2赞 4

内容摘要：

本文介绍了在生产环境应用推广OceanBase分布式数据库的日常运维管理规范，包括版本、硬件、操作系统、高可用测试等方面的规范，以及OB集群的高可用验证和恢复步骤，生产环境中的运维经验和数据库安全加固原则。同时提到了IT开发规范和OceanBase数据库功能正在完善。

当前摘要为AI生成

近年来，随着国家信息技术应用创新战略的快速推进，各银行业金融机构积极响应国家政策号召，大力推进信息系统信创适配改造，数据库作为最核心的基础软件产品，其稳定性不言而喻。国产数据库起步晚，市场竞争剧烈，案例相对较少，产品可靠性及成熟度还有待市场的不断检验。经过近4年的市场推广，OceanBase作为国内数据库头部产品之一，产品也日趋完善，但在使用过程中，也存在一些需要大家高度关注的问题。本文将分享一些笔者在生产环境应用推广OceanBase分布式数据库的日常运维管理规范，帮忙中小银行的读者们更多的了解掌握OceanBase，进一步规范使用，避免踩坑，提高信息系统的稳定性。

# 一、软件产品版本规范
目前OceanBase软件产品版本更新迭代较快，各版本之间在功能、性能及稳定性等方面也存在较大差异，如何在众多的版本中选择适合自身需求的产品产品至关重要。笔者单位选择版本一般遵循“原厂推荐的次新、近一年来客户案例最多、最稳定的LTS（长期支持）版本”，最新版本一般都未经最终客户实际推广使用，仅在产品厂商内部开展了一些测试验证，产品的稳定性及功能等方面无法全面得到检验，中小银行受限于人员数量及人员技术水平限制，建议不宜做第一个吃螃蟹的人，一旦产品出现重大缺陷，将会十分被动，完全依赖产品厂商人员响应时效性，故我们应该以保障业务连续性为第一目标，避免最新版本，选择经很多客户验证的稳定版本，确保业务系统连续运行。

软件版本确定后，在安装部署产品时一般将当前软件版本的最新补丁包一并安装部署，补丁包修复了很多已知缺陷，可避免很多问题。笔者项目实施过程中因版本缺陷导致的问题如下：
![](/home/attachment/202401/26/377659_170625774172059.png)
结合上述原则，笔者所在单位的ECIF等关键业务系统OceanBase数据库软件及配套软件版本选择如下，可供大家参考：
![](/home/attachment/202401/26/377659_170625775596450.png)

备注：OBProxy及OCP版本一定要适配Observer版本

# 二、硬件环境配置规范
在数据库集成部署过程中，硬件设备需参照最佳实践进行配置，这样可以很大程度的降低数据库安全运行风险，具体如下：

## （一）硬件设备规范
虽然官方网站上显示采用3台服务器就可以搭建一套3副本的OB集群，但经过实践，生产环境一般建议每个ZONE至少配置2台机器，即：至少采用6台服务器搭建3副本的OB集群，这样既可以降低因单台硬件设备故障导致的业务影响，又能增加高可用性。为方便日常运维，建议硬件服务器的型号及配置保持一致，形成一个通用硬件设备规范，笔者所在单位的OB硬件设备品牌型号、资源容量等都集中统一，具体配置规范如下，可供大家参考：
![](/home/attachment/202401/26/377659_170625779756067.png)

## （二）磁盘RAID模式规范
一般建议操作系统磁盘配置为RAID1模式，对于性能要求不高的系统，数据磁盘可配置为RAID5模式，对于性能要求较高的系统，数据磁盘配置为直通模式，笔者所在单位的系统对于性能要求不是很高，RAID模式配置如下所示：
![](/home/attachment/202401/26/377659_170625783675281.png)

## （三）网络配置规范
服务器配置两块万兆网卡，分别取两个网卡的第一个口做bond，配置为bond4模式，两块网卡分别上联至两个交换机，交换机侧配置802.3ad链路聚合模式，双网卡同时承载流量。

# 三、操作系统参数规范
操作系统是数据库运行的基础，参数设置不合理可能导致OB数据库异常关闭，笔者所在单位OB日常运维过程中，设置了如下规范，可供大家参考：

## （一）时钟同步参数
分布式数据库产品不同节点之间时钟要保持同步，误差不宜超过2秒，一旦超过将会导致数据库软件进程异常退出，笔者单位的测试环境就出现过因时钟不同步导致observer进程异常退出的情况。所以，一定要确保各OBserver节点及OCP节点的时钟同步参数都正确配置且运行正常，笔者所在单位OB服务器使用银河麒麟V10操作系统，采用chrony时钟同步服务，保证所有节点的时钟偏差在2秒以内，此外，生产环境一定要配置时钟同步状态的实时监控，一旦因时钟同步服务异常或网络异常等情况导致节点之间时钟偏差过大，将会第一时间预警，可大大降低数据库异常情况发生的概率。

## （二）操作系统审计服务
银河麒麟V10操作系统默认开启的auditd审计服务，该服务组件存在内存泄露缺陷，运行一段时间后将会耗尽操作系统的内存资源，故需要关闭此服务。使用银河麒麟V10操作系统的朋友可关注此项。

## （三）目录规范
笔者所在单位OB服务器的目录规范如下：
![](/home/attachment/202401/26/377659_170625786520372.png)

## 四、高可用测试规范
高可用测试验证工作是信息系统投产上线的最后一道防线，数据库集群集成部署后需要开展严格的多场景高可用测试验证，满足测试预期目标后方可投产上线，否则将会对日常运维工作带来巨大的挑战，笔者所在单位设计了一套较为标准完善的高可用测试规范，可供大家参照，具体如下：

## （一）OCP高可用规范
1.OCP节点停docker容器。停止任意一台OCP服务器的OCP Docker容器，验证OCP服务的高可用情况，验证后拉起docker，确保OCP服务恢复正常。
**操作步骤：**
1.登录OCP服务器，使用docker stop ocp命令将OCP容器关闭。

**高可用验证：**
1.访问该节点OCP地址：http://xx.xx.xx.xx:8080，OCP服务不可访问。
2.域名或负载均衡VIP访问OCP：http://ocp.nxbank.cn:8080，验证OCP服务仍可访问，日常维护操作不受影响。

**恢复步骤：**
1.登录OCP服务器，使用docker start ocp命令将OCP容器启动。
2.访问该OCP地址http://xx.xx.xx.xx:8080，确保可以访问操作

参照上述步骤，依次验证其它OCP节点。

**预期结论：**
任意一个或两个OCP节点出现docker容器故障，均可正常通过域名或负载均衡VIP地址访问OCP云管平台，可正常对OB集群进行管控操作。

2.OCP节点停进程(kill -9)。Kill任意一台OCP容器的Java进程，验证OCP服务的高可用使用情况，   验证后启动进程，确保OCP服务恢复正常。
![](/home/attachment/202401/26/377659_170625795290796.png)

3.OCP节点网卡中断。禁掉任意一台OCP服务器的网卡60秒，模拟OCP节点网络故障，验证OCP服务的高可用使用情况，    60秒后自动恢复正常。
![](/home/attachment/202401/26/377659_170625797970981.png)

4.OCP节点宕机。直接关闭任意一台ocp节点服务器，验证ocp服务的高可用使用情况  ，验证结束后重新开机并确保ocp所有服务恢复正常。
![](/home/attachment/202401/26/377659_170625802916545.png)

## （二）OBSERVER高可用规范
**1.RootService节点停进程(kill -9)。kill rootservice所在的observer节点，模拟rootservice节点故障，验证故障恢复和业务系统影响   验证后启动observer，确保集群恢复正常，通过应用日志监控以及ocp监控确认流量恢复情况。**
![](/home/attachment/202401/26/377659_170625808940158.png)

**2.RootService节点网卡中断。禁掉rootservice所在的observer节点的网卡60秒，模拟rootservice节点网络故障，验证故障恢复和业务系统影响，     60秒后rootservice节点网络自动恢复正常     ，通过应用日志监控以及OCP监控确认流量恢复情况。**
操作步骤：
1.开启业务压测程序。
2.查询rootservice服务所在机器位置
select svr_ip,with_rootserver from __all_server;
3.从其它observer主机执行ping命令
date && ping rootservice节点 && date
4.登录rootservice所在服务器，使用ifdown bond0命令禁掉网卡（禁掉60秒）
date && ifdown bond0 && sleep 60 && ifup bond0 && date

高可用验证：
1.验证业务系统的报错以及恢复情况。
2.故障期间，检查rs的位置已发生切换。
3.登录ocp查看集群租户性能监控，观察故障期间业务TPS波动及RTO恢复情况

恢复步骤：
1.1分钟后节点网络自动恢复正常（ping命令正常）。
2.查看日志同步是否完成（预期返回空）
select svr_ip, svr_port, table_id, partition_idx from __all_virtual_clog_stat where is_in_sync= 0 and is_offline = 0 and replica_type != 16;
3.检查副本个数，确保不少副本（预期返回空）
select member_list, table_id, partition_id, count(1) as cx from __all_meta_table group by table_id, partition_id, member_list having cx<>5;
4.观察一段时间业务系统的运行情况，确保业务数据无问题。

预期结论：
RootService节点网卡中断60秒场景，TPS下降，最低跌至零，2分钟故障恢复后，业务TPS恢复正常，验证通过。

**3.RootService节点宕机。关闭rootservice所在的observer节点，模拟rootservice服务器宕机故障，验证后启动rootservice，确保集群恢复正常，通过应用日志监控以及OCP监控确认流量恢复情况。**
操作步骤：
1.开启业务压测程序；
2.查询rootservice服务所在机器位置
select svr_ip,with_rootserver from __all_server;
3.登录rootservice所在服务器，使用shutdown -h now命令关闭该节点服务器。

高可用验证：
1.验证业务系统的报错以及恢复情况，1分钟后无任何业务报错；
2.故障期间，检查rs的位置已发生切换；
3.登录ocp查看集群租户性能监控，观察故障期间业务TPS波动及RTO恢复情况。

恢复步骤：
1.使用管理口登录原rootservice服务器，启动该服务器;
2.登录原rootservice服务器，启动observer进程
su - admin;cd /home/admin/oceanbase;./bin/observer
3.查询__all_server表，确保start_service_time有时间、stop_time为空、status都是active;
4.查看日志同步是否完成（预期返回空）
select svr_ip, svr_port, table_id, partition_idx from __all_virtual_clog_stat where is_in_sync= 0 and is_offline = 0 and replica_type != 16;
5.检查副本个数，确保不少副本（预期返回空）
select member_list, table_id, partition_id, count(1) as cx from __all_meta_table group by table_id, partition_id, member_list having cx<>5;

6.观察一段时间业务系统的运行情况，确保业务数据无问题。

预期结论：
RootService节点宕机场景，TPS下降，最低跌至零，1分钟故障恢复后，业务TPS恢复正常，验证通过。

**4.ocp停止ob节点。在ocp界面上停止和启动任意一台leader（主副本）所在的observer主机，模拟节点重启，验证恢复和业务系统影响，验证后启动observer，确保集群恢复正常，通过应用日志监控以及ocp监控确认流量恢复情况。**
![](/home/attachment/202401/26/377659_170625846230960.png)

**5.停止ob进程(kill -9）。kill任意一台leader observer，模拟节点故障，验证故障恢复和业务系统影响，     验证后启动observer，确保集群恢复正常 ，通过应用日志监控以及ocp监控确认流量恢复情况。**
![](/home/attachment/202401/26/377659_170625849021251.png)

**6.ob节点网卡中断。k禁掉任意一台leader observer的网卡60秒，模拟节点网络故障，验证故障恢复和业务系统影响，60秒后恢复正常 ，通过应用日志监控以及ocp监控确认流量恢复情况。**
![](/home/attachment/202401/26/377659_170625851031348.png)

**7.ob节点宕机。关闭任意一台leader observer服务器，模拟服务器宕机故障，验证故障恢复和业务系统影响，验证后启动observer，确保集群恢复正常，通过应用日志监控以及ocp监控确认流量恢复情况。**
![](/home/attachment/202401/26/377659_170625853442977.png)

## （三）ODP高可用规范
1.停止obproxy进程(kill -9)。kill任意一台obproxy进程，模拟obproxy节点故障，验证故障恢复和业务系统影响，验证后拉起obproxy，确保集群恢复正常，通过应用日志监控以及ocp监控确认流量恢复情况。
![](/home/attachment/202401/26/377659_170625856578446.png)

# 五、生产环境应用OB运维经验分享

以下是一些行内日常运维实践过程中的经验，分享给大家。

## （一）租户内存写满场景
生产运行环境中，涉及批量数据导入操作时，一定要对处理任务进行适度分割及合理限流，否则很容易导致租户内存（memstore）快速写满，一旦内存写满数据库将会hang住，进而影响业务连续性。针对大批量数据写入的场景，一般建议按照如下优先级采取有效措施：

1.应用侧降级批量处理任务。将批量处理任务分割为多个小任务，顺序执行，避免数据写入速率高于内存转储速率。
2.增加租户内存。如果服务器内存资源充裕的情况下，通过OCP扩充租户内存资源。
3.调高内存转储线程数。加快转储，尽快释放内存。通过参数'minor_merge_concurrency'控制并行转储线程数，默认为0.表示只有一个线程数。（该参数调大的代价为CPU使用率升高）
![](/home/attachment/202401/26/377659_170625861678643.png)
4.开启数据库写入限速。内存写入达到一定阈值后OB会主动限制客户端导入速度。
由租户级别参数“writing_throttling_trigger_percentage”控制，该参数是调整写入速度的阈值，当memstore已使用的内存达到该阈值时，触发写入限速，该参数默认值为100，代表关闭写入限速机制，该参数的取值范围为0-100，修改该参数无需重启OBServer即刻生效。
另一个参数writing_throttling_maximum_duration表示触发限速后，剩余内存最多支持多长时间的写入时间，默认为1小时，该项一般不做修改。
![](/home/attachment/202401/26/377659_170625864222309.png)
5.应用侧降级批量处理任务。将批量处理任务分割为多个小任务，顺序执行，避免数据量过大。

## （二）租户ZONE优先级配置
分布式架构下，合理的ZONE优先级配置可以提高业务处理效率，提高物理服务器资源的利用率，默认情况下，OB集群的租户ZONE优先级为random随机，即多个ZONE的优先级一样，表分区主副本随机分布到不同的ZONE中，每个ZONE都承担业务处理功能。ZONE优先级配置一般遵循如下原则：

1.针对夜间批量处理场景，如果热点表随机分布到不同的服务器上，将会导致跨节点分布式事务较多，过多的分布式事务会增加事务处理响应延迟，降低数据库集群的处理效率，针对这类型场景，可考虑采用表组tablegroup特性，将关联度较高的热点表配置为一个表组，同一个表组内的主副本表分区会分分布到相同的机器，这样可减少因分布式事务带来的效率问题。
2.同一套集群中，可按照不同租户ZONE优先级交叉的方式配置，比如3副本集群中，租户A的ZONE优先级为ZONE1;ZONE2;ZONE3，租户B的ZONE优先级为ZONE2;ZONE1;ZONE3，租户C的ZONE优先级为ZONE3;ZONE1;ZONE2，每个租户的主副本相互分离到不同的ZONE中，从整个集群视角来看，所有ZONE都承载了业务流量，既能充分利用机器资源，又能避免分布式事务，提高运行效率。

## （三）应用端数据源连接池参数配置

每个节obproxy(OB数据库连接反向代理，用于代理前端应用访问后端数据库）默认支持的最大客户端连接数（client_max_connections参数控制）为8192，正常情况下，3各obproxy节点累计可提供24576个数据库连接，完全可以满足多个租户场景的使用。如果应用程序端数据源连接池参数配置不合理，将会消耗大量的数据库连接资源，导致整个集群无法连接，笔者在项目实施过程中就遇到因一套系统数据源连接池异常导致obproxy连接数耗尽，导致整个集群无法访问的场景，所以，在项目实施过程中行，一定要合理配置数据库连接池参数，否则将会带来致命灾难。

## （四）事务超时时间参数配置
租户的事物超时时间（ob_trx_timeout参数）默认为100秒，一定要根据业务系统实际情况合理设置，该参数过小将会导致事务尚未正常执行完就被提前关闭，设置过大将无法及时关闭异常挂起的事务，占用数据库资源。笔者项目实施过程中，就出现：该参数由默认100秒调整为100000秒（27.7小时），出现了一条每间隔5分钟执行一次的异常挂起UPDATE SQL语句，导致数据库物理服务器CPU被耗尽，进而导致数据库集群不可用。

## （五）数据库备份
目前OceanBase数据库仅支持OSS（阿里云对象存储）、COS（腾讯云对象存储）及NFS三种备份截至，对于大部分中小银行可能只具备NAS存储，没有OSS及COS云对象存储，笔者所在单位使用NAS存储开展数据库集中备份，由于NFS协议在性能方面不是很好，实际使用效果不是太理想，建议有条件的单位，尽量采购OSS（阿里云对象存储）或COS（腾讯云对象存储）进行数据库备份，可大幅度提升数据备份及恢复效率。每日至少一次全库备份，备份数据至少保留7日。

V2.2x及V3.x两个版本只支持集群级别的数据物理备份及租户级别的数据恢复，每次发起备份任务会将整个集群的所有租户数据全部备份，实际使用过程中，测试环境为了恢复使用其中一个租户的数据，需要将整个集群的数据都进行物理备份。

V4.x版本做了优化调整，支持以租户为单位进行数据备份及恢复，进一步提高了数据备份及恢复的灵活性。

## （六）监控管理
OCP管理工具中包含了较为强大的日常运维监控及告警功能，实现集群状态及集群性能等关键指标监控，数据库管理员应充分利用OCP工具对数据库进行全面监控，通过OCP工具的“告警配置”及“告警订阅”功能吧相关告警信息与自己已有的监控告警平台进行对接，当出现异常告警信息后可以第一时间通过短信方式告知数据库管理人员。

## （七）参数配置经验
默认安装后，一般需要对部分关键参数进行合理优化配置，以保障数据更加高效运行，具体参照如下：

1.集群参数
![](/home/attachment/202401/26/377659_170625867290145.png)

2.obproxy参数
![](/home/attachment/202401/26/377659_170625868888515.png)
```asp
其余关键参数设置可参照如下：
SET GLOBAL connect_timeout=600;
SET GLOBAL interactive_timeout=604800;
SET GLOBAL ob_query_timeout=7200000000;
SET GLOBAL ob_trx_timeout=7200000000;
SET GLOBAL net_read_timeout=30;
SET GLOBAL net_write_timeout=180;
SET GLOBAL ob_pl_block_timeout=7200000000;
SET GLOBAL ob_trx_idle_timeout=7200000000;
SET GLOBAL ob_trx_lock_timeout=-1;
SET GLOBAL wait_timeout=604800;
SET GLOBAL ob_max_parallel_degree=32;
SET GLOBAL parallel_max_servers=30;
SET GLOBAL parallel_servers_target=30;
SET GLOBAL nls_date_format='YYYY-MM-DD HH24:MI:SS';
SET GLOBAL nls_timestamp_format='YYYY-MM-DD HH24:MI:SS.FF6';
SET GLOBAL nls_timestamp_tz_format='YYYY-MM-DD HH24:MI:SS.FF6 TZR TZD';
SET GLOBAL recyclebin=OFF;
SET GLOBAL ob_enable_truncate_flashback=OFF;
SET GLOBAL undo_retention=900;
SET GLOBAL ob_sql_work_area_percentage=10;
SET GLOBAL ob_sql_audit_percentage=3;
SET GLOBAL max_allowed_packet=104857600;

```

## （八）数据库安全加固
数据库安全加固原则如下：

（1）不使用的用户一律设置为禁止登录并锁定；
（2）依据“必需知道”和“最小授权”原则，分配账号权限；
（3）不允许有密码为空的用户；
（4）租户及用户需设置符合安全规范的密码策略，密码复杂度需满足如下规范：
长度为 8-32个字符，只能包含字母、数字和特殊字符（~!@#%^&*_-+=|(){}[]:;,.?/），大小写字母、数字和特殊字符都至少包含 2 个。

## （九）日常开发规范
1.不要在系统表空间上创建用户数据库对象；
2.系统变量截止设置global级别，尤其是超时时间；
3.截止一个事物内大批量数据插入和修改，把大量记录的增删改操作放到一个事物内，不仅提交效率低，更有可能造成租户内写满，所以要分批次提交这些更新，拆分成多个小事物提交，推荐一个事物处理的记录数不超过2000行；
4.业务要有重试逻辑：应用中主动捕捉失败事物并加入重试逻辑，防止由于集群合并或副本切主带来的杀事物的影响；
5.单表大小不超过50G或500万行，对于数据量比较大的表，根据表数据的常用关联或检查字段进行分区，以最大程度发挥分布式数据库的性能。

# 六、总结
随着客户案例的增加，目前OceanBase数据库产品功能正在逐步完善，上述内容是笔者日常运维及项目建设过程中的一些规范及所遇到的经验分享，希望能够帮忙同行业朋友们规避一些风险，帮助大家积累经验，在大家的共同努力下，相信OceanBase数据库产品的稳定性及功能会越来越完善。

信创数据库运维管理规范信创数据库 OceanBase

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！