一种不停机数据库迁移方法与流程

1.本发明涉及互联网金融交易系统领域，特别涉及带有运营商特色的交易数据信息维护方法。


背景技术：

2.互联网金融交易系统一直以来作为金融支付系统的核心，承载着核心业务链路中核心交易信息的生命周期管理，是支付系统中数据量最大，业务场景最为复杂的系统，而其保有的数据量最为繁多又极其重要，这对于交易数据的存储提出了更高的要求，而作为给运营商提供服务的应用方数据上更为繁琐与复杂，伴随着业务量的不断提升，各系统公用数据库时存在数据库资源竞争的频率越来越高，为了保证在未来更大数据请求下的高成功率，数据库迁移迫在眉睫。
3.本专利针对这一场景，提出了一种在保证集团公司业务正常运行或极小影响的情况下对oracle数据库进行不停机切换迁移的实施方案。相较于传统的数据库直接切换方式，增加了临时表与缓存的方式，增强了数据库切换过程中的容错性、健壮性，简化了数据校对的复杂度。在集团用户无感知的情况下完成底层数据库切换，为复杂场景下要求高实时业务方提供了具体的实施步骤和经验。


技术实现要素：

4.本发明要解决的技术问题是克服现有技术的缺陷，提供一种不停机数据库迁移方法。
5.本发明提供了如下的技术方案：
6.本发明提供一种业务不停机底层数据库热迁移实施方案，包括以下步骤：
7.s1、数据库迁移之前正常交易数据流向如图1；
8.交易查询
9.在v1版本期间上线对应最终表交易查询的代码，同时对查询交易返回不存在的调用返回系统维护中。预计影响数据量：临时表中数据，大约2100条。
10.预计影响时间：30分钟。
11.s2、迁库过程中数据流向以及影响：正常交易数据：v1版本—切换到临时表，如图2所示；
12.s3、正常交易数据：v2版本—切换到最终表，这个阶段最终表已经包含了所有需要迁移的数据(旧表中的所有数据)，而临时表中的数据等待dba做迁移对比(迁移到最终表)，此时临时表中数据无法做后续交易，如图3所示；
13.s4、迁库完成，所有数据迁移完成，交易数据添加到最终表。
14.与现有技术相比，本发明的有益效果如下：
15.1.运营商业务正常运行无影响，集团用户几乎无感知；
16.2.分阶段、递进式实施方案，全方位闭环的补偿保障方案；
17.3.复杂业务背景下，高并发高实时性要求的前提下，交易无差错。
18.4.相较于传统的数据库直接切换方式，增加了临时表与缓存的方式，增强了数据库切换过程中的容错性、健壮性，简化了数据校对的复杂度。
附图说明
19.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
20.图1是迁库之前交易正常数据的流向流程图；
21.图2是迁库过程中v1版本切换临时表交易数据流向流程图；
22.图3是迁库过程中v2版本切换最终表交易数据流向流程图；
23.图4是s1步骤的实施例示意图；
24.图5是s2步骤的实施例示意图；
25.图6是s3步骤的实施例示意图；
26.图7是s4步骤的实施例示意图；
27.图8是版本v0数据流向说明示意图；
28.图9是版本v1阶段数据库流向示意图；
29.图10是版本v2阶段数据库流向示意图；
30.图11是版本v3阶段数据库流向示意图。
具体实施方式
31.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
32.实施例1
33.如图1-11，本发明提供一种不停机数据库迁移方法，包括以下步骤：
34.s1、版本v0迁库前的前置操作，用于控制版本v1操作落db-new数据的幂等判断；原有下单流程不变，仅在下单成功情况下新增存储请求四要素在redis的操作，在v0版本上线前保障此版本稳定运行一段时间；
35.操作注意点：
36.(1)redis存储期限：1～2天；
37.(2)redis格式：
38.{trade_center_v0_requestdate_requestorderno_requestsystem_merchantno,normal}
39.其中小写字符代表变量，记录的是确定的值，例如：
40.收单域订单redis存储：
41.{trade_center_v0_20170815_2017081517tppiop1110000000000466_trade_acquiring_3178000000875377,normal}
42.资金域订单redis存储：资金幂等校验没有考虑商户号
43.{trade_center_v0_20170815_2017081517tppiop1110000000000466_trade_
deduct,normal}
44.(3)涉及业务：资金下单、收单下单；
45.(4)在v0发版后检查redis数据是否正常；
46.s2、版本v1将数据新增到新数据库db-new的t1-move表中，仅仅处理在move表中的订单，原表中的数据静置后进行数据迁移；v1版本上线前操作：(后续v2版本照此操作)
47.关闭应用大总管后台操作入口；
48.该应用所有定时任务暂停(将所有定时任务状态置为invalid失效)；
49.数据库层面：
50.新增库db-new；
51.在db-new库中新增两套表：t1-new《与db-old所有表名保持一致》，t_move《临时存储新库数据表》；
52.v1版本操作如下：
53.①
将db-old数据源连接信息替换成db-new的；
54.②
mapper层所有表名换成t1-move：暂时存储数据，后续会迁移到t1-new表；
55.③
下单：落t1-move表；
56.a.下单前：先判断请求四要素是否已存储在trade_center_v0_request缓存中，已存在则直接抛出异常——重复下单，不存在则正常落t1-move表；
57.b.下单后：下单成功后存储前缀为ade_center_v1_request的redis缓存，请求四要素拼接作为key；
58.④
支付(以前就有判断订单是否存在)：支付前根据交易号判断该订单是否存在t1-move表，不存在则直接抛出异常’订单不存在’《数据可能存储在t1-old表》，存在则继续支付；
59.⑤
接收支付控制kafka处理：新增一条日志打印——首先判断该支付单是否能在t1-move表中查到，如果查不到则打印经支付控制kafka消息转换而来的支付信息，否则继续处理；
60.发送kafka无需做特殊处理；
61.发版后操作：观察数据落t1-move表正常后，则可以通知dba将db-old数据迁移到db-new的t1-new表中；
62.s3、版本v2发布条件：等待dba将db_old的所有数据迁移到db-new的t1-new表，再发布v2版本；
63.数据库层面：无变化；
64.v2版本操作如下：
65.1)继续使用db-new数据源
66.mapper层所有表名更换为t1(db-new中的表)，相对于上一个版本删除move后缀；
67.2)下单：
68.下单前：先判断请求四要素是否已存储在ade_center_v1_request缓存中，已存在则直接抛出异常——重复下单，不存在则正常落t1-new表；
69.下单后：无需新增redis缓存操作(后续版本交易还是落t1-new表，仅是将代码还原到迁库之前，且只改动数据源)；
70.3)支付(以前就有判断订单是否存在)：支付前根据交易号判断该订单是否存在t1-new表，不存在则直接抛出异常“订单不存在”《数据可能存储在t1-move表》，存在则继续支付；
71.4)接收支付控制kafka处理：新增一条日志打印——首先判断该支付单是否能在t1-move表中查到，如果查不到则打印经支付控制kafka消息转换而来的支付信息，否则继续处理；
72.5)发送kafka无需做特殊处理；
73.发版后操作：观察数据落t1-new表正常后，通知dba将t1-move数据迁移到t1-new表中；
74.s4、版本v3发布条件，等待dba将t1-move的所有数据迁移到t1-new表，再发布v3版本；
75.数据库层面：无变化；
76.v3版本操作如下：
77.a.继续使用db-new数据源；
78.b.mapper层所有表名为t1(db-new中的表)；
79.c.下单、支付逻辑还原到迁库之前；
80.发版后操作：检查数据量是否正确；
81.s5、迁移过程预期问题
82.(1)v0版本发布只涉及上线redis控制正交易唯一性约束问题，理论不会有任何问题；
83.(2)v0到v1版本发布期间(一半机器运行v0，一半机器运行v1)，可能出现下单落在v0，支付落在v1或者下单落在v1，支付落在v0的情况下：
84.正交易：对于老交易来说不受任何影响(老交易都是下单并支付)，对于新交易全部受影响；
85.反交易：新老交易视原交易位置，如果原单不在相应版本的表里，全部受影响；
86.(3)v1版本发布完成后对新老交易的所有正交易均不受影响，所有记录全部落在temp表；对新老交易的反交易，原交易在老表的情况下受影响；
87.(4)在v1和v2发布期间(一半机器运行v1，一半机器运行v2)，可能出现下单落在v1，支付落在v2或者下单落在v2，支付落在v1的情况下：
88.正交易：对于老交易来说不受任何影响(老交易都是下单并支付)，对于新交易全部受影响；
89.反交易：新老交易视原交易位置，如果原单不在相应版本的表里，全部受影响；
90.(5)v2版本发布完成后对新老交易的所有正交易均不受影响，所有记录全部落在最终表；
91.对新老交易的反交易，在原交易在tmep表的情况下受影响；
92.对新老交易的反交易，原交易在老表里的全部受影响；
93.(6)v2到v3版本发布至完成理论数据全部切到最终表后，无影响；
94.回滚方案迁移到tmp表的过程中发生影响，代码回滚，将tmp表数据移动至老表。
95.本发明提供复杂场景下业务不停机oracle数据库切换迁移实施方案，以下是对上
述步骤的补充和总结：
96.s1、对查询模块来说：在v1版本期间上线对应最终表交易查询的代码，同时对查询交易返回不存在的，调用返回系统维护中。预计影响数据量：临时表中数据，大约2100条。预计影响时间：30分钟；
97.s2、v1版本切换到临时表时：最坏情况下会影响总计200条左右反向交易，预估影响时间5～10分钟。
98.正向交易下单信息在旧表的数据(数据量根据发版完成时间而定)，会被禁止支付，其余正向交易正常无影响。
99.切库后交易号中分库号对应修改。
100.后续根据交易号中的分库号来直接拒绝或者处理交易。
101.最坏情况下可能出现，在发布v0版本前已下单交易在v2版本重复下单，数据库中有相同数据，在最后数据合并时会进行处理筛选。
102.预估dba操作时间5分钟，临时表中可能产生大约2100条数据。
103.s3、v2版本发版前后：影响交易量为临时表中数据，正向交易预计2w笔，影响部分为临时表中数据的反交易，但同时dba正在做数据迁移，将临时表数据迁移至最终表，所以迁移速度越快影响越小，预计影响反交易200笔左右，预估影响时间5～10分钟；
104.s4、v2版本推完之后，一定要确保所有数据迁移完成，交易数据添加到最终表，对操作期间的数据做相应核查。
105.进一步的，数据库和表名字解释：
106.1.db-old：原始数据库；
107.2.t1-old：原始表(t1指的是所有的表)；
108.3.db-new：需要迁移到的数据库；
109.4.t1-new：新的数据库中的表(t1指的是所有的表)；
110.5.t1-move：新的数据库中临时存储表(t1-move指的是所有的表)。
111.图8至11如下所示：
112.图8是版本v0数据流向说明示意图：
113.数据库迁移前v0阶段：每笔交易的数据都将落入老的数据库和老的交易表中；
114.图9是版本v1阶段数据库流向示意图：
115.v1实施阶段：在v1版本之前，所有的交易数据都保存在老的数据库db-old和老表中t1-old；
116.在v1版本上线后，新发生的交易数据将保存在新的数据库db-new和新的临时表中t1-move；
117.此外在v1版本上线之前会将一天前的所有老的历史数据迁移到新的数据库中，保证查询和反交易的正常进行；
118.图10是版本v2阶段数据库流向示意图：
119.v2实施阶段：在v1版本和v2版本之间时，新进入的交易数据保存在新的数据库db-new和临时表t1-move中；
120.v2版本上线后，所有的新进入交易数据将保存到新的数据库db-new和新的表t1-new中；
121.此外会将之前落入临时表t1-move的交易数据迁移到新的表t1-new中，保证数据的完整性；
122.图11是版本v3阶段数据库流向示意图：
123.v3实施阶段：在v3版本执行后，新进入的交易数据全部保存在新的数据库db-new和新表t1-new中，最终迁移完成。
124.特别说明：
125.从老的数据库迁移到新的数据库时，没有将新进入的数据直接落入新数据库的表t1-new中，而是先存入新数据库的临时表t1-move中，原因是如果在实施过程中发生任何异常需要紧急回退时，我们只需将数据源切回老的数据源，将t1-move临时表中的数据同步过去就好，不会导致数据错乱难以核对校验，是我们采取的一种异常补偿机制，技术方案的优化。相较于现有常见的数据库迁移直接切换方式，具有更好的容错性，数据核对更加简洁。
126.最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。