Business database architecture upgrading test method and system

Abstract

The invention relates to a business database architecture upgrading test method and system, and the method comprises the following steps: S1, synchronizing the total data of a to-be-upgraded business database in a production environment to a parallel environment, and guaranteeing the real-time consistency of the data of the production environment and the parallel environment through real-time increment synchronization; s2, stopping real-time increment synchronization, capturing data change information and original flow information in a production environment, and storing the data change information and the original flow information in a preset comparison library; and S3, replaying the traffic in the comparison library to the parallel environment, storing the replayed traffic information to the comparison library, and comparing the data generated by the production environment and the parallel environment with the traffic after the traffic is replayed. Compared with the prior art, the method adopts a mode of scene verification and overall regression verification, and has the advantages of complete isolation of a parallel environment and a production environment and the like.

Description

Technical Field

[0001] The present invention relates to the field of database technology, and in particular to a business database architecture upgrade testing method and system. Background Art

[0002] During the period of rapid business development, the amount of data is growing rapidly. Due to the limitations of its own architecture, traditional single databases can easily become the capacity or performance bottleneck of the entire system. In this case, upgrading distributed databases becomes the first choice. During the database upgrade process, applications and data structures must also be adapted accordingly. How to ensure that the application behavior and data generated after the upgrade remain consistent with those before the upgrade has always been a difficult point.

[0003] The existing solution is a trial run, that is, deploying an upgraded system outside the existing system, first processing a small amount of business on the upgraded system, and then gradually increasing the business volume. The limitation of this solution is that a small amount of business in the early stage cannot cover all business scenarios. If problems are found after a large number of businesses are switched, it may cause immeasurable losses.

[0004] In summary, there is currently a lack of a testing method for business database architecture upgrade scenarios to solve or partially solve the aforementioned problems. Summary of the invention

[0005] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a business database architecture upgrade testing method and system to solve or partially solve the problem of the current lack of testing methods for business database architecture upgrade scenarios.

[0006] The purpose of the present invention can be achieved by the following technical solutions:

[0007] One aspect of the present invention provides a business database architecture upgrade test method, comprising the following steps:

[0008] Step S1, synchronizing the full amount of data of the business database to be upgraded in the production environment to the parallel environment, and ensuring that the data of the production environment and the parallel environment remain consistent in real time through real-time incremental synchronization;

[0009] Step S2, stop real-time incremental synchronization, capture data change information and original traffic information in the production environment, and store them in a preset comparison library;

[0010] Step S3, replaying the traffic in the comparison library to the parallel environment, saving the replayed traffic information to the comparison library, and comparing the data and traffic generated by the production environment and the parallel environment after the traffic is replayed.

[0011] As a preferred technical solution, the following steps are also included:

[0012] Step S4, reading the data changes of the parallel environment from the comparison library, rolling back one by one, and restoring the parallel environment data to the state before the replay traffic;

[0013] Step S5, repeat steps S2-S4 to implement testing of multiple business scenarios and restore real-time incremental synchronization.

[0014] As a preferred technical solution, the data change information includes the content before the data change, the content after the change and the change time.

[0015] As a preferred technical solution, in step S3, the process of comparing the data and traffic generated by the production environment and the parallel environment includes the following steps:

[0016] Step S301, performing overall comparison and field-by-field comparison on the return messages of the production environment and the parallel environment;

[0017] Step S302, with respect to the data changes in the production environment and the parallel environment, identify the changed tables according to the traffic, parse the key business parameters from the request or return parameters, query the data changes of the production environment related tables during the original traffic period and the parallel environment related tables during the replay traffic period from the comparison library, and compare whether the change path and the final result are consistent.

[0018] As a preferred technical solution, the replay traffic information includes request initiation time, request return time, request message and return message.

[0019] Another aspect of the present invention provides a business database architecture upgrade test system, comprising:

[0020] The data preparation module is used to synchronize the full amount of data of the business database to be upgraded in the production environment to the parallel environment, and ensure that the data of the production environment and the parallel environment remain consistent in real time through real-time incremental synchronization;

[0021] The data change capture module is used to capture data change information and original traffic information in the production environment after stopping real-time incremental synchronization, and store them in the preset comparison library;

[0022] The traffic capture and comparison module is used to replay the traffic in the comparison library to the parallel environment, save the replayed traffic information to the comparison library, and compare the data and traffic generated by the production environment and the parallel environment after the traffic is replayed.

[0023] As a preferred technical solution, it also includes:

[0024] The data rollback module is used to read the data changes of the parallel environment from the comparison library, roll back one by one, restore the parallel environment data to the state before the replay traffic, and resume real-time incremental synchronization.

