一种灾备数据库的切换方法和切换系统与流程

1.本发明涉及数据库管理技术领域，具体涉及一种灾备数据库的切换方法和切换系统。


背景技术：

2.为保障业务的连续性，通常设有主数据库(生产数据库)和备数据库(灾备数据库)。通过灾备数据库解决生产连续性的问题，在生产数据库出现故障时，切换到灾备数据库中继续处理，灾备数据库通常与生产数据库保持实时复制。为了提高系统的稳健性，生产数据库和灾备数据库通常异地设置。
3.但是现有技术中，灾备数据库与生产数据的复制通过应用层协议来完成，效率普遍不高，存在同步延迟的现象，延迟时间从几分钟到几十分钟不等。因此，切换过程中，造成灾备数据库缺失延迟时间内的数据，在下一次生产数据库恢复时，再同步该部分数据。这就造成延迟时间内的丢失数据无法进行访问或修改，造成业务的异常，如业务不正确或重复受理等。业务异常进一步导致大量的投诉、数据稽核和异常处理等大量维护问题，造成服务水平下降，体验下降和运维成本上升。


技术实现要素：

4.针对现有技术中存在的上述技术问题，本发明提供一种灾备数据库的切换方法和切换系统，在有数据丢失风险时，向连接请求的发送方返回拦截信息，避免了错误的连接和错误的数据，提高使用体验。
5.本发明公开了一种灾备数据库的切换方法，所述切换方法包括：在灾备数据库切换时，拦截连接请求；判断所述连接请求是否有数据丢失的风险；若是，向连接请求的发送方返回拦截信息；若否，将连接请求转发给已启用的数据库。
6.优选的，数据丢失风险的分析方法包括：
7.获取历史连接；
8.根据历史连接建立分析数据，所述分析数据包括一定时间内与所述连接请求相应的连接数据；
9.判断灾备数据库切换与上一次相应连接数据的时间差是否小于第一域值，所述第一域值大于或等于灾备数据库的同步时间延时；
10.若时间差小于第一域值，数据有丢失风险。
11.优选的，所述上一次连接数据的类型为修改数据。
12.优选的，根据历史连接建立分析数据的方法包括：
13.建立分析数据列表，并按键值对历史连接进行分析；
14.判断当前历史连接在分析数据列表中是否有相应的记录；
15.若有记录，更新所述记录的时间戳。
16.若没有记录，添加新记录，并保存时间戳。
17.优选的，所述键值包括以下任一维度或它们的组合：用户名、帐户、用户id和手机号码。
18.优选的，所述连接请求包括交易请求，切换方法包括：
19.根据所拦截的连接请求中，获得用户id；
20.将所述用户id与所述分析数据的用户id进行匹配；
21.若匹配成功，判断灾备数据库切换与上一次相应连接数据的时间差是否小于第一域值；
22.若时间差小于第一域值，数据有丢失风险，向请求方发送拦截信息；
23.若时间差大于或等于第一域值，将连接请求转发给已启用的数据库；
24.若匹配不成功，将连接请求转发给已启用的数据库。
25.本发明还提供一种用于实现上述灾备数据库切换方法的切换系统，包括拦截模块和风险评估模块，
26.所述拦截模块用于在容灾数据库切换时，拦截连接请求；
27.所述风险评估模块用于判断所述连接请求是否有数据丢失的风险；若是，向连接请求的发送方返回拦截信息；若否，将连接请求转发给已启用的数据库。
28.优选的，所述切换系统还包括网关和业务管理模块，所述拦截模块设置在网关内，所述业务管理模块用于生产数据库和容灾数据库的管理。
29.优选的，所述切换系统还包括采集模块和连接分析模块，
30.所述采集模块设置在业务管理模块内，用于采集历史连接；
31.所述连接分析模块用于根据历史连接建立分析数据；
32.所述风险评估模块用于根据灾备数据库切换与上一次连接数据的时间差，分析数据丢失的风险。
33.优选的，将一定时间内的分析数据加载到缓存中，灾备数据库切换和缓存中上一次连接数据的时间差小于第一域值时，数据有丢失风险。
34.与现有技术相比，本发明的有益效果为：通过对连接请求的拦截和分析，在有数据丢失风险时，向连接请求的发送方返回拦截信息，避免了错误的连接和错误的数据，提高使用体验；对于没有数据丢失风险的正常连接请求，进行正常处理，确保了数据库业务的连续性。
附图说明
35.图1是本发明的灾备数据库的切换方法流程图；
36.图2是数据丢失风险的分析方法流程图；
37.图3是数据丢失风险的分析逻辑框图；
38.图4是是建立分析数据的方法流程图；
39.图5是本发明的切换系统的逻辑框图。
具体实施方式
40.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是
本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
41.下面结合附图对本发明做进一步的详细描述：
42.一种灾备数据库的切换方法，如图1所示，所述切换方法包括：
43.步骤101：在灾备数据库切换时，拦截连接请求。其中，灾备数据库切换是指生产数据库切换到灾备数据库，或者灾备数据库切换到生产数据库。
44.步骤102：判断所述连接请求是否有数据丢失的风险。
45.若是，执行步骤103：向连接请求的发送方返回拦截信息。拦截信息提醒连接请求的发送方，例如提醒数据可能存在异常，建议过段时间再继续访问等。
46.若否，执行步骤104：将连接请求转发给已启用的数据库。
47.通过对连接请求的拦截和分析，在有数据丢失风险时，向连接请求的发送方返回拦截信息，避免了错误的连接和错误的数据，提高使用体验；而对于没有数据丢失风险的正常连接请求，进行正常处理，确保了数据库业务的连续性。
48.如图2和图3所示，步骤102中，数据丢失风险的分析方法包括：
49.步骤201：获取历史连接。在一个具体实施例中，设置业务管理模块，用于接收连接请求，管理生产数据库和灾备数据库，业务管理模块接收和处理连接请求时，对历史连接进行采集。其中历史连接是指，业务管理模块已处理的连接请求。
50.步骤202：根据历史连接建立分析数据，所述分析数据包括一定时间内与所述连接请求相应的连接数据。例如1小时内的连接数据，相应的连接数据是指连接请求中采用的连接数据，例如连接请求用于查询或修改所述连接数据。
51.步骤203：判断灾备数据库切换与上一次相应连接数据的时间差是否小于第一域值，所述第一域值大于灾备数据库的切换时间延时。在一个具体实施例中，同步时间延时为10分钟，第一域值设为30分钟，即上一次相应连接数据与灾备数据库切换的时间差小于30分钟时，判断为有数据丢失风险；时间差大于30分钟时，判断为正常连接。
52.若小于第一域值，执行步骤204：判断数据有丢失风险。
53.若大于或等于第一域值，执行步骤205：判断数据没有丢失风险。
54.其中，切换时间延时包括灾备数据库与生产数据库的同步延时。步骤203中，还可以对连接数据的类型进行判定，上一次相应连接数据为修改数据，如数据的增、改和删；而查询类的连接数据，不会对数据库中的数据产生实质影响，因此仍然可以正常访问。
55.步骤202中，根据历史连接建立分析数据的方法可以包括：
56.步骤221：按键值，对连接请求进行分析，并按连接请求的时间进行记录，获得统计数据。
57.步骤222：从统计数据中，获取一定时间内的分析数据。
58.但不限于此，如图4所示，也可以通过以下方式建立分析数据：
59.步骤231：建立分析数据列表，并按键值对历史连接进行分析。在一个具体实施例中，键值以下任一维度或它们的组合：用户名、帐户、用户id和手机号码，所述连接请求可以是交易请求，即本发明的方法可以应用到交易系统中。在一个具体实施例中，从业务管理模块中采集历史连接。
60.步骤232：判断当前历史连接在分析数据列表中是否有相应的记录。
61.若有记录，执行步骤233：更新所述记录的时间戳。
62.若没有记录，执行步骤234：添加新记录，并保存时间戳。
63.从而实时对分析数据列表进行更新。
64.本发明还提供一种用于实现上述灾备数据库切换方法的切换系统，如图5所示，包括拦截模块11和风险评估模块12，
65.拦截模块11用于在容灾数据库切换时，拦截连接请求；
66.风险评估模块12用于判断所述连接请求是否有数据丢失的风险；若是，向连接请求的发送方返回拦截信息；若否，将连接请求转发给已启用的数据库。
67.本发明的切换系统还包括网关1和业务管理模块2，拦截模块11设置在网关1内，业务管理模块2用于生产数据库21和容灾数据库22的管理。业务管理模块2内还设有采集模块23，采集模块用于采集历史连接，即将业务管理模块处理的连接请求发送到连接分析模块3，连接分析模块3用于根据历史连接建立分析数据31，分析数据31包括一定时间内的连接数据。风险评估模块12用于根据灾备数据库切换与上一次连接数据的时间差，分析数据丢失的风险。在一个具体实施例中，根据分析数据和灾备数据库切换时间点建立匹配规则，将连接请求与匹配规则进行匹配，符合匹配规则时，判定为具有数据丢失的风险。
68.其中，可以将分析数据或匹配规则加载到缓存中，根据灾备数据库切换和缓存中上一次连接数据的时间差，分析数据丢失的风险。
69.实施例
70.以电信业务为例，以用户id为键值，处理交易请求时，切换方法包括：
71.步骤301：拦截连接请求，并从连接请求中获得用户id。
72.步骤302：将所述用户id与所述分析数据的用户id进行匹配。其中，分析数据为一定时间内(如1小时)的用户交易数据，包括用户id、交易时间和交易类型。
73.若匹配成功，执行步骤303：判断灾备数据库切换与上一次相应连接数据(即用户上一次交易)的时间差是否小于第一域值。
74.若小于第一域值，执行步骤304：数据有丢失风险，向请求方发送拦截信息。
75.若时间差大于或等于第一域值，执行步骤305：将连接请求转发给已启用的数据库。在具体实施例中，将连接请求发送给业务管理模块，由业务管理模块将连接请求分配给已启用的数据库。
76.若匹配不成功，执行步骤305。
77.一个承载3000万用户的业务系统，日交易量在1000万笔左右，而且主要集中在白天8小时内。在该场景中，业务系统在容灾切换过程中，按切换延迟10分钟计算，在10分钟内业务量大概有20万笔，其中交易非查询类的约2w笔(10％)，影响约2w用户的正常交易需需求。这些异常数据的稽核和处理完成需要至少3天左右的时间，而且还需要投入大量的客服和维护人员。
78.而采用本实施例的方法进行分析和拦截后，可以精确计算10s到1分钟内的用户业务，可以精确定位和跟踪90％以上的用户，提前进行业务拦截限制和拦截提醒。提高了用户满意度，减少了系统后台维护处理的工作量。
79.其中，连接分析模块3可以部署在分析集群中，生产数据库和灾备数据库部署在esb集群中。
80.以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。