分布式关系型内存数据库系统的可持续运行及日常运维策略探讨_数据库运行连续性

本文不讨论分布式关系型内存数据库系统的常规技术要点。只是基于笔者2021年实际参与的，分布式关系型数据库产品研发后期到电信行业核心级应用部署及上线正式运行的经历，从保障系统7*24小时不间断服务角度，探讨如何实现分布式关系型内存数据库系统的长期可持续运行性。

2020年下半年，随着国产化数据库的蓬勃发展趋势，我司电信行业大客户在某省的核心数据库（Oracle），计划更换为我司自主研发的分布式关系型内存数据库。

数据库系统，作为电信行业的7*24小时不间断服务的核心系统，在迁移到内存数据库后，其实只是C4小机上的一个应用，意味着只要数据库应用不重启、所在主机不宕机，其内存占用将会持续增长，C4单机内存已经接近顶配（无法再增加），当内存使用率达到90%甚至接近100%时，主机存在宕机的风险。传统的磁盘数据库，在数据库空间使用比率较高时，可以通过数据清理、增加数据文件等方式予以缓解，相较而言，内存数据库会给运维人员带来更大的运维压力。

经过21年4月~7月初，约3个多月的试运行和多轮分析，我们基本掌握了内存数据库的运维要点，首先确保多占用的内存空间，能及时回收到表级可复用空间；然后通过整表工具将表级可复用空间回收到数据库级可复用空间；其次日常加强清理各类历史及垃圾数据，确保数据库级可复用空间充足（单节点不少于80G），理论上可实现内存数据库的良性运转，详见如下措施和策略。

1、降低单机初始内存占用率

核心数据库经过多轮瘦身、数据迁移至内存库后，数据+索引的总容量大约在6.3T，起初计划7分片、主备容3副本，每分片初始占用内存约900G，已占到C4单机总内存（1.5T）的60%，为稳妥起见，正式运行前扩为8分片，初始内存占用率降到单机53%左右。

2、严格控制内存空间使用新增

日常新业务开发过程中，不可避免要新增表，原则是尽量限制新增表，需经过评审方可新增，新增表的同时需要提供相应表生命周期管理策略，包括且不限于：分表策略（按日、按月还是按年分表；是否按账户尾号分表、10分表还是50分表）、分表迁移历史库及清理策略（保留3+1还是6+1：3+1是指保留当前月及前3个月，之前的月份分表迁移到历史库，6+1同理）等等。

3、及时将多占用的内存空间释放到数据库级可复用空间

a、定期迁移数据分表到历史库并清理

针对过期的历史月份分表，定期（一般按月）安排迁移至历史磁盘库并同步删除当前库表，释放出的内存空间会回收到数据库级可复用空间。

b、定期清理临时表

日常业务开发测试运维过程中，难免会新增临时表，一般建议新增临时表时，都选择使用特定表空间，根据需要安排定期（按周、按月）删除，释放出的内存空间会回收到数据库级可复用空间。

c、定期整表

• 部分业务流水表在业务量高峰时存在瞬间或短期内记录暴增的场景；
• 批量update操作、先insert后delete操作这两种多占用的undo内存空间、可能受之前其它长时间未提交事务的影响而不能及时回收到表级可复用空间、从而在新的操作下进一步导致内存使用增长的场景；

以上种种批量数据处理场景，在数据处理完毕后，相应数据表空间、索引表空间内存新增使用量都比较大，虽然表级可复用空间可供该表后续的数据记录使用，但是如果后续数据量变化不大的情况下，这些内存空间占用就会存在一定的浪费。

借鉴Oracle的收缩表（shrink）功能，我们安排新增了针对内存数据库表的整表功能，将表中数据和索引集中存储，释放多余的内存空间，整表过程中释放的内存空间，回收到数据库级可复用空间。

另外，日常整哪些表、什么时候整也是有讲究的，我们研究了整表相关策略，建议在每月月末月初出账前一周开始，在每天的业务闲时（在整表过程中涉及到数据搬迁操作，可能会对业务有一定影响）安排整表，按照 【（实际数据占用内存空间/表占用内存空间）* 表占用内存空间】大小倒排序，依次整前100或200张表，实操下来，效果还是很明显的。

上图是5月下旬到7月上旬内存使用趋势跟踪，基本符合我们的预期和判断，该内存库于2021年9月中旬正式割接上线。

以上是笔者本人2021年牵头的实践总结，虽然数据库单机偶尔也会存在异常宕机情况，但是凭着主备容三副本高可用能力，以及相对完善的运维保障措施，目前该内存数据库集群已经在客户生产系统中持续运行了近2年时间，另外我司国产数据库产品也在专业团队负责下，目前进一步研发演进中，未来可期！