[0025] As a preferred technical solution, the data change information includes the content before the data change, the content after the change and the change time.

[0026] As a preferred technical solution, the traffic capture and comparison module includes:

[0027] A message comparison unit, used to compare the returned messages of the production environment and the parallel environment as a whole and field by field;

[0028] The data change comparison unit is used to identify the changed tables according to the traffic flow for the data changes in the production environment and the parallel environment, parse the key business parameters from the request or return parameters, query the data changes of the production environment related tables during the original traffic period and the data changes of the parallel environment related tables during the replay traffic period from the comparison library, and compare whether the change path and the final result are consistent.

[0029] As a preferred technical solution, the replay traffic information includes request initiation time, request return time, request message and return message.

[0030] Compared with the prior art, the present invention has at least one of the following beneficial effects:

[0031] (1) Adopting the mode of scenario verification + overall regression verification: The present invention divides the parallelization into large and small cycles: steps S1-S5 is a large cycle, and steps S2-S4 is a small cycle. The small cycle can support on-demand parallelization and parallel verification of each business scenario. After all scenarios are verified one by one in the small cycle, a large cycle can be restarted. At this time, steps S2-S4 are no longer executed according to the business scenario, but all businesses are parallelized for a certain period of time, thereby fully supporting the mode of scenario verification + overall regression verification.

[0032] (2) Complete isolation of the parallel environment and the production environment: The present invention can perform full-volume business parallel verification without affecting the normal operation of the production environment

[0033] (3) Integrate data change capture tools and data synchronization: Small-cycle data rollback ensures data consistency before small-cycle parallelization, and full data migration ensures data consistency before large-cycle parallelization. In addition, because the data change path of the production environment is recorded, the data status before and after the production environment business occurs can be provided, which can be used to compare with the data status after the parallel environment business occurs, so as to achieve accurate comparison of each business result. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 Flow chart of the business database architecture upgrade test method in the embodiment;

[0035] Figure 2 A schematic diagram of a business database architecture upgrade test system in an embodiment;

[0036] Figure 3 A schematic diagram of a parallel environment and a production environment in an embodiment;

[0037] Figure 4 Schematic diagram of small cycle and large cycle in the embodiment. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0039] Example 1

[0040] In view of the problems existing in the above-mentioned prior art, this embodiment provides a business database architecture upgrade test method, see Figure 3 , deploy an upgraded system (hereinafter referred to as the parallel environment) outside the existing system, and completely isolate the application, database, and hardware from the existing system (hereinafter referred to as the production environment). Synchronize the previous data of the production environment at a certain point in time to the parallel environment, and then replay all the business that occurred in the production environment after this point in time in the parallel environment, and check and analyze the execution results of the parallel environment and the production environment.

[0041] This embodiment uses the upgrade of Oracle to distributed OceanBase as an example for explanation.

[0042] See also Figure 1 , the method comprises the following steps:

[0043] Step S1: synchronize the full amount of data of the business database to be upgraded in the production environment to the parallel environment, and ensure that the data in the production environment and the parallel environment remain consistent in real time through real-time incremental synchronization.

[0044] Specifically, a synchronization tool is used to synchronize data. This tool is adapted to databases in parallel environments and production environments. It is preferred that the database manufacturer provide corresponding tools to support data migration from other databases to this database. The tool of this embodiment can support real-time incremental synchronization as well as the suspension and resumption of real-time incremental synchronization. Example: Using OMS that is compatible with OceanBase, it supports data migration from Oracle to OceanBase. To avoid affecting the normal operation of the production environment, OMS is connected to the production environment backup database.

[0045] Step S2, stop real-time incremental synchronization, capture data change information and original traffic information in the production environment, and store them in a preset comparison library.

[0046] Specifically, use the database data change capture (CDC) tool to record data changes, send the changes to the message queue, and the comparison tool consumes the messages to save the content and change time before and after the data change to an independent database (hereinafter referred to as the comparison database) for data change comparison and new database data restoration. This tool is adapted to the database of the new production environment. Example: OceanBase's CDC uses OMS, Oracle's CDC uses OGG, and the message queue uses Kafka. To avoid affecting the normal operation of the production environment, OGG is connected to the production environment backup database.

[0047] Step S3, replay the traffic in the comparison library to the parallel environment, save the replayed traffic information to the comparison library, and compare the data and traffic generated by the production environment and the parallel environment after the traffic is replayed.

[0048] Specifically, use traffic tools to record production environment traffic and replay it to a parallel environment. It is necessary to record the request initiation time, request return time, request message, and return message of the original traffic and the replayed traffic to the comparison library. Use traffic log parsing to capture traffic to avoid affecting the normal operation of the production environment. This tool needs to support recording and replay pause and resume. If the production environment uses a private protocol and there are no ready-made tools, this tool needs to be self-developed. If the production environment uses a standard protocol such as the HTTP protocol, you can choose an existing mature product.

