A mimetic bracket and arbitration method based on relational database

Abstract

The present invention provides a mimetic architecture for a relational database, comprising: a transaction marking module located on each heterogeneous executor, for adding a unique mimetic transaction marking to a transaction; a group marking module located on each heterogeneous executor, for adding a unique mimetic group marking to each SQL statement in the transaction; an arbiter located on a database front-end agent, for receiving transactions sent by the heterogeneous executors, normalizing and adjudicating the mimetic transaction markings carried by the transactions, obtaining a target mimetic transaction marking, and determining a target socket connection according to the target mimetic transaction marking; normalizing and adjudicating SQL statements in different transactions carrying the target mimetic transaction markings one by one based on the mimetic group marking to obtain a target transaction; and sending the target socket connection and the target transaction to the database front-end agent, so that the database front-end agent sends the target transaction to the database for operation based on the target socket connection.

Description

Technical Field

[0001] The present invention relates to the field of mimicry defense, and in particular to a mimicry architecture and a mimicry defense method for a relational database. Background Art

[0002] The cyberspace mimicry defense theory, invented by Academician Wu Jiangxing, has overturned the traditional passive cyberspace defense philosophy. Its dynamic redundant architecture and feedback control mechanism, which proactively senses unknown threats, greatly enhances the inherent security characteristics of cyberspace, changing the rules of the cyberspace defense game and providing a new and innovative solution for network security. Currently, mimicry defense technology has been included in national strategic priorities. As mimicry defense technology becomes increasingly sophisticated and mature, more and more network elements are beginning to incorporate mimicry defense concepts to improve their own security, enhancing their inherent security features to defend against security threats such as those based on unknown vulnerabilities and backdoors. Storage, as one of the three key components of IT infrastructure, plays a crucial role. With the demand for cloud computing and the construction of new infrastructure big data centers, the importance of storage has become increasingly apparent, and the security of storage and data has become particularly important.

[0003] A relational database uses a relational model to organize data, storing data in rows and columns for easier understanding. These rows and columns are called tables, and a database is composed of a set of tables. Users retrieve data from the database through queries, which are executable code that restricts access to specific areas of the database. The relational model can be simply understood as a two-dimensional table model, and a relational database is a data organization consisting of two-dimensional tables and the relationships between them.

[0004] Due to the widespread use of relational databases in traditional storage, data security and other issues they face are particularly important. If relational databases can be combined with currently popular mimicry active defense technologies while minimizing major modifications to database components, the security level of the data itself can be greatly improved at a minimal cost.

[0005] In the process of mimetic transformation of application systems supported by relational databases, there are situations where multiple heterogeneous executors operate on a database at the same time, which leads to the problem of duplicate writing of business data and the inability to correctly commit and roll back database transactions. These problems must be faced and solved.

[0006] In order to solve the above problems, people have been seeking an ideal technical solution. Summary of the Invention

[0007] The purpose of the present invention is to address the deficiencies of the existing technology and thus provide a mimetic architecture and mimetic defense method for a relational database, which solves the problems of repeated writing of business data and the inability to correctly commit and roll back database transactions when applying mimetic transformation to a relational database.

[0008] In order to achieve the above-mentioned object, the technical solution adopted by the present invention is to provide a mimetic architecture of a relational database, including: a transaction marking module located on each heterogeneous execution body, for adding a unique mimetic transaction mark to the transaction;

[0009] A group marking module located on each heterogeneous execution body is used to add a unique pseudo-grouping mark to each SQL statement in the transaction, wherein the pseudo-grouping mark includes an execution sequence number of the SQL statement in the current transaction;

[0010] The arbiter located on the database front-end agent is configured to receive transactions sent by the heterogeneous executors, perform normalization and adjudication on the mimetic transaction tags carried by the transactions, obtain a target mimetic transaction tag, and determine a target socket connection based on the target mimetic transaction tag; perform normalization and adjudication on SQL statements in different transactions carrying the target mimetic transaction tags one by one based on the mimetic grouping tags to obtain a target transaction; and send the target socket connection and target transaction to the database front-end agent, so that the database front-end agent can send the target transaction to the database for operation based on the target socket connection;

