内存数据库迁移方法改进研究
2019-10-09李璋琪
文/李璋琪
1 引言
TimesTen内存数据库是一个针对内存进行了优化的关系数据库，它为应用程序提供了当今实时企业和行业所需的即时响应性和非常高的吞吐量。因此，常被用于业务响应及时性要求非常高的场景，例如通信业务中的实时计费系统。Timesten数据库一般采用两节点的主-备机架构来保证内存库的高可用性，主节点负责处理业务读写，备节点接收主节点传递过来的日志，保持备用数据库与主库数据一致。
在系统运维过程中，当需要进行内存数据库底层平台进行主机更换、存储设备调整等操作时，必须将内存数据库从原有平台迁移至新的硬件平台。目前的迁移方法多采用搭建内存数据库主备复制关系，之后进行切换并激活备用数据库的方式，该方式虽然在速度上优于逻辑数据导出、导入，但仍难于满足业务系统的高实时性要求。
因此，本文在原有迁移方式的基础上，从原理、速度、风险等方面进行评估，提出通过增加额外备用数据库进行中转的方式，逐步优化与改进，提高迁移速度，降低迁移风险，也为其他类别内存数据库系统的迁移工作提供思路、建议与参考。
图1：主-备-备方式（不排除Cache Group复制）
图2：主-备-备方式（排除Cache Group复制）
2 现有方案分析
针对内存数据库的迁移需求，可采用数据导出、导入，或新建主-备数据库两种方式。但基于ttMigrate的数据导出、导入方式需要在整个迁移过程期间中断业务，且数据入库时以数据表为单位，尤其在数据导入及重建索引、Cache Group阶段所需时间较长，中断业务时长约在3-4小时，因此在大规模的生产环境中应用较少，最多的方法为新建主-备库方式。
所谓新建主-备库方式，即在数据库迁移工程实施过程中，停止原有Timesten内存数据库上连接的业务，并以原有Timesten内存数据库作为主库，在新主机上新建一套Timesten内存数据库作为备库。待完成主备数据同步后，切断该主备同步关系，将新机器上面的备库切换为主库使用，完成主机设备更换过程。该方案为目前最常用的方案，但所有操作均需在工程实施过程中停止Timesten内存数据库对外服务。其中，新建主备复制关系耗时需1小时以上，统计信息收集半小时以上，迁移过程产生的影响时长接近2小时。
无论采用现有的何种方式，均需要在工程中较长时间中断Timesten内存数据库对外服务，在诸如实时计费等电信级别业务实践中，均无法有效满足业务连续性要求。因此，有必要找到一种迁移时间短，且风险可控的迁移手段。
3 改进思路与方案
从现有分析中可知，影响迁移时长的环节主要有：数据导入、重建索引、重建Cache Group，以及新建主备复制关系等过程。因此，缩短迁移时间也应从上述关键环节入手。
Cache Group是TimesTen内存数据库的一个重要组件，对于现有应用数据存放在Oracle Database（或简称“物理库”）中的场景，可通过Timesten内存数据库的Cache Group组件从Oracle物理数据库中按照一定时间间隔将数据库刷新到内存数据库中，实现Oracle物理库和Timesten内存数据库之间数据同步。
在实践过程中，充分利用高可用架构及备用数据库特点，结合Cache Group组件的刷新方法，采用新建第二套备库，分别形成两种主-备-备三台主机同时在线的过渡架构，并对效果进行了验证。
3.1 主-备-备方式（不排除Cache Group复制）
在原有的主-备架构内存数据库基础上，在新增的主机上建立第二套备库，添加到原有主-备架构的内存数据库集群中，形成主-备-备架构。第二套备库采用默认的搭建方式（不排除Cache Group），即主备复制策略中包含了针对Cache Group的复制，且第二个备库（subscriber）是read-only状态，所以新增加的备库上Cache Group表将变为实体表（Timesten内部机制决定），必须在工程实施时间窗口内，删除该实体表并重建为Cache Group。
该方案与现有方案比较，在工程实施时间窗口内减少了数据导入、重建索引，以及新建主备复制关系等操作，停机时间有所下降，但仍然必须包含重建Cache Group的操作，尤其在内存库Cache Group较大的情况下，重建耗时较长，经实际测试，100G大小的内存数据库迁移过程耗时约40分钟，仍不能够很好地满足业务连续性需求。
方案的技术架构如图1所示。
3.2 主-备-备方式（排除Cache Group复制）
分析第一次改进方案可知，该方案在搭建第二套备库时采用了默认方法，重建Cache Group的过程消耗了大量时间。在此基础上进一步优化，通过研究Timesten复制机制，改进了第二套备库CacheGroup的刷新方法，形成了主-备-备方式（排除Cache Group复制）的方案，方案的技术架构如图2所示。
可以看到，本方案在新主机（目标服务器）上面搭建了第二套备库，并且与原有的主库保持数据同步，所以在工程实施过程中无需对位于新主机上的内存数据库进行操作，只需要停止原有的内存数据库，并将应用程序重新连接到新的内存数据库即可，不需要停机时间，对业务的影响非常小。
方案主要步骤如表1所示。
方案具体实现方式详细阐述如表2所示。
3.3 改进点与效果分析
本章所述的两种“主-备-备”架构方案均无需在工程实施时间窗口内进行数据导入、重建索引，以及新建主备复制关系等操作。3.2节所述的“排除Cache Group复制”方案更进一步，与3.1节所述的“不排除Cache Group复制”方案比较，采用了排除复制策略的方式，也就是重建第二套备库的Cache Group，并且直接从物理库刷新数据到Cache Group，完全避免了重建Cache Group的迁移或重建操作，更无需受制于内存库Cache Group的大小影响。
经过严格的评估与测试，改进后的主-备-备（排除Cache Group复制）方案，在省内多个地市计费业务系统内存数据库迁移工程中得到应用，并取得良好效果。
（1）工程实施过程中的停机时间从3-4小时逐步缩短为无需停机时间（仅需要应用程序重新连接一次）。
（2）工程操作可以提前实施，并且可以利用搭建完成的目标内存数据库进行功能与性能方面的测试工作。
（3）实施安全性高，在操作过程中，不对原有生产数据库数据做变更，而且原有生产库始终处于正常运行状态，如果切换到新系统出现问题，应用程序可以立即切换回原有内存数据库。
4 结束语
本文在研究Timesten内存数据库各个组件功能与实现方式的基础上，结合业务场景的具体需求，通过合理设计与多次尝试，逐步减少由迁移工程造成的业务中断时长，最终将其从3-4小时降低到分钟级别，并成功应用于生产系统的工程实践中。
表1
核查变更结果，并再次检查业务是否正常。a)检查操作前库表备份记录文件是否存在b)检查Cache Group刷新状态c)核查复制策略是否排除所有Cache Group停止并删除原备库a)删除备节点Cache Group。drop active standby pair; 之后逐个删除Cache Group：drop cache group XXX;b)备节点重启Cache agent进程c)备节点Cache agent进程停止d)备节点做ckpt：call ttckpt e)Unload备节点DSN实例f)Destroy备节点DSN实例g)停止TT内存库daemon主进程h)重启TT内存库daemon主进程更改主节点复制策略，并重新开启复制进程（在复制策略中新增第二套备库，由主-备策略变为主-备-备策略）过程如下：a)删除原复制策略b)新建主备备复制策略，subscriber为第二套备库节点c)设置原主库仍为主节点d)启动内存库复制进程。a)执行备节点的备机重建脚本 （重建第一个备库）b)开启备节点Cache agent进程和复制进程，包括：开启TT内存库Cache agent进程、开启TT内存库复制进程。c)检查备节点角色状态、主节点检查复制日志是否进行同步。d)设置主备节点不自动重启加载e)等待主节点复制同步完成。在目标服务器上建立第二套备库，主库为原来的生产库。重建原备库，开启复制进程。将备库原来从主库刷新数据，变更为从物理数据库刷新数据。a)建立第二套备库：ttRepAdmin -duplicate -from