[0049] Specifically, the comparison process includes the following sub-steps:

[0050] Step S301, use a comparison tool to compare the data and traffic return messages generated by the parallel environment and the production environment. The return message comparison is divided into overall comparison and field-by-field comparison. If the overall comparison is consistent, no field comparison is performed. If it is inconsistent, the message needs to be compared field by field, and the fields related to the traffic replay time, such as the sequence number and timestamp, are ignored.

[0051] Step S302, data change comparison requires identifying tables that may change based on traffic, parsing key business parameters from request or return parameters, querying data changes in production environment-related tables during the original traffic period and parallel environment-related tables during the replay traffic period from the comparison library, and comparing whether the change path and final result are consistent.

[0052] Step S4, read the data changes of the parallel environment from the comparison library, roll back one by one, and restore the parallel environment data to the state before the replay traffic.

[0053] Step S5, repeat steps S2-S4 to implement testing of multiple business scenarios and restore real-time incremental synchronization.

[0054] This method is suitable for systems with extremely large amounts of data and where full synchronization takes a long time (for example, more than a week). Systems with small amounts of data can use the method of fully synchronizing data before each parallel operation. This method does not guarantee data consistency before each replay of a transaction, but it guarantees data consistency at the beginning of a small cycle. The comparison tool uses the business occurrence time to extract the data change path based on the assumption that the same data will not be updated concurrently. The insurance industry meets this assumption, that is, the same policy will not have two claims or two preservations at the same time. This method has been verified in the scenario where Oracle is upgraded to distributed OceanBase, and in theory it can be extended to other scenarios.

[0055] This method only needs to deploy the modified system in the parallel environment, without the need to modify the system before modification. It is suitable for situations where the system deployment cost is very high (such as using an all-in-one machine, etc.).

[0056] This solution not only compares interface messages but also compares data, so it is not only applicable to service replay verification but also to batch verification; in particular, it not only compares the final data but also the data change process, which makes it necessary to have branches in scenarios in the financial field where data consistency requirements are extremely high.

[0057] The process of this solution is divided into large and small cycles. The large cycle is suitable for full-scale scenario verification, and the small cycle is suitable for scenario-by-scenario verification. It is very useful in systems with extremely large data volumes (more than 100T or full-scale synchronization time exceeds 1 week), and can speed up the process by more than 3 times (based on 7 days of full-scale data synchronization, 10 scenarios, and 2 days of replay and analysis for each scenario. The existing patented solution requires full synchronization for each scenario, and full-scale scenario verification requires (7+2)*10=90 days. This solution only requires 7+2*10=27, an increase of 90 / 27≈3.4).

[0058] Example 2

[0059] Based on Example 1, see Figure 2 , this embodiment provides a business database architecture upgrade test system, including:

[0060] The data preparation module is used to synchronize the full data of the business database to be upgraded in the production environment to the parallel environment, and ensure that the data in the production environment and the parallel environment remain consistent in real time through real-time incremental synchronization.

[0061] The data change capture module is used to capture data change information and original traffic information in the production environment after stopping real-time incremental synchronization, and store them in a preset comparison library. The data change information includes the content before the data change, the content after the change, and the change time.

[0062] The traffic capture and comparison module is used to replay the traffic in the comparison library to the parallel environment, save the replayed traffic information to the comparison library, and compare the data and traffic generated by the production environment and the parallel environment after the traffic is replayed. The replayed traffic information includes the request initiation time, request return time, request message, and return message.

[0063] The data rollback module is used to read the data changes of the parallel environment from the comparison library, roll back one by one, restore the parallel environment data to the state before the replay traffic, and resume real-time incremental synchronization.

[0064] Preferably, the traffic capture and comparison module includes:

[0065] A message comparison unit, used to compare the returned messages of the production environment and the parallel environment as a whole and field by field;

[0066] The data change comparison unit is used to identify the changed tables according to the traffic flow for the data changes in the production environment and the parallel environment, parse the key business parameters from the request or return parameters, query the data changes of the production environment related tables during the original traffic period and the data changes of the parallel environment related tables during the replay traffic period from the comparison library, and compare whether the change path and the final result are consistent.

[0067] In summary, the present invention has the following characteristics:

[0068] (1) The parallel environment and the production environment are completely isolated: full business parallel verification can be performed without affecting the normal operation of the production environment.

[0069] (2) Divide parallelism into large and small cycles: see Figure 4 The overall process is a large cycle, and steps S2-S4 are a small cycle; the small cycle can support on-demand parallel verification for each business scenario; after all scenarios are verified one by one in the small cycle, a large cycle can be restarted. At this time, steps S2-S4 are no longer executed according to the business scenario, but all businesses are parallelized for a certain period of time, thereby fully supporting the scenario verification + overall regression verification mode.

[0070] (3) Integrate data change capture tools and data synchronization tools: Small-cycle data rollback ensures data consistency before small-cycle parallelization, and full data migration ensures data consistency before large-cycle parallelization. And because the data change path of the production environment is recorded, the data status before and after the production environment business occurs can be provided, which can be used to compare with the data status after the parallel environment business occurs, so as to achieve accurate comparison of each business result.

[0071] Example 3

[0072] This embodiment provides an electronic device, including: one or more processors and a memory, wherein the memory stores one or more programs, and the one or more programs include instructions for executing the business database architecture upgrade test method described in Example 1.

[0073] Specifically, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other hardware required for the business. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to achieve the above Figure 1 Of course, in addition to the software implementation, the present invention does not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0074] Example 4

[0075] This embodiment provides a computer-readable storage medium, including one or more programs for execution by one or more processors of an electronic device, wherein the one or more programs include instructions for executing the business database architecture upgrade testing method described in Example 1.

[0076] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0077] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A business database architecture upgrade test method, characterized in that: The steps include: Step S1, synchronizing the full amount of data of the business database to be upgraded in the production environment to the parallel environment, and ensuring that the data of the production environment and the parallel environment remain consistent in real time through real-time incremental synchronization; Step S2, stop real-time incremental synchronization, capture data change information and original traffic information in the production environment, and store them in a preset comparison library; Step S3, replaying the traffic in the comparison library to the parallel environment, saving the replayed traffic information to the comparison library, and comparing the data and traffic generated by the production environment and the parallel environment after the traffic is replayed.

2. A business database architecture upgrade test method according to claim 1, characterized in that: The following steps are also included: Step S4, reading the data changes of the parallel environment from the comparison library, rolling back one by one, and restoring the parallel environment data to the state before the replay traffic; Step S5, repeat steps S2-S4 to implement testing of multiple business scenarios and restore real-time incremental synchronization.

3. A business database architecture upgrade test method according to claim 1, characterized in that: The data change information includes the content before the data change, the content after the change and the change time.

4. A business database architecture upgrade test method according to claim 1, characterized in that: In step S3, the process of comparing the data and traffic generated by the production environment and the parallel environment includes the following steps: Step S301, performing overall comparison and field-by-field comparison on the return messages of the production environment and the parallel environment; Step S302, with respect to the data changes in the production environment and the parallel environment, identify the changed tables according to the traffic, parse the key business parameters from the request or return parameters, query the data changes of the production environment related tables during the original traffic period and the parallel environment related tables during the replay traffic period from the comparison library, and compare whether the change path and the final result are consistent.

5. A business database architecture upgrade test method according to claim 1, characterized in that: The replay traffic information includes request initiation time, request return time, request message and return message.

6. A business database architecture upgrade test system, characterized in that: include: The data preparation module is used to synchronize the full amount of data of the business database to be upgraded in the production environment to the parallel environment, and ensure that the data of the production environment and the parallel environment remain consistent in real time through real-time incremental synchronization; The data change capture module is used to capture data change information and original traffic information in the production environment after stopping real-time incremental synchronization, and store them in the preset comparison library; The traffic capture and comparison module is used to replay the traffic in the comparison library to the parallel environment, save the replayed traffic information to the comparison library, and compare the data and traffic generated by the production environment and the parallel environment after the traffic is replayed.

7. A business database architecture upgrade test system according to claim 6, characterized in that: Also includes: The data rollback module is used to read the data changes of the parallel environment from the comparison library, roll back one by one, restore the parallel environment data to the state before the replay traffic, and resume real-time incremental synchronization.

8. A business database architecture upgrade test system according to claim 6, characterized in that: The data change information includes the content before the data change, the content after the change and the change time.

9. A business database architecture upgrade test system according to claim 6, characterized in that: The traffic capture and comparison module includes: A message comparison unit, used to compare the returned messages of the production environment and the parallel environment as a whole and field by field; The data change comparison unit is used to identify the changed tables according to the traffic flow for the data changes in the production environment and the parallel environment, parse the key business parameters from the request or return parameters, query the data changes of the production environment related tables during the original traffic period and the data changes of the parallel environment related tables during the replay traffic period from the comparison library, and compare whether the change path and the final result are consistent.

10. A business database architecture upgrade test system according to claim 6, characterized in that: The replay traffic information includes request initiation time, request return time, request message and return message.

Images