Database version upgrade traffic playback test method, device and program product

Abstract

The embodiment of the application provides a database version upgrade traffic playback test method, device and program product, and relates to the field of database test. The method comprises the following steps: obtaining traffic data of a source database by deploying a benchmark test instance and a comparison test instance; applying a multi-dimensional filtering strategy to the traffic data to generate a filtered data set; synchronously playing back the filtered data set in the benchmark test instance and the comparison test instance, and recording execution results; and generating a compatibility problem report based on the execution results. The method is used to improve the effectiveness and standardization of test input data, reduce invalid traffic interference, reduce playback cost, shorten the test cycle, and improve the accuracy of database version upgrade evaluation and the effect of business continuity guarantee capability.

Description

Technical Field

[0001] This application relates to the field of database testing, and in particular to a database version upgrade traffic replay testing method, device, and program product. Background Technology

[0002] In distributed database version upgrade testing, compatibility verification of the old and new versions of the database is usually performed by manually constructing test cases or by replaying the traffic collected from production Structured Query Language (SQL).

[0003] However, existing traffic replay solutions often fail to accurately maintain the original transaction sequence and data correlation in high-concurrency, complex transaction, and cross-node scenarios, easily leading to distorted replay results. At the same time, the processing and difference analysis of massive traffic often remain at the result level, resulting in limited testing efficiency and difficulty in accurately locating real compatibility issues.

[0004] Therefore, how to improve the accuracy and effectiveness of real business traffic replay in database version upgrade testing, so as to reliably identify compatibility risks, has become a technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a database version upgrade traffic replay testing method, device, and program product to improve the accuracy of real business traffic replay, thereby enhancing the targeting and effectiveness of traffic usage during version upgrade compatibility verification.

[0006] In a first aspect, embodiments of this application provide a database version upgrade traffic replay testing method, including:

[0007] Traffic data from the source database is obtained by deploying benchmark test instances and comparison test instances;

[0008] A multidimensional filtering strategy is applied to the traffic data to generate a filtered dataset;

[0009] The filtered dataset is synchronously replayed in the benchmark test instance and the comparison test instance, and the execution results are recorded.

[0010] A compatibility issue report is generated based on the execution results.

[0011] In one possible embodiment, a multidimensional filtering strategy is applied to the traffic data, including:

[0012] Traffic data is cleaned by time dimension, and structured query language (SQL) statements that are not in the specified time period are removed;

[0013] Traffic data is cleaned according to database dimensions, and structured query language (SQL) statements from non-business databases are removed;

[0014] Traffic data is cleaned by keyword tags, and structured query language (SQL) statements containing invalid operation identifiers are removed.

[0015] In one possible embodiment, before cleaning traffic data by keyword tags and removing Structured Query Language (SQL) statements containing invalid operation identifiers, the process includes:

[0016] Perform Structured Query Language (SQL) syntax validation on traffic data and remove SQL statements with syntax errors.

[0017] In one possible embodiment, the multidimensional filtering strategy includes at least one of the following:

[0018] Semantic coverage filtering of traffic data is performed based on SQL fingerprint calculation using the structured query language.

[0019] Filtering is performed based on the association between SELECT statements and DML statements.

[0020] In one possible embodiment, synchronously replaying the filtered dataset in the benchmark test instance and the comparison test instance includes:

[0021] The static data of the benchmark test instance is synchronized to the comparison test instance using a data migration tool;

[0022] Verify the consistency of table structure and data between the benchmark test instance and the comparison test instance;

[0023] If the table structure and data of the benchmark test instance and the comparison test instance are consistent, group replay is performed on the benchmark test instance and the comparison test instance.

[0024] In one possible embodiment, group playback specifically includes:

[0025] Based on the relationships between data tables, structured query language (SQL) statements are clustered to form table groups;

[0026] Parallel playback of Structured Query Language (SQL) statements for different table groups, and serial playback of Structured Query Language (SQL) statements for the same table group.

[0027] In one possible embodiment, after applying a multidimensional filtering strategy to the traffic data to generate a filtered dataset, the process includes:

[0028] Dynamic replacement of auto-incrementing columns is performed on the filtered dataset. Specifically, dynamic replacement of auto-incrementing columns includes:

[0029] After replaying the INSERT statement, record the auto-increment column values ​​generated by the old and new versions of the database instance;

[0030] In subsequent playbacks, the auto-incrementing column values ​​in the original traffic will be replaced with the actual values ​​of the corresponding instances.

[0031] In one possible embodiment, the method further includes:

[0032] The replay results of the benchmark test instance groups in the target storage unit are compared with the replay results of the comparison test instance groups to obtain a comparison result list;

[0033] Based on the preset difference classification rules, normal differences and compatibility issues are distinguished in the comparison result list. Normal differences include at least differences in execution efficiency and differences in the order of returned results, while compatibility issues include at least differences in execution errors, differences in returned result data, and differences in the number of rows affected.

[0034] Based on compatibility issues and fixes from historical test data, a knowledge graph of compatibility issues is constructed.

[0035] Based on knowledge graphs, compatibility issues in playback results are traced back to their source and repair suggestions are generated.

[0036] Secondly, embodiments of this application provide a database version upgrade traffic replay testing device, comprising:

[0037] The acquisition module is used to obtain traffic data from the source database by deploying benchmark test instances and comparison test instances;

[0038] The application module is used to apply a multi-dimensional filtering strategy to the traffic data and generate a filtered dataset.

[0039] The recording module is used to synchronously replay the filtered dataset in the benchmark test instance and the comparison test instance, and record the execution results.

[0040] The generation module is used to generate a compatibility issue report based on the execution results.

[0041] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0042] The memory stores computer-executed instructions;

[0043] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0044] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0045] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0046] This application provides a database version upgrade traffic replay testing method, device, and program product. By acquiring traffic data from the source database and applying a multi-dimensional filtering strategy to generate a filtered dataset, the filtered dataset is synchronously replayed in benchmark test instances and comparison test instances, and the execution results are recorded. Then, a compatibility issue report is generated based on the execution results. This method can selectively filter and consolidate the original massive traffic, improve the data quality and usability used for version upgrade replay testing, and thus provide more effective data support for compatibility verification of new and old database versions, improving the accuracy of compatibility risk identification and the efficiency of test analysis. Attached Figure Description

[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0048] Figure 1 A flowchart illustrating a database version upgrade traffic replay test method provided in this application embodiment;

[0049] Figure 2 A schematic diagram of the architecture of a database version upgrade traffic replay test system provided in this application embodiment;