[0011] Among them, the transaction marking module on each heterogeneous executor generates a unique mimetic transaction mark based on the built-in mimetic transaction mark generation rule, and the grouping marking module on each heterogeneous executor generates a unique mimetic grouping mark based on the built-in mimetic transaction grouping generation rule. The mimetic transaction mark generation rules built into different transaction marking modules are the same, and the mimetic grouping mark generation rules built into different grouping marking modules are the same.

[0012] In one embodiment, determining a target socket connection according to a target pseudo-transaction tag includes:

[0013] Find out whether there is a Socket connection associated with the target mimic transaction tag. If so, use the Socket connection as the target Socket connection.

[0014] If it does not exist, determine the heterogeneous executor that sends the transaction carrying the target pseudo-transaction tag, select the heterogeneous executor corresponding to the high-confidence information according to the confidence information of the heterogeneous executor, and associate the Socket connection established by the heterogeneous executor for the transaction with the target pseudo-transaction tag, and then use the Socket connection as the target Socket connection.

[0015] In one embodiment, normalizing and adjudicating SQL statements in different transactions carrying target mimic transaction tags is performed one by one based on the mimic grouping tags to obtain the target transaction, including:

[0016] In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; each group of SQL statements is normalized and adjudicated one by one to obtain the target SQL statement of the group;

[0017] Sort all target SQL statements in execution order to form a target transaction.

[0018] Furthermore, after obtaining the target transaction, traverse the transactions carrying the target pseudo-transaction tag to find out whether there is a transaction identical to the target transaction. If so, confirm that the target transaction is correct and retain the target transaction. If not, confirm that the target transaction is wrong and report an error.

[0019] Since the database will perform two operations after executing the transaction: correct transaction commit and transaction rollback, the heterogeneous executors also need to perform data update and data rollback operations accordingly. Specifically, the arbiter receives the database execution result of the target transaction returned by the database front-end agent, and distributes it to each heterogeneous executor for updating. Alternatively, the arbiter receives the database-generated transaction rollback operation instruction returned by the database front-end agent, and distributes it to each heterogeneous executor. The transaction rollback operation instruction carries a pseudo-transaction marker, so that the heterogeneous executor can roll back the execution result of the target transaction corresponding to the pseudo-transaction marker.

[0020] The present invention also provides a mimicry defense method for a relational database, which is applied to an arbitrator and includes the following steps:

[0021] Receive transactions sent by different heterogeneous executors, each transaction carries a unique mimetic transaction tag, and each SQL statement in each transaction carries a unique mimetic grouping tag; wherein the mimetic transaction tag generation rules built into the different heterogeneous executors are the same, and the built-in mimetic grouping tag generation rules are the same, and the mimetic grouping tag includes the execution sequence number of the SQL statement in the current transaction;

[0022] Normalize and adjudicate the pseudo-transaction tag carried by the transaction to obtain a target pseudo-transaction tag, and determine the target socket connection according to the target pseudo-transaction tag; normalize and adjudicate the SQL statements in different transactions carrying the target pseudo-transaction tag one by one based on the pseudo-grouping tag to obtain the target transaction;

[0023] The target Socket connection and the target transaction are sent to the database front-end agent, so that the database front-end agent can send the target transaction to the database for operation based on the target Socket connection.

[0024] The present invention has outstanding substantive features and significant advancements. Specifically, the present invention adds a unique pseudo-transaction tag to transactions generated by heterogeneous executors, and an arbiter normalizes and adjudicates the pseudo-transaction tag carried by the transaction to obtain a target pseudo-transaction tag. The target socket connection is finally determined based on the target pseudo-transaction tag, so that database transactions can be correctly committed and rolled back.

[0025] The present invention adds a unique mimetic grouping tag to each SQL statement in the transaction, and the arbiter normalizes and adjudicates the SQL statements in different transactions carrying the target mimetic transaction tag one by one based on the mimetic grouping tag to obtain the target transaction, thereby preventing the repeated writing of business data corresponding to the transaction.

[0026] The present invention can ensure the matching degree between the transaction and the Socket connection to the greatest extent by selecting the Socket connection corresponding to the target transaction with the highest possibility of being selected as the target transaction, is more in line with the consistency principle of the database Socket connection on which the transaction depends, and can ensure the correct execution and rollback of the database transaction.

[0027] After obtaining the target transaction, the present invention further verifies the correctness of the target transaction to ensure that only the correct target transaction can be sent to the database for execution, thereby ensuring the security of the database. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a structural diagram of embodiment 1 of the present invention.

[0029] Figure 2 It is a flow chart of embodiment 2 of the present invention.

[0030] Figure 3 It is a flow chart of Example 3 of the present invention.

[0031] Figure 4 It is a flow chart of Example 4 of the present invention. DETAILED DESCRIPTION

[0032] A database transaction is a collection of operations that constitute a single logical unit of work. A database transaction can contain one or more database operations, but these operations form a logical whole. These database operations that constitute the logical whole are either all executed successfully or not executed at all. All operations that constitute the transaction either have an impact on the database or have no impact at all. That is, regardless of whether the transaction is executed successfully, the database can always maintain a consistent state.

[0033] When a database operation fails or the system crashes, the system can recover based on the transaction boundary. When multiple users operate the database at the same time, the database can perform concurrency control based on the transaction unit.

[0034] However, in the process of mimetic transformation of application systems supported by relational databases, there are situations where multiple heterogeneous executors generate the same transaction and operate a database at the same time, which results in repeated writing of business data and the inability to correctly commit and roll back database transactions.

[0035] In order to solve the above technical problems, the present invention proposes a mimetic architecture of a relational database, which acts on the right bracket part of the mimetic system and cooperates with other mimetic components to complete the support of the mimetic application system.

[0036] The technical solution of the present invention is further described in detail below through specific implementation methods.

[0037] Example 1

[0038] This embodiment provides a mimetic architecture of a relational database, such as Figure 1 Shown, including:

[0039] The transaction marking module located on each heterogeneous executor is used to add a unique pseudo-transaction marker to the transaction;

[0040] A group marking module located on each heterogeneous execution body is used to add a unique pseudo-grouping mark to each SQL statement in the transaction, wherein the pseudo-grouping mark includes an execution sequence number of the SQL statement in the current transaction;

[0041] The arbiter located on the database front-end agent is used to receive transactions sent by the heterogeneous executors, perform normalization and adjudication on the pseudo-transaction tags carried by the transactions, obtain target pseudo-transaction tags, and determine the target Socket connection based on the target pseudo-transaction tags; perform normalization and adjudication on SQL statements in different transactions carrying the target pseudo-transaction tags one by one based on the pseudo-grouping tags to obtain the target transaction; and send the target Socket connection and the target transaction to the database front-end agent, so that the database front-end agent can send the target transaction to the database for operation based on the target Socket connection.

[0042] Among them, the transaction marking module on each heterogeneous executor generates a unique mimetic transaction mark based on the built-in mimetic transaction mark generation rule, and the group marking module on each heterogeneous executor generates a unique mimetic group mark based on the built-in mimetic transaction group generation rule.

[0043] To facilitate understanding, this embodiment provides a complete transaction statement demo received by the arbitrator:

[0044] / *xdyw=abc* / begin;

[0045] / *xdyw=abc label1* / update test set status=1 where id='xxx';

[0046] / *xdyw=abc label2* / delete from test where id='xxy';

[0047] / *xdyw=abc* / commit;

[0048] Among them, xdwy=abc is the pseudo-transaction mark of the current transaction, label1 and label2 are the pseudo-grouping marks of different SQL statements in the current transaction. It can be seen that the pseudo-grouping mark includes the execution sequence number of the current SQL statement in the transaction.

[0049] When used, you can quickly locate a transaction based on the pseudo-transaction tag *xdyw=abc*, and quickly locate the SQL statement in the transaction based on the pseudo-transaction tag and the pseudo-transaction tag *xdyw=abc label1 or *xdyw=abc label2.

[0050] It can be understood that the built-in pseudo-transaction marker generation rules of different transaction marking modules are the same, so that the unique pseudo-transaction markers generated by different heterogeneous executors for the same transaction are the same; the built-in pseudo-grouping marker generation rules of different grouping marking modules are the same, so that the unique pseudo-transaction markers generated by different heterogeneous executors for the same SQL statement are also the same.

[0051] The present invention adds a unique pseudo-transaction tag to the transaction generated by the heterogeneous execution body, and the arbiter normalizes and adjudicates the pseudo-transaction tag carried by the transaction to obtain the target pseudo-transaction tag. The target socket connection is finally determined according to the target pseudo-transaction tag to execute the current transaction. The database transaction is ensured to be executed correctly by executing the database socket connection consistency principle on which the transaction depends.

[0052] It can be understood that after the database transaction is executed correctly, the database needs to synchronize the transaction execution results to each heterogeneous executor so that the logic of each heterogeneous executor continues to run; the specific steps are as follows: the database front-end agent sends the execution result of the target transaction returned by the database to the arbitrator, and the arbitrator distributes the execution result of the target transaction to each heterogeneous executor for updating.

[0053] At the same time, when a transaction executes abnormally, the database must perform a rollback operation and simultaneously return a rollback instruction to the heterogeneous executor based on the transaction's corresponding target socket connection, ensuring synchronous transaction rollback among heterogeneous executors. The specific steps include: the database front-end agent sends the transaction rollback instruction returned by the database to the arbitrator, and the arbitrator distributes the transaction rollback instruction to each heterogeneous executor. The transaction rollback instruction carries a pseudo-transaction marker, allowing the heterogeneous executor to roll back the execution results of the target transaction corresponding to the pseudo-transaction marker.

[0054] It can be understood that as long as the pseudo-transaction tag generation rule can ensure the uniqueness of the generated pseudo-transaction tag, it can be set according to actual needs, such as using the database self-increment sequence or field to generate the ID generation rule or UUID generation rule. This embodiment does not make any public limitations.

[0055] Furthermore, the present invention adds a unique mimetic grouping tag to each SQL statement in the transaction, and the arbiter normalizes and adjudicates the SQL statements in different transactions carrying the target mimetic transaction tag one by one based on the mimetic grouping tag, obtains a single target transaction, and sends the target transaction to the database for operation through the target Socket connection, thereby solving the problem of repeated writing of business data in the process of application mimetic transformation.

[0056] It can be understood that as long as the mimetic grouping tag generation rule can ensure the uniqueness of the generated mimetic grouping tag, it can be set according to actual needs, such as simply the execution sequence number of the SQL statement in the current transaction, or the use of the database self-increment sequence or field to generate the ID generation rule or the UUID generation rule to generate the identifier + the execution sequence number of the SQL statement in the current transaction. This embodiment does not make any public limitation.

[0057] Furthermore, the mimetic architecture also includes a negative feedback center. The arbitrator reports the abnormal conditions of heterogeneous executors encountered during the arbitration process to the negative feedback center, and the negative feedback center completes the cleaning and scheduling of abnormal heterogeneous executors, thereby ensuring the correct execution of transactions by ensuring the health of heterogeneous executors.

[0058] Example 2

[0059] The difference between this embodiment and embodiment 1 is that: it provides a specific embodiment for determining the target Socket connection according to the target mimic transaction tag, such as Figure 2 As shown, the specific steps include:

[0060] Check whether there is a Socket connection associated with the target mimic transaction tag. If so, use the Socket connection as the target Socket connection.

[0061] If it does not exist, determine the heterogeneous executor that sends the transaction carrying the target pseudo-transaction tag, select the heterogeneous executor corresponding to the high-confidence information according to the confidence information of the heterogeneous executor, and associate the Socket connection established by the heterogeneous executor for the transaction with the target pseudo-transaction tag, and then use the Socket connection as the target Socket connection.

[0062] For example, transactions sent by heterogeneous executors 1, 2, and 3 all carry the target pseudo-transaction tag. Heterogeneous executor 1 establishes Socket connection 1 for the transaction, executor 2 establishes Socket connection 2 for the transaction, and executor N establishes Socket connection N for the transaction. If the confidence information between the heterogeneous executors is heterogeneous executor 1 > heterogeneous executor 2 > heterogeneous executor N, then the socket connection finally selected is Socket connection 1 established by heterogeneous executor 1 for the transaction.

[0063] During specific implementation, after associating the Socket connection established by the heterogeneous execution body with the pseudo transaction mark, the pseudo transaction mark and the socket connection association table may be written to facilitate subsequent query.

[0064] In specific implementation, the confidence information of the heterogeneous executors can be updated based on the decision result of the arbitrator. When a certain executor is determined to be abnormal based on the decision result of the arbitrator, the abnormal executor is taken offline for cleaning and its confidence is reduced.

[0065] It can be understood that the heterogeneous executor corresponding to high-confidence information means that the security level of the heterogeneous executor is high and it is not easily attacked. Therefore, the transaction generated by the heterogeneous executor is most likely to be selected as the target transaction. Therefore, selecting the socket connection corresponding to the target transaction with the highest probability of being selected as the target transaction can ensure the matching degree between the transaction and the socket connection to the greatest extent, which is more in line with the consistency principle of the database socket connection that the transaction depends on, and can ensure the correct execution of the database transaction.

[0066] Example 3

[0067] The difference between this embodiment and embodiment 1 is that: it provides a method for normalizing and judging SQL statements in different transactions carrying target mimicry transaction tags one by one based on mimicry grouping tags to obtain a specific embodiment of the target transaction, such as Figure 3 As shown, the specific steps include:

[0068] In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; each group of SQL statements is normalized and adjudicated one by one to obtain the target SQL statement of the group;

[0069] Sort all target SQL statements in execution order to form a target transaction.

[0070] It can be understood that normalization ensures that each set of SQL statements only outputs one SQL statement, so that the target transaction obtained is single, solving the problem of repeated writing of business data during the application mimicry transformation process.

[0071] Furthermore, when attacks are carried out on different execution bodies respectively, the following situation may occur: there are three execution bodies, namely, execution body I, execution body II, and execution body III, and the transactions sent by each execution body include SQL statement 1, SQL statement 2, and SQL statement 3.

[0072] After attack 1 attacks executors II and III, the SQL statement 1 generated by executors II and II is incorrect A. After attack 2 attacks executors I and III, the SQL statement 2 generated by executors I and III is incorrect B. After attack 3 attacks executors I and II, the SQL statement 3 generated by executors I and II is incorrect C. The target SQL statements finally selected are incorrect A, incorrect B, and incorrect C, respectively.

[0073] For details, please refer to Table 1 below.

[0074]

[0075] It can be seen that there may be a situation where all the target SQL statements determined are wrong, resulting in the target transaction composed of these wrong target SQL statements also being an wrong transaction. In this case, if the wrong transaction is sent to the database, it may cause irreparable damage to the database. Therefore, after obtaining the target transaction, it is necessary to verify the correctness of the target transaction.

[0076] The specific steps are as follows:

[0077] Traverse the transactions carrying the target mimic transaction mark to find whether there is a transaction identical to the target transaction. If so, confirm that the target transaction is correct and retain the target transaction. If not, confirm that the target transaction is wrong and report an error.

[0078] Example 4

[0079] This embodiment provides a mimicry defense method for a relational database, which is applied to a arbitrator, such as Figure 4 As shown, the following steps are included:

[0080] Receive transactions sent by different heterogeneous executors, each transaction carries a unique mimetic transaction tag, and each SQL statement in each transaction carries a unique mimetic grouping tag; wherein the mimetic grouping tag includes the execution sequence number of the SQL statement in the current transaction; the unique mimetic transaction tag is generated by the heterogeneous executor and added to the transaction; the unique mimetic grouping tag is generated by the heterogeneous executor and added to the corresponding SQL statement; different heterogeneous executors have the same built-in mimetic transaction tag generation rules and the same built-in mimetic grouping tag generation rules;

[0081] Normalize and adjudicate the pseudo-transaction tag carried by the transaction to obtain a target pseudo-transaction tag, and determine the target socket connection according to the target pseudo-transaction tag; normalize and adjudicate the SQL statements in different transactions carrying the target pseudo-transaction tag one by one based on the pseudo-grouping tag to obtain the target transaction;

[0082] The target Socket connection and the target transaction are sent to the database front-end agent, so that the database front-end agent can send the target transaction to the database for operation based on the target Socket connection.

[0083] Specifically, after a database transaction is correctly executed, the database needs to synchronize the transaction execution result to each heterogeneous executor according to the target Socket connection corresponding to the transaction, so that the logic of each heterogeneous executor continues to run; the specific steps are as follows: the arbiter receives the execution result of the target transaction and distributes it to each heterogeneous executor so that the heterogeneous executor can update data based on the execution result of the target transaction, wherein the execution result of the target transaction is returned to the database front-end agent by the database after the transaction is correctly executed.

[0084] Similarly, when the database performs a transaction rollback operation after executing the transaction abnormally, it is necessary to synchronize the transaction rollback operation to each heterogeneous executor according to the target Socket connection corresponding to the transaction, so that the transaction execution results of each heterogeneous executor are consistent with the database; the specific steps are as follows: the transaction rollback operation instruction forwarded by the database front-end agent is received and distributed to each heterogeneous executor, the transaction rollback operation instruction carries a pseudo-transaction marker, so that the heterogeneous executor will roll back the execution result of the target transaction corresponding to the pseudo-transaction marker; wherein, the transaction rollback operation instruction is generated by the database after executing the transaction abnormally and forwarded to the database front-end agent.

[0085] It can be seen that the present invention adds a unique pseudo-transaction tag to the transaction generated by the heterogeneous execution body, and the arbiter normalizes and adjudicates the pseudo-transaction tag carried by the transaction to obtain the target pseudo-transaction tag. The target Socket connection is finally determined according to the target pseudo-transaction tag to execute the current transaction. By executing the consistency principle of the database Socket connection on which the transaction depends, it is ensured that the database transaction can be correctly executed and rolled back.

[0086] Furthermore, the present invention adds a unique mimetic grouping tag to each SQL statement in the transaction, and the arbiter normalizes and adjudicates the SQL statements in different transactions carrying the target mimetic transaction tag one by one based on the mimetic grouping tag, obtains a single target transaction, and sends the target transaction to the database for operation through the target Socket connection, thereby solving the problem of repeated writing of business data in the process of application mimetic transformation.

[0087] It can be understood that the same pseudo-transaction marker generation rules built into the transaction marking modules on different heterogeneous executors make the unique pseudo-transaction markers generated by different heterogeneous executors for the same transaction the same, and the same pseudo-grouping marker generation rules built into the grouping marking modules on different heterogeneous executors make the unique pseudo-transaction markers generated by different heterogeneous executors for the same SQL statement the same.

[0088] It can be understood that as long as the pseudo-transaction tag generation rule can ensure the uniqueness of the generated pseudo-transaction tag, it can be set according to actual needs, such as using the database self-increment sequence or field to generate the ID generation rule or UUID generation rule. This embodiment does not make any public limitations.

[0089] Similarly, as long as the mimetic grouping tag generation rule can ensure the uniqueness of the generated mimetic grouping tag, it can be set according to actual needs, such as simply the execution sequence number of the SQL statement in the current transaction, or the use of the database self-increment sequence or field to generate the ID generation rule or the UUID generation rule to generate the identifier + the execution sequence number of the SQL statement in the current transaction. This embodiment does not make any public limitations.

[0090] It can be understood that, like other mimic architectures, the arbiter also reports abnormal situations of heterogeneous executors encountered during the arbitration process to the negative feedback center, and the negative feedback center completes the cleaning and scheduling of abnormal heterogeneous executors.

[0091] Example 5

[0092] The difference between this embodiment and embodiment 4 is that: it provides a specific embodiment of determining the target Socket connection according to the target mimic transaction tag, such as Figure 2 As shown, the specific steps include:

[0093] Check whether there is a Socket connection associated with the target mimic transaction tag. If so, use the Socket connection as the target Socket connection.

[0094] If it does not exist, determine the heterogeneous executor that sends the transaction carrying the target pseudo-transaction tag, select the heterogeneous executor corresponding to the high-confidence information according to the confidence information of the heterogeneous executor, and associate the Socket connection established by the heterogeneous executor for the transaction with the target pseudo-transaction tag, and then use the Socket connection as the target Socket connection.

[0095] In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; each group of SQL statements is normalized and adjudicated one by one to obtain the target SQL statement of the group;

[0096] Sort all target SQL statements in execution order to form a target transaction.

[0097] In specific implementation, the confidence information of the heterogeneous executors can be updated based on the decision result of the arbitrator. When a certain executor is determined to be abnormal based on the decision result of the arbitrator, the abnormal executor is taken offline for cleaning and its confidence is reduced.

[0098] It can be understood that the heterogeneous executor corresponding to high-confidence information means that the security level of the heterogeneous executor is high and it is not easily attacked. Therefore, the transaction generated by the heterogeneous executor is most likely to be selected as the target transaction. Therefore, selecting the socket connection corresponding to the target transaction with the highest probability of being selected as the target transaction can ensure the matching degree between the transaction and the socket connection to the greatest extent, which is more in line with the consistency principle of the database socket connection that the transaction depends on, and can ensure the correct execution of the database transaction.

[0099] Example 6

[0100] The difference between this embodiment and embodiment 4 is that: it provides a method for normalizing and judging SQL statements in different transactions carrying target mimicry transaction tags one by one based on mimicry grouping tags to obtain a specific embodiment of the target transaction, such as Figure 3 As shown, the specific steps include:

[0101] In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; each group of SQL statements is normalized and adjudicated one by one to obtain the target SQL statement of the group;

[0102] Sort all target SQL statements in execution order to form a target transaction.

[0103] It can be understood that normalization ensures that each set of SQL statements only outputs one SQL statement, so that the target transaction obtained is single, solving the problem of repeated writing of business data during the application mimicry transformation process.

[0104] Furthermore, when attacks are carried out on different execution bodies respectively, the following situation may occur: there are three execution bodies, namely, execution body I, execution body II, and execution body III, and the transactions sent by each execution body include SQL statement 1, SQL statement 2, and SQL statement 3.

[0105] After attack 1 attacks executors II and III, the SQL statement 1 generated by executors II and II is incorrect A. After attack 2 attacks executors I and III, the SQL statement 2 generated by executors I and III is incorrect B. After attack 3 attacks executors I and II, the SQL statement 3 generated by executors I and II is incorrect C. The target SQL statements finally selected are incorrect A, incorrect B, and incorrect C, respectively.

[0106] For details, please refer to Table 1 below.

[0107]

[0108] It can be seen that there is a possibility that all the target SQL statements determined are incorrect, which will cause the target transaction composed of these incorrect target SQL statements to be an incorrect transaction. In this case, if the incorrect transaction is sent to the database, it may cause irreparable damage to the database. Therefore, after obtaining the target transaction, it is necessary to verify the correctness of the target transaction. The specific steps are as follows:

[0109] Traverse the transactions carrying the target mimic transaction mark to find whether there is a transaction identical to the target transaction. If so, confirm that the target transaction is correct and retain the target transaction. If not, confirm that the target transaction is wrong and report an error.

[0110] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A mimetic architecture of a relational database, characterized in that: include: The transaction marking module located on each heterogeneous executor is used to add a unique pseudo-transaction marker to the transaction; A group marking module located on each heterogeneous execution body is used to add a unique pseudo-grouping mark to each SQL statement in the transaction, wherein the pseudo-grouping mark includes an execution sequence number of the SQL statement in the current transaction; The arbiter located on the database front-end agent is used to receive the transaction sent by the heterogeneous executor, normalize and adjudicate the pseudo transaction tag carried by the transaction, obtain the target pseudo transaction tag, and determine the target socket connection according to the target pseudo transaction tag; Determine the target Socket connection based on the target mimic transaction tag, including: Find out whether there is a Socket connection associated with the target mimic transaction tag. If so, use the Socket connection as the target Socket connection. If it does not exist, determine the heterogeneous executor that sent the transaction carrying the target pseudo-transaction tag, select the heterogeneous executor corresponding to the high-confidence information based on the confidence information of the heterogeneous executor, associate the socket connection established by the heterogeneous executor for the transaction with the target pseudo-transaction tag, and then use the socket connection as the target socket connection; Normalize and adjudicate SQL statements in different transactions carrying target mimic transaction tags one by one based on the mimic grouping tags to obtain the target transaction; and send the target socket connection and the target transaction to the database front-end agent, so that the database front-end agent sends the target transaction to the database for operation based on the target socket connection; Among them, the transaction marking module on each heterogeneous executor generates a unique mimetic transaction mark based on the built-in mimetic transaction mark generation rule, and the grouping marking module on each heterogeneous executor generates a unique mimetic grouping mark based on the built-in mimetic transaction grouping generation rule. The mimetic transaction mark generation rules built into different transaction marking modules are the same, and the mimetic grouping mark generation rules built into different grouping marking modules are the same.

2. The mimetic architecture of a relational database according to claim 1, wherein: Based on the mimicry grouping tag, the SQL statements in different transactions carrying the target mimicry transaction tag are normalized and judged one by one to obtain the target transaction, including: In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; each group of SQL statements is normalized and adjudicated one by one to obtain the target SQL statement of the group; Sort all target SQL statements in execution order to form a target transaction.

3. The mimetic architecture of a relational database according to claim 2, characterized in that: After obtaining the target transaction, traverse the transactions carrying the target pseudo-transaction tag to find out whether there is a transaction identical to the target transaction. If so, confirm that the target transaction is correct and retain the target transaction. If not, confirm that the target transaction is wrong and report an error.

4. The mimetic architecture of a relational database according to claim 1, wherein: The arbiter receives the database execution result of the target transaction returned by the database front-end agent, and distributes it to each heterogeneous execution body for updating; Alternatively, the arbiter receives a transaction rollback operation instruction generated by the database and returned by the database front-end agent, and distributes it to each heterogeneous executor. The transaction rollback operation instruction carries a pseudo-transaction marker, so that the heterogeneous executor can roll back the execution result of the target transaction corresponding to the pseudo-transaction marker.

5. A mimicry defense method for a relational database, applied to a arbitrator, characterized in that: The following steps are involved: Receive transactions sent by different heterogeneous executors, each transaction carries a unique mimetic transaction tag, and each SQL statement in each transaction carries a unique mimetic grouping tag; wherein the mimetic transaction tag generation rules built into the different heterogeneous executors are the same, and the built-in mimetic grouping tag generation rules are the same, and the mimetic grouping tag includes the execution sequence number of the SQL statement in the current transaction; Normalize and adjudicate the pseudo-transaction tag carried by the transaction to obtain a target pseudo-transaction tag, and determine the target socket connection according to the target pseudo-transaction tag; normalize and adjudicate the SQL statements in different transactions carrying the target pseudo-transaction tag one by one based on the pseudo-grouping tag to obtain the target transaction; Determine the target Socket connection based on the target mimic transaction tag, including: Find out whether there is a Socket connection associated with the target mimic transaction tag. If so, use the Socket connection as the target Socket connection. If it does not exist, determine the heterogeneous executor that sent the transaction carrying the target pseudo-transaction tag, select the heterogeneous executor corresponding to the high-confidence information based on the confidence information of the heterogeneous executor, associate the socket connection established by the heterogeneous executor for the transaction with the target pseudo-transaction tag, and then use the socket connection as the target socket connection; The target Socket connection and the target transaction are sent to the database front-end agent, so that the database front-end agent can send the target transaction to the database for operation based on the target Socket connection.

6. A mimicry defense method for a relational database according to claim 5, characterized in that: In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; Normalize and judge each group of SQL statements one by one to obtain the target SQL statement of the group; Sort all target SQL statements in execution order to form a target transaction.

7. A mimicry defense method for a relational database according to claim 5 or 6, characterized in that: Based on the mimicry grouping tag, the SQL statements in different transactions carrying the target mimicry transaction tag are normalized and judged one by one to obtain the target transaction, including: In different transactions carrying the target mimic transaction tag, SQL statements are grouped according to the mimic grouping tag, and SQL statements with the same mimic grouping tag are grouped together; each group of SQL statements is normalized and adjudicated one by one to obtain the target SQL statement of the group; Sort all target SQL statements in execution order to form a target transaction.

8. The mimicry defense method for a relational database according to claim 7, characterized in that: After obtaining the target transaction, traverse the transactions carrying the target pseudo-transaction tag to find out whether there is a transaction identical to the target transaction. If so, confirm that the target transaction is correct and retain the target transaction. If not, confirm that the target transaction is wrong and report an error.

9. The mimicry defense method for a relational database according to claim 6, characterized in that: receiving the execution result of the target transaction forwarded by the database front-end agent, and distributing the result to each heterogeneous execution body, so that the heterogeneous execution body can perform data update based on the execution result of the target transaction; receiving a transaction rollback instruction forwarded by the database front-end agent, and distributing the instruction to each heterogeneous executor, wherein the transaction rollback instruction carries a pseudo-transaction marker, so that the heterogeneous executor can roll back the execution result of the target transaction corresponding to the pseudo-transaction marker; The execution result of the target transaction is returned to the database front-end agent by the database after the transaction is correctly executed; the transaction rollback operation instruction is generated by the database after the transaction is abnormally executed and forwarded to the database front-end agent.

Images