[0050] Figure 3 A flowchart illustrating another database version upgrade traffic replay test method provided in this application embodiment;

[0051] Figure 4 A flowchart illustrating a multi-level filtering method provided in an embodiment of this application;

[0052] Figure 5 A schematic diagram of a database version upgrade traffic replay testing device provided in this application embodiment;

[0053] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0054] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0055] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0056] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0057] First, let's explain some of the terms used in this application:

[0058] Structured Query Language (SQL) is the standard language for relational databases, used for querying, updating, defining, and controlling data. SQL is a high-level declarative language with a highly unified and portable syntax.

[0059] Data Manipulation Language (DML) is the core sub-language of Structured Query Language used to manipulate data in a database. Its main function is to perform CRUD operations on data.

[0060] The INSERT statement is a basic command used in databases to add new records to tables. It belongs to the data manipulation language and supports single or batch writing.

[0061] Distributed database version upgrade testing falls under the cross-disciplinary technical field of database operations and maintenance and software testing. It is primarily applied in business systems with high requirements for transaction consistency and business continuity, such as financial transactions, e-commerce orders, and internet accounts. These scenarios typically rely on production databases, traffic collection nodes, and test environments for compatibility verification. It requires obtaining real SQL traffic without interrupting live network operations and using it as input for upgrade testing.

[0062] Existing database version upgrade testing typically employs two methods: one is to manually construct test cases to verify typical CRUD operations and some transaction flows; the other is to collect SQL traffic from the production environment and then replay it in the test environment to compare how the database handles the same business requests before and after the upgrade. The basic idea is to first record the statements executed by the source database and related information, and then use these statements in subsequent tests to approximate real business load as closely as possible.

[0063] However, in high-concurrency, complex transaction, and cross-node scenarios of distributed databases, existing database version upgrade testing methods tend to include a large number of system maintenance statements, low-value queries, abnormal statements, or statements with repetitive semantics in the test data. This results in redundant replay data, excessive resource consumption, and prolonged testing cycles. At the same time, redundant traffic dilutes core business operations, causing truly critical SQL queries to be overwhelmed, reducing the relevance of compatibility verification.

[0064] Therefore, improving the validity and availability of traffic data during database version upgrade testing has become a pressing technical problem. To address this issue, a database version upgrade traffic replay testing method is proposed, which integrates a multi-dimensional filtering strategy, a dual-instance consistent replay mechanism, auto-incrementing column dynamic replacement technology, and an intelligent comparison and analysis system. This method reduces interference from invalid traffic, resolves replay consistency issues in a distributed environment, and enables intelligent identification of compatibility defects and generation of optimization suggestions.

[0065] The execution entity of this database version upgrade traffic replay test method can be, for example, a test system. Optionally, the test system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the test system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the test system.

[0066] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0067] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0068] Figure 1 This is a flowchart illustrating a database version upgrade traffic replay testing method provided in an embodiment of this application. Figure 1 As shown, the method includes:

[0069] S101 obtains traffic data from the source database by deploying benchmark test instances and comparison test instances.

[0070] For example, a benchmark instance can be a test environment that hosts an older version of the database, whose static data corresponds to the table structure, basic table data, and key index information of the source database at a specified collection time.

[0071] For example, the comparison test instance could be a test environment hosting a new version of the database, whose static data is migrated from the benchmark test instance.

[0072] For example, the source database can be the object to be upgraded.

[0073] For example, traffic data can be SQL statements and their related metadata recorded in the source database. The related metadata includes at least the SQL text, execution time, user information, and statement type.

[0074] Optionally, the testing system can obtain raw data based on a traffic acquisition and analysis server by establishing read-only access connections with the source database, accessing audit records, or parsing log information. It should be understood that the above examples are for illustrative purposes only and are not limiting.

[0075] Optionally, the testing system can standardize the raw records. Specifically, records from different sources can be mapped to a unified set of fields, which may include information such as record identifier, data source, database instance identifier, database name, execution time, SQL text, statement type, user identifier, transaction identifier, and execution status.

[0076] Optionally, for records with missing fields, the test system can fill in the blanks according to preset rules and add source tags to ensure that data from different sources can be parsed uniformly in the same processing flow. For time fields, they can be uniformly converted to the same time zone and the same time precision for subsequent processing. For SQL text, the original text can be retained and the necessary formatting can be performed to reduce subsequent processing errors.

[0077] Optionally, the testing system can retrieve traffic data in pagination or batches during the collection process. If there is abnormal text in the collected records, it can first perform verification according to the encoding rules. Records that fail verification can be further judged in subsequent processing.

[0078] S102, apply a multi-dimensional filtering strategy to the traffic data to generate a filtered dataset.

[0079] In one possible implementation, the multidimensional filtering strategy includes at least one of the following: semantic coverage filtering of traffic data based on structured query language (SQL) fingerprint calculation; filtering based on the association between SELECT statements and DML statements.

[0080] For example, the Structured Query Language (SQL) fingerprint calculation can first parameterize the SQL statements entering the filtering module, replacing constant values ​​with placeholders, so that statements with the same semantics but different parameters are grouped into the same semantic category. Then, the MD5 (Message-Digest Algorithm 5) value is calculated for the parameterized statements to form the SQL fingerprint, and the duplicate semantic statements are identified and deduplicated based on the SQL fingerprint.

[0081] For example, selecting the relationship between a SELECT statement and a DML statement can involve parsing the data tables, related conditions, and contextual operations involved in the SELECT statement, determining whether the SELECT statement has a direct business relationship with the preceding or subsequent DML statements, and retaining related queries and eliminating redundant queries that are not related to business updates.

[0082] Optionally, the testing system can receive the SQL logs output from the source database, send each Structured Query Language (SCL) SQL statement into the parsing unit, first complete lexical and syntactic normalization, then extract the table name, condition fields, operation type and parameter position, and uniformly replace variable parameters with preset placeholders to obtain standardized statements.

[0083] Optionally, for the standardized statement, the test system can call the hash calculation module to generate the corresponding MD5 fingerprint and write the Structured Query Language (SQL) fingerprint into the fingerprint index table. When the same SQL fingerprint is detected, the statement is judged as semantically duplicated data and will not be included in the replay set. When a new SQL fingerprint is detected, the statement is retained as valid data covering different business semantics.

[0084] Optionally, for SELECT statements, the test system can extract the data tables accessed and the primary keys, foreign keys, or filtering conditions shared with DML statements based on the execution context. When the SELECT statement is directly related to insert, update, or delete operations, it is marked as retained data; when the SELECT statement is only used for system inspection, statistical probing, or independent query and does not form a business loop with DML operations, it is removed from the filtered dataset.

[0085] After adopting the above method, the number of synonymous and repeated structured query language (SQL) statements in the filtered dataset is significantly reduced, the business link between SELECT queries and DML operations is preserved, the redundancy of replay data is reduced, the test resource consumption is reduced accordingly, and the visibility of key transaction statements in the test set is enhanced, thereby improving the effectiveness of the input data for database version upgrade tests.

[0086] In one possible embodiment, the testing system can clean traffic data by time dimension, removing structured query language (SQL) statements that are not within a specified time period; clean traffic data by database dimension, removing structured query language (SQL) statements that are not within the business database; and clean traffic data by keyword tags, removing structured query language (SQL) statements that contain invalid operation identifiers.

[0087] For example, the time dimension can be used to filter traffic data according to a preset time range, and the specified time period can correspond to the peak business period or the business period that matches the test target.

[0088] For example, the database dimension can be used to identify traffic data based on database name, database type, or whitelist rules. Non-business databases include system databases, test databases, or other databases unrelated to business.

[0089] For example, keyword tags can be preset invalid operation identifiers in structured query language (SQL) statements.

[0090] Optionally, the testing system can compare timestamps with preset time ranges to remove Structured Query Language (SQL) statements that do not fall within the specified time period from the processing set. Then, it can match the database identifier field with the business database whitelist to filter out SQL statements originating from non-business databases.

[0091] Optionally, the testing system can perform text tag recognition on the retained Structured Query Language (SQL) statements. If a statement contains a preset invalid operation identifier, it is determined to be invalid traffic and is removed. After the above cleaning, the output filtered dataset retains only the core business Structured Query Language (SQL) statements related to version upgrade testing, and can be written to the target storage unit for playback testing.

[0092] By using the above methods, the redundancy of replay data is reduced, the proportion of core business structured query language (SQL) is increased, the clarity of the correspondence between test inputs and upgrade verification targets is improved, and the filtered results are easier to analyze and store later.

[0093] In one possible implementation, before cleaning traffic data by keyword tags and removing Structured Query Language (SQL) statements containing invalid operation identifiers, the testing system can perform SQL syntax validation on the traffic data and remove SQL statements with syntax errors.

[0094] Optionally, the testing system can perform lexical and syntactic analysis on the collected SQL text using parsing tools and generate parsing results. If the parsing results show that the statement cannot be correctly constructed into a syntax tree, the statement is judged to have a syntax error and is removed. For traffic data from different database protocols or different business systems, a combination of rule validation and syntax tree analysis can also be used.

[0095] By using the above methods, we can ensure the consistency and executability of subsequent processed objects, improve the stability of the correspondence between SQL text and database execution semantics in the filtered dataset, and reduce the number of execution failure records generated during replay.

[0096] S103, synchronously replay the filtered dataset in the benchmark test instance and the comparison test instance, and record the execution results.

[0097] Optionally, the testing system can store the filtered dataset in a target storage unit. For example, the target storage unit can be a database table, a dedicated directory in a file system, or a data partition in object storage.

[0098] In one possible embodiment, if the target storage unit is a database, the test system can pre-build a filtering result table. This table should include at least the record primary key, task identifier, timestamp, source instance identifier, database name, execution status, and filtering trajectory fields. The test system can use batch insertion to write the same batch of filtering results and can also create indexes on the timestamp, transaction identifier, and database name fields. For large-scale traffic data, it can also be partitioned and stored by date, task identifier, or business database name.

[0099] In another exemplary implementation, if the target storage unit is a file system, the test system can serialize the filtered dataset into a structured file, such as a text file stored line by line or a binary file with field definitions, and generate a directory hierarchy according to the task identifier, collection date and business library name.

[0100] Optionally, the testing system can set a file scrolling threshold, such as automatically splitting into new files when the number of records reaches a preset limit or the file size reaches a preset capacity, and recording the order, start and end time, and number of records of each file in the manifest file.

[0101] Optionally, the testing system can calculate the total number of records, total number of transactions, SQL type distribution, and file or table shard identifier for each batch of data, and write the statistical results to the task metadata table or manifest file. After writing, the testing system can also verify whether the number of records written is consistent with the number of records in the memory result set, whether the index was successfully created, whether the file is readable, and whether the fields of the randomly sampled records are complete.

[0102] For example, if a write failure, field misalignment, or abnormal transaction order is detected, the current batch of writes is rolled back or the batch of data is re-exported until the filtered dataset in the target storage unit meets the requirements for subsequent playback.

[0103] As one possible implementation, the test system can use a data migration tool to synchronize the static data of the benchmark test instance to the comparison test instance. Then, it verifies the consistency of the table structure and data between the benchmark test instance and the comparison test instance. If the table structure and data of the benchmark test instance and the comparison test instance are consistent, it performs grouped replay on the benchmark test instance and the comparison test instance.

[0104] For example, a data migration tool can be a program, script, or middleware component that has the capabilities of data extraction, format conversion, batch distribution, and incremental synchronization.

[0105] Optionally, the testing system can connect to the benchmark test instance using a data migration tool, selectively read all static datasets within the instance, and complete field parsing, structure reading, and temporary caching. Mapping and conversion are performed based on the database structure, storage format, and field naming conventions of the benchmark test instance, eliminating redundant fields. Then, the processed benchmark static data is batch-pushed and written to the corresponding storage media (database, configuration file, local cache, cloud configuration library) of the benchmark test instance using the data migration tool.

[0106] Optionally, after the migration is complete, the testing system can compare the baseline source data with the target instance's data entry one by one, verifying whether the number of records, field values, and hash checksums are completely consistent, and output a synchronization result report. If problems such as write failure, format incompatibility, or primary key conflict occur during the synchronization process, a transaction rollback will be automatically triggered to restore the original data of the comparison instance.

[0107] Optionally, the testing system can use a combination of metadata comparison and data verification code to check whether the static data is consistent. If the table structure, field types, primary key constraints, NOT NULL constraints, and values ​​of key business fields are consistent, the static data can be determined to be consistent.

[0108] Optionally, assuming the table structure and data of the benchmark and comparison test instances are consistent, the testing system can cluster the Structured Query Language (SQL) statements in the filtered dataset according to the table relationships, forming multiple table groups. Then, grouped replays are executed synchronously on both the benchmark and comparison test instances.

[0109] In one possible implementation, the testing system can cluster Structured Query Language (SQL) statements into table groups based on the relationships between data tables; it can replay SQL statements from different table groups in parallel, and replay SQL statements from the same table group serially.

[0110] For example, data table relationships can be association rules that determine table-level dependencies between Structured Query Language (SQL) statements.

[0111] Optionally, the testing system can identify whether there are direct or indirect dependencies between the data tables involved in each Structured Query Language (SQL) statement based on the table names, join conditions, foreign key references, and shared table information in the SQL statement, and group SQL statements with common dependent tables into the same table group.

[0112] Optionally, the testing system can assign different replay threads or replay channels to different table groups. For Structured Query Language (SQL) statements within the same table group, the testing system can send them to the target database for execution sequentially according to the original execution order collected. If there are explicit transaction boundaries within the same table group, the testing system can use the transaction boundaries as a serial control unit, switching to the next SQL statement only after the transaction is committed or completed.

[0113] In this way, tightly coupled Structured Query Language (SQuery) SQL statements are aggregated into the same table group and replayed sequentially, while loosely coupled SQuery Language SQL statements can be executed concurrently. This ensures that the replay process balances execution consistency and replay efficiency. This reduces unnecessary concurrency conflicts, maintains transaction semantic stability, and shortens the overall replay time for distributed database version upgrade testing.

[0114] By employing the methods described above, the consistent order of related statements is ensured, reducing the interference of cross-table concurrency conflicts on test results. Verifying the consistency of table structure and data between the benchmark test instance and the comparison test instance improves the comparability and accuracy of version upgrade test results.

[0115] As one possible implementation, a multi-dimensional filtering strategy is applied to the traffic data to generate a filtered dataset. After that, the test system can perform dynamic replacement of the auto-incrementing columns on the filtered dataset.

[0116] Optionally, after replaying the INSERT statement, the test system can record the auto-increment column values ​​generated by the old and new versions of the database instance. In subsequent replays, the auto-increment column values ​​in the original traffic can be replaced with the actual values ​​of the corresponding instances.

[0117] Optionally, the test system can read the INSERT statement from the target storage unit and simultaneously send isomorphic insert requests to both the old and new version database instances. After the instances complete the insert, the test system can extract the auto-increment column value based on the returned results and establish a mapping relationship with the table name, primary key placeholder, statement sequence number, and instance identifier as keys.

[0118] Optionally, if the SQL statement replayed subsequently contains a reference field, related field, or lookup condition corresponding to the auto-increment column, the test system can replace the auto-increment column value in the original traffic with the actual value generated by the current instance based on the mapping relationship, and then submit it to the corresponding database instance for execution.

[0119] By using the above methods, the replay data can be kept in correspondence with the actual state of the instance, thus ensuring the availability and continuity of the filtered dataset during the replay process.

[0120] In this embodiment, by collecting real business traffic from the source database and performing multi-dimensional filtering on the traffic, the core business traffic is persistently saved in a searchable structure. This allows the input data used for subsequent version upgrade replay tests to be more focused on the actual business chain, and the data format is consistent, the source is traceable, and the transaction order is recoverable. It should be understood that the above example is only for demonstration and is not limiting.

[0121] In some embodiments, the testing system can also compare the replay results of benchmark test instance groups in the target storage unit with the replay results of comparison test instance groups to obtain a comparison result list. Then, based on preset difference classification rules, normal differences and compatibility issues in the comparison result list are distinguished, and a compatibility issue knowledge graph is constructed based on compatibility issues and remediation methods in historical test data. Then, based on the knowledge graph, the compatibility issues in the replay results are traced back to their source and remediation suggestions are generated. The normal differences include at least differences in execution efficiency and the order of returned results, and the compatibility issues include at least differences in execution errors, differences in returned result data, and differences in the number of rows affected.

[0122] For example, the group replay results may include test metrics such as execution time, returned dataset, error messages, number of rows affected by the SQL, and execution status codes.

[0123] For example, the preset difference classification rules can be a pre-configured rule system that can be embedded in the program or configuration file, used to distinguish between test differences as normal differences and compatibility issues.

[0124] For example, normal differences can be reasonable differences that do not affect business correctness, do not cause business anomalies, and do not require repair.

[0125] For example, compatibility issues can be unusual differences that affect business correctness, data consistency, and business availability.

[0126] Optionally, the testing system can group benchmark test instances and comparison test instances, such as query statement groups or update statement groups. Then, it reads the full replay results of the benchmark and the full replay results of the test under the same group from the target storage unit, uses the unique identifier of the test case as the association primary key, matches and compares field by field, generates intra-group difference records for each group, and summarizes them to obtain a global comparison result list.

[0127] Optionally, the testing system can set a threshold for execution efficiency differences (e.g., 20%). If the testing system detects that the execution efficiency fluctuates within 20%, it is considered a normal efficiency difference. If it exceeds the threshold, the system will verify the returned data content, the number of affected rows, and the execution error information. If any of these items are inconsistent, it is considered a compatibility issue.

[0128] Optionally, if the difference in execution efficiency is due to database version optimization but there is no difference in the result data, the testing system can determine it as a normal difference; if the data content is the same but the order of the returned results is different, the testing system can determine it as a normal difference. If the comparison result list shows at least one of the following differences: execution error difference, returned result data difference, or difference in the number of rows affected, the testing system can determine it as a compatibility issue.

[0129] Optionally, the testing system can extract error codes, exception text, SQL characteristics, version numbers, table structure names, and repair records from historical test data, and standardize the extraction results into unified entity identifiers. Then, compatibility issues and repair methods are written into a graph database according to preset entity and relationship types, forming a searchable entity and relationship graph. If new historical test data exists, the testing system can also match new issues with existing entities and incrementally write them.

[0130] Optionally, the testing system can characterize abnormal statements, abnormal return values, or inconsistent results in the playback results. Then, it can perform similarity matching between these characteristics and problem entities in the knowledge graph, and perform multi-hop retrieval through relationship chains to locate the historical problem and its processing records that are most relevant to the current anomaly.

[0131] Optionally, the testing system can output repair suggestions based on the retrieved associated paths. These suggestions may include SQL statement rewriting suggestions, index optimization suggestions, function call replacement suggestions, or version difference avoidance suggestions, and may also include repair results from corresponding historical cases for reference.

[0132] By structuring and accumulating compatibility issues and fixes from historical tests into a knowledge graph, the accuracy of problem localization and the feasibility of fix recommendations can be improved.

[0133] Figure 2 This is a schematic diagram of the architecture of a database version upgrade traffic replay test system provided in an embodiment of this application. Figure 2 As shown, the architecture of this database version upgrade traffic replay test system includes a traffic acquisition module, a traffic filtering module, a test resource preparation module, a traffic replay module, and an intelligent comparison and analysis module. Among these,

[0134] Traffic acquisition module: responsible for collecting SQL traffic information from the database of the system under test, and realizing the timed collection and persistent storage of traffic data;

[0135] Traffic filtering module: Based on a preset multi-dimensional traffic filtering strategy, the collected SQL traffic is cleaned and filtered to remove invalid and redundant traffic, thereby reducing the amount of replay data while ensuring test coverage.

[0136] Test resource preparation module: Construct benchmark test instances and comparison test instances to ensure that the static data (table structure, full data) of the two instances are completely consistent, providing a unified benchmark for subsequent replay comparison;

[0137] Traffic replay module: It adopts a group replay strategy and combines auto-incrementing column dynamic replacement technology to replay the filtered traffic synchronously in two test instances and record complete execution result information.

[0138] Intelligent comparison and analysis module: It intelligently compares the replay execution results of two test instances, identifies SQL statements with inconsistent results, distinguishes between normal differences and compatibility issues, and can provide SQL optimization suggestions.

[0139] Optionally, the traffic acquisition module uses timed scanning and persistent storage to obtain SQL traffic information from the source database.

[0140] For example, the traffic collection module can rely on the SQL auditing function built into the database to enable SQL auditing logging in the source database and generate an SQL auditing table. The auditing table contains key information such as SQL statements, execution time, databases involved, executing users, and statement types.

[0141] For example, the traffic acquisition module can use a timed scanning mechanism to collect data. The scanning cycle (such as 1 minute / time or 5 minutes / time) can be configured based on the retention time of SQL audit table data calculated in memory to ensure the real-time and timely nature of traffic acquisition and avoid missing critical business traffic.

[0142] For example, the traffic acquisition module can store the SQL traffic data collected by scanning into a dedicated traffic storage database in the format of timestamp, SQL statement, and related information. This supports the backtracking, querying, and retrieval of traffic data, providing data support for subsequent filtering and playback steps.

[0143] Optionally, the traffic filtering module cleans and filters the collected SQL traffic based on a preset multi-dimensional traffic filtering strategy, removing invalid and redundant traffic to ensure that the filtered traffic can accurately cover business scenarios, while reducing the amount of replay data and improving testing efficiency.

[0144] For example, the traffic filtering strategy of the traffic filtering module includes at least one of the following filtering methods, which can be combined according to actual testing needs to achieve multi-level filtering:

[0145] 1. Time-based cleaning: Based on test requirements, preset a specified time (such as the start time of the test or the start time of the business peak), filter out SQL traffic before the specified time, and only retain traffic after the specified time, to ensure the relevance of the replay traffic to the test scenario and avoid invalid historical traffic from interfering with the test results;

[0146] 2. Cleaning by database dimension: Pre-define a whitelist of business databases to filter out SQL traffic generated by non-business databases (such as system databases and temporary test databases), retain only traffic related to business databases, and focus on core business compatibility testing;

[0147] 3. Filter by keyword tags: Preset invalid traffic keywords (such as "data migration", "batch import", "test script", etc.), perform keyword matching on SQL traffic, and remove SQL statements generated by abnormal business activities such as data migration, batch operations, and test activities to avoid test deviations caused by such traffic;

[0148] 4. Filter by SQL syntax: Call the SQL syntax parsing tool to perform syntax verification on the collected SQL statements and remove statements with obvious syntax errors (such as missing keywords or non-standard syntax) to avoid invalid errors during playback and affect testing efficiency.

[0149] 5. Filtering based on the relationship between SELECT statements and DML statements: Perform syntactic analysis on SELECT statements to parse the table relationships involved, match the corresponding DML statements (such as insert, download, delete), and for a single DML statement, retain only the two SELECT statements before and after it, eliminating redundant SELECT statements that are irrelevant to business logic, further reducing the amount of traffic data; specifically, extract the table name and query conditions of SELECT statements through syntactic analysis tools, match DML statements involving the same table in the same session, establish relationship mapping, retain related SELECT statements according to rules, and eliminate redundant statements without relationships;

[0150] 6. Semantic coverage filtering of traffic data based on SQL fingerprint calculation: The SQL statements are parameterized, and the variable parameters in the SQL statements (such as specific values ​​in query conditions and specific content in inserted data) are replaced with uniform placeholders. The Message-Digest Algorithm 5 (MD5) value is calculated on the parameterized text to generate a unique SQL fingerprint. When the traffic dataset exceeds a preset threshold (such as 100,000 records), deduplication is performed based on the SQL fingerprint, retaining the SQL statements corresponding to different SQL fingerprints, maximizing the coverage of different SQL semantics, ensuring test coverage, and avoiding redundant traffic replay with the same semantics.

[0151] For example, after filtering is completed, a standardized filtered traffic dataset is generated and stored in the filtered data table of the traffic storage database for subsequent playback steps.

[0152] Optionally, the test resource preparation module can deploy benchmark test instances. Using the test environment source database as a baseline, at a specified time (consistent with the specified time for traffic filtering), the complete table structure (including table names, field types, constraints, indexes, etc.) and full data of the source database are exported using a database backup tool. The exported table structure and full data are then imported into a server that has an older version of the database deployed (i.e., the database version before the upgrade), forming an older version replica database. This older version replica database is the core of the benchmark test instance, and its static data (table structure, full data) is completely consistent with the state of the source database at the specified time.

[0153] Optionally, the test resource preparation module can also deploy comparison test instances. The complete table structure and all data of the old version replica database in the benchmark environment are completely migrated to a server deploying the new version database (i.e., the upgraded target database version) using a data migration tool, forming a new version replica database. This new version replica database is the core of the comparison test instance. During the migration process, data integrity and table structure consistency are strictly verified to ensure that the table structure and all data of the new version replica database are completely consistent with the old version replica database, eliminating the impact of environmental differences on the playback results.

[0154] Optionally, after deployment, the test resource preparation module can also execute preset verification SQL statements to compare the table structure and key data (such as the total number of rows in the core business table and the values ​​of key fields) of the two test instances to confirm that they are completely consistent. If there is any inconsistency, the data migration and verification steps are re-executed until the requirements are met.

[0155] Optionally, the traffic replay module will synchronously replay the filtered traffic data in the benchmark test instance (old version replica library) and the comparison test instance (new version replica library), record complete execution result information, and adopt a group replay strategy and auto-incrementing column dynamic replacement technology to solve the replay consistency problem in a distributed environment.

[0156] For example, the group replay strategy can perform cluster analysis, parse the SQL statements in the filtered traffic data, extract the data tables involved in each SQL statement, and based on the relationship between the data tables (such as primary and foreign key relationships, and union query relationships), use the disjoint set algorithm to group the SQL statements involving related data tables into a group, forming a table group with a relationship.

[0157] For example, the group replay strategy can also perform parallel replay. For traffic data between different table groups, parallel replay operations are performed to improve replay efficiency. For SQL statements within the same table group, serial replay operations are performed according to the execution order of the original traffic to ensure the consistency of table association logic and avoid execution result deviations caused by concurrent replay.

[0158] For example, the traffic replay module can dynamically adjust the replay rate according to the hardware performance of the test environment (CPU, memory, disk I / O) to ensure the stability of the test environment during replay and avoid problems such as excessive database pressure and execution timeout caused by excessively fast replay rate.

[0159] Optionally, the traffic replay module can record auto-incrementing column values. After synchronously replaying the INSERT statement to the benchmark test instance and the comparison test instance, it can immediately obtain the auto-incrementing column values ​​generated by the INSERT statement in the two instances through a database query statement.

[0160] Optionally, the traffic replay module can establish an association mapping table for the auto-incrementing column values ​​in the original traffic, the auto-incrementing column values ​​generated by the benchmark test instance, and the auto-incrementing column values ​​generated by the comparison test instance, and store them in the traffic storage database.

[0161] Optionally, the traffic replay module can, during subsequent replays, when encountering SQL statements involving the auto-increment column value (such as UPDATE and DELETE statements using the auto-increment column as a condition), replace the auto-increment column value in the original traffic with the actual auto-increment column value generated in the corresponding test instance according to the association mapping table. This ensures that the replay statement can accurately match the data and avoids execution errors or result deviations caused by inconsistent auto-increment column values.

[0162] Optionally, during the replay process, the traffic replay module can record the execution result information of each SQL statement in the two test instances in real time, ensuring the integrity and traceability of the result information. For example, the recorded execution result information includes: SELECT statements: original return information (including the returned result set, field values, number of returned rows, etc.); DML statements (INSERT, UPDATE, DELETE): number of rows affected by execution, execution status (success / failure); execution error statements: original error information (including error code, error description, location of error, etc.).

[0163] Optionally, the intelligent comparison and analysis module automatically compares the execution results of the benchmark test instance and the comparison test instance, identifies SQL statements with inconsistent results, distinguishes between normal differences and compatibility issues, and provides SQL optimization suggestions. The intelligent comparison and analysis module can extract the execution result information of the two test instances from the result storage database and compare them according to the SQL statement identifier. The comparison content includes: the return result set of the SELECT statement, the number of rows affected by the DML statement, execution status, and error information. During the comparison process, the returned result set is standardized (e.g., sorted) to avoid misjudgments caused by different return orders.

[0164] For example, the intelligent comparison and analysis module can filter out the SQL statements that differ after comparison, record their original SQL statements, the execution results of the two instances, and the differences, forming a list of inconsistent results.

[0165] For example, the intelligent comparison and analysis module can push a list of inconsistent results and corresponding contextual information (including SQL statement type, involved data tables, execution time, associated traffic, etc.) to the intelligent comparison and analysis agent. The agent then distinguishes between normal differences and compatibility issues based on preset difference classification rules. Normal differences include: differences in execution efficiency due to database version optimization (no difference in result data) and differences in the order of returned results (consistent data content). Compatibility issues include: differences in execution errors, differences in returned result data, and differences in the number of rows affected. These types of differences need to be highlighted.

[0166] For example, the intelligent comparison and analysis module can also send the parameterized SQL text (consistent with the parameterization process in the traffic filtering step) to the SQL optimization agent. The agent, in combination with the characteristics of the new version of the database, analyzes the execution efficiency and syntax optimization space of the SQL statement, and generates targeted SQL optimization suggestions (such as index optimization, statement reconstruction, etc.) to help users optimize business SQL and improve the operating efficiency of the upgraded database.

[0167] For example, the intelligent comparison and analysis module can also output a list of inconsistent results, difference classification results, compatibility issue markings, and optimization suggestions (if any) in the form of a visual report, and push it to relevant testers to guide them in further analyzing and resolving compatibility issues.

[0168] Figure 3 A flowchart illustrating another database version upgrade traffic replay testing method provided in this application embodiment is shown below. Figure 3 As shown, the method includes:

[0169] Step 1: Traffic collection. Obtain the actual business SQL traffic from the source database to provide basic data for subsequent testing.

[0170] Optionally, the test system can enable the SQL auditing function of the source database, configure the audit log parameters, and ensure that the audit table can record key information of each SQL statement (SQL text, execution time, databases involved, executing user, statement type, etc.).

[0171] Optionally, the testing system can launch a traffic acquisition program to periodically scan the SQL audit table of the source database according to a preset scanning cycle (e.g., 1 minute / time) and extract newly added SQL traffic data from the audit table. The collected SQL traffic data is then stored in a dedicated traffic storage database in the format of "timestamp, SQL statement, and related information," creating a traffic data index to support subsequent queries and retrieval.

[0172] Step 2: Traffic filtering. Eliminate invalid and redundant traffic to reduce the amount of replay data, improve testing efficiency, and ensure test coverage.

[0173] Optionally, the testing system can be configured with multi-dimensional filtering strategies (one or more combinations can be selected) according to testing requirements, including preset time thresholds, business database whitelists, invalid keywords, traffic scale thresholds, and other parameters. Then, multi-level filtering is executed.

[0174] For example, Figure 4 This is a flowchart illustrating a multi-level filtering method provided in an embodiment of this application, as shown below. Figure 4 As shown,

[0175] First-level filtering: Based on the time dimension, remove SQL traffic before a specified time and retain traffic after the specified time;

[0176] The second layer of filtering: Based on the database dimension, SQL traffic generated by non-business databases is removed, while business database traffic is retained;

[0177] The third layer of filtering: Based on keyword tags, SQL statements for abnormal business operations such as data migration and batch operations are removed;

[0178] Fourth layer of filtering: Based on SQL syntax, remove statements with obvious syntax errors;

[0179] Fifth layer of filtering: Based on the relationship between SELECT and DML statements, redundant SELECT statements are filtered out, and only SELECT statements associated with DML statements are retained;

[0180] The sixth layer of filtering is based on SQL fingerprint calculation. When the traffic volume exceeds the preset threshold, the SQL statement is parameterized and an SQL fingerprint is generated. This process removes duplicates and maximizes the coverage of different SQL semantics.

[0181] Optionally, the testing system can sample and verify the filtered traffic dataset to confirm that invalid traffic has been removed, core business traffic has been retained, and the traffic scale meets the testing requirements; if the verification fails, the filtering parameters are adjusted and the filtering steps are re-executed.

[0182] Optionally, the testing system can store the filtered traffic dataset in the filtered data table of the traffic storage database to provide standardized data for subsequent playback steps.

[0183] Step 3: Deploy test resources and build two completely identical test instances to eliminate the impact of resource differences on the playback results and provide a unified benchmark for subsequent comparative analysis.

[0184] Optionally, the test system can use a database backup tool at a specified time (consistent with the specified time of traffic filtering) to export the complete table structure and full data of the source database. The exported table structure and full data are then imported into a server with an older version of the database installed, creating a replica database. The table structure and data integrity of the replica database are verified to ensure complete consistency with the state of the source database at the specified time.

[0185] Optionally, the test system can use a data migration tool to completely migrate the entire table structure and all data of the old version replica database to the server with the new version database installed, creating a new version replica database. After the migration is complete, execute verification SQL statements to compare the table structure (field types, constraints, indexes) and core business table data (total number of rows, key field values) of the old and new version replica databases. If data inconsistencies or table structure differences exist, repeat the data migration and verification steps until the static data of the two instances is completely consistent.

[0186] Optionally, the testing system can initialize the two test database instances, clear irrelevant data and logs, and ensure that the test instances are in a clean and stable state to avoid historical data interfering with the replay test.

[0187] Step 4: Traffic replay. The filtered business traffic is replayed synchronously in two test instances to record the complete execution results, while also solving the replay consistency problem in a distributed environment.

[0188] Optionally, the testing system can be configured with replay rate (dynamically adjusted based on test environment performance), group replay parameters, and a switch for dynamically replacing auto-incrementing columns. Then, each SQL statement in the filtered traffic data is parsed, the relevant data tables are extracted, and clustering algorithms are used to form related table groups based on the data table relationships.

[0189] Optionally, the testing system can perform parallel replay of traffic data from different table groups to improve replay efficiency. For SQL statements within the same table group, serial replay is performed according to the execution order of the original traffic, ensuring the consistency of table join logic. During replay, the system monitors the real-time running status of the test environment (CPU, memory, disk I / O), and automatically adjusts the replay rate if excessive pressure is detected.

[0190] Optionally, when replaying INSERT statements, the test system can query the auto-incrementing column values ​​generated by the INSERT statement in both instances, establish a mapping table between the original auto-incrementing column values ​​and the actual generated values ​​in the two instances, and store it in the traffic storage database. If, during subsequent replays, SQL statements involving the auto-incrementing column value are encountered, the test system can use the mapping table to replace the auto-incrementing column value in the original traffic with the actual auto-incrementing column value of the corresponding test instance, ensuring accurate statement execution.

[0191] Optionally, the testing system can also record the execution results of each SQL statement in both test instances in real time, including the result set returned by the SELECT statement, the number of rows affected by the DML statement, and the original error information of the execution error statement. These results are stored in a standardized format in the result storage database to ensure traceability. After replay, the replay success rate and the number of execution errors are calculated. The replay success rates of the two instances are compared. If there is a significant difference, environmental or traffic issues are investigated, and the replay process is repeated.

[0192] Step 5: Intelligent comparison and analysis, automatically compares the playback results of two test instances, accurately identifies compatibility issues, distinguishes normal differences, and provides optimization suggestions.

[0193] Optionally, the testing system can extract all execution result information of the two test instances from the result storage database, group them according to the SQL statement identifier, and ensure that the two execution results of each SQL statement correspond.

[0194] Optionally, the testing system can standardize (sort) the returned result set, compare the content, field values, and number of returned rows of the result set to determine if they are consistent, and also compare the number of rows affected by the execution and the execution status (success / failure) to determine if they are consistent.

[0195] Optionally, the testing system can compare error information. If an SQL statement fails to execute in a certain instance, the system can compare the error codes and descriptions of the two instances to determine if there are any differences.

[0196] Optionally, the testing system can filter out the SQL statements that differ after comparison, form a list of inconsistent results, record the original SQL text of each statement, the execution results of the two instances, and the content of the differences, and push the list of inconsistent results and context information (SQL type, involved data tables, execution time, etc.) to the intelligent comparison and analysis agent. The agent distinguishes between normal differences and compatibility issues based on preset rules.

[0197] For example, if the difference is normal, it is marked as no need to be processed, such as different order of returned results but the same content, or difference in execution efficiency but no difference in results; if it is a compatibility issue, it is marked as important, such as difference in execution error, difference in returned result data, or difference in the number of affected rows, etc. Such differences need to be further analyzed and processed.

[0198] Step 6: Optimization suggestion generation. The parameterized SQL text is sent to the SQL optimization agent. The agent analyzes the optimization space of the SQL statement based on the characteristics of the new version of the database and generates targeted optimization suggestions (such as index optimization and statement restructuring).

[0199] Step 7: Output the test report, including the list of inconsistent results, the classification results of differences, the marking of compatibility issues, and optimization suggestions (if any). Generate a visual test report and push it to the testers to clarify the specific location and scope of the compatibility issues, and guide the testers to further analyze and solve the problems.

[0200] For example, testers can use the reports output by intelligent comparison analysis to further verify compatibility issues and confirm their authenticity, scope of impact, and severity. They can also optimize business SQL statements based on identified compatibility issues and SQL optimization suggestions, or coordinate with database vendors to fix compatibility vulnerabilities in newer database versions.

[0201] For example, testers can also assess the feasibility of database version upgrades based on the resolution of compatibility issues. If all compatibility issues have been resolved, the upgrade can proceed; if there are serious compatibility issues that cannot be resolved, the upgrade plan needs to be adjusted (such as changing the database version or delaying the upgrade). All data from the testing process (traffic data, filtering results, replay results, comparison reports) should be archived to form a complete test file, providing a reference for subsequent database upgrade tests.

[0202] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0203] Figure 5 A schematic diagram of a database version upgrade traffic replay testing device provided in this application embodiment is shown below. Figure 5 As shown, the database version upgrade traffic replay test device 500 includes: an acquisition module 501, an application module 502, a recording module 503, and a generation module 504. Among them,

[0204] The acquisition module 501 is used to acquire traffic data from the source database by deploying benchmark test instances and comparison test instances;

[0205] Application module 502 is used to apply a multi-dimensional filtering strategy to the traffic data and generate a filtered dataset.

[0206] The recording module 503 is used to synchronously replay the filtered dataset in the benchmark test instance and the comparison test instance, and record the execution results.

[0207] Module 504 is used to generate a compatibility issue report based on the execution result.

[0208] Optionally, the application module 502 is also used to clean the traffic data by time dimension, removing structured query language (SQL) statements that are not in the specified time period;

[0209] The traffic data was cleaned at the database level, removing structured query language (SQL) statements from non-business databases.

[0210] The traffic data is cleaned by keyword tags, and structured query language (SQL) statements containing invalid operation identifiers are removed.

[0211] Optionally, the application module 502 is also used to perform SQL syntax validation on the traffic data before cleaning the traffic data by keyword tags and removing structured query language SQL statements containing invalid operation identifiers, and to remove structured query language SQL statements with syntax errors.

[0212] Optionally, the application module 502 is also used to perform semantic coverage filtering on traffic data based on the structured query language SQL fingerprint calculation;

[0213] Filtering is performed based on the association between SELECT statements and DML statements.

[0214] Optionally, the recording module 503 is also used to synchronize the static data of the benchmark test instance to the comparison test instance through a data migration tool after storing the filtered dataset to the target storage unit;

[0215] Verify the consistency of table structure and data between the benchmark test instance and the comparison test instance;

[0216] If the table structure and data of the benchmark instance and the comparison instance are consistent, perform grouped replay on the benchmark instance and the comparison instance.

[0217] Optionally, the recording module 503 is also used to cluster Structured Query Language (SQL) statements into table groups based on data table relationships;

[0218] Parallel playback of Structured Query Language (SQL) statements for different table groups, and serial playback of Structured Query Language (SQL) statements for the same table group.

[0219] Optionally, the generation module 504 is further configured to apply a multi-dimensional filtering strategy to the traffic data, generate a filtered dataset, and then perform dynamic replacement of auto-incrementing columns on the filtered dataset. This dynamic replacement of auto-incrementing columns specifically includes:

[0220] After replaying the INSERT statement, record the auto-increment column values ​​generated by the old and new versions of the database instance;

[0221] In subsequent playbacks, the auto-incrementing column values ​​in the original traffic will be replaced with the actual values ​​of the corresponding instances.

[0222] Optionally, the generation module 504 is further configured to compare the replay results of the benchmark test instance group in the target storage unit with the replay results of the comparison test instance group to obtain a comparison result list;

[0223] Based on the preset difference classification rules, normal differences and compatibility issues are distinguished in the comparison result list. Normal differences include at least differences in execution efficiency and differences in the order of returned results, while compatibility issues include at least differences in execution errors, differences in returned result data, and differences in the number of rows affected.

[0224] Based on compatibility issues and fixes found in historical test data, a knowledge graph of compatibility issues is constructed.

[0225] Based on this knowledge graph, compatibility issues in the playback results are traced back to their source, and repair suggestions are generated.

[0226] This embodiment provides a database version upgrade traffic replay test device, which can execute the methods provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0227] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 600 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0228] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0229] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0230] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0231] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0232] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0233] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0234] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0235] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0236] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0237] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0238] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0239] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0240] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0241] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0242] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0243] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for testing traffic replay during database version upgrades, characterized in that, include: Traffic data from the source database is obtained by deploying benchmark test instances and comparison test instances; A multidimensional filtering strategy is applied to the traffic data to generate a filtered dataset; The filtered dataset is synchronously replayed in the benchmark test instance and the comparison test instance, and the execution results are recorded. A compatibility issue report is generated based on the execution results.

2. The method according to claim 1, characterized in that, The application of a multidimensional filtering strategy to the traffic data includes: The traffic data is cleaned according to the time dimension, and structured query language (SQL) statements that are not in the specified time period are removed; The traffic data is cleaned according to the database dimension, and structured query language (SQL) statements from non-business databases are removed; The traffic data is cleaned by keyword tags, and structured query language (SQL) statements containing invalid operation identifiers are removed.

3. The method according to claim 2, characterized in that, Before cleaning the traffic data by keyword tags and removing Structured Query Language (SQL) statements containing invalid operation identifiers, the process includes: The traffic data is subjected to Structured Query Language (SQL) syntax validation, and SQL statements with syntax errors are removed.

4. The method according to claim 1, characterized in that, The multidimensional filtering strategy includes at least one of the following: Semantic coverage filtering of traffic data is performed based on SQL fingerprint calculation using the structured query language. Filtering is performed based on the association between SELECT statements and DML statements.

5. The method according to claim 1, characterized in that, The step of synchronously replaying the filtered dataset in the benchmark test instance and the comparison test instance includes: The static data of the benchmark test instance is synchronized to the comparison test instance using a data migration tool; Verify the consistency of table structure and data between the benchmark test instance and the comparison test instance; If the table structure and data of the benchmark test instance and the comparison test instance are consistent, group replay is performed on the benchmark test instance and the comparison test instance.

6. The method according to claim 5, characterized in that, The group playback specifically includes: Based on the relationships between data tables, structured query language (SQL) statements are clustered to form table groups; Parallel playback of Structured Query Language (SQL) statements for different table groups, and serial playback of Structured Query Language (SQL) statements for the same table group.

7. The method according to claim 1, characterized in that, After applying a multi-dimensional filtering strategy to the traffic data to generate a filtered dataset, the process includes: Dynamic replacement of auto-incrementing columns is performed on the filtered dataset. Specifically, this dynamic replacement includes: After replaying the INSERT statement, record the auto-increment column values ​​generated by the old and new versions of the database instance; In subsequent playbacks, the auto-incrementing column values ​​in the original traffic will be replaced with the actual values ​​of the corresponding instances.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Compare the replay results of the benchmark test instance group with the replay results of the comparison test instance group to obtain a comparison result list; Based on preset difference classification rules, the comparison result list is distinguished into normal differences and compatibility issues. The normal differences include at least differences in execution efficiency and differences in the order of returned results. The compatibility issues include at least differences in execution errors, differences in returned result data, and differences in the number of rows affected. Based on the compatibility issues and fixes described in historical test data, a knowledge graph of compatibility issues is constructed. Based on the knowledge graph, compatibility issues in the playback results are traced back to their source, and repair suggestions are generated.

9. A database version upgrade traffic replay testing device, characterized in that, include: The acquisition module is used to obtain traffic data from the source database by deploying benchmark test instances and comparison test instances; The application module is used to apply a multi-dimensional filtering strategy to the traffic data and generate a filtered dataset. The recording module is used to synchronously replay the filtered dataset in the benchmark test instance and the comparison test instance, and record the execution results. The generation module is used to generate a compatibility issue report based on the execution results.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images