Database bidirectional synchronization method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a database bidirectional synchronization method and device, computer equipment, a readable storage medium and a program product, and relates to the technical field of big data processing. The method comprises the following steps: determining a source database and a target database from a plurality of monitored databases; comparing the source label of the change data in the source database with the source label corresponding to the target database to obtain a comparison result; and under the condition that the comparison result meets a preset condition, synchronizing the change data to the target database. By adopting the method, the problem of data cycle synchronization in the database synchronization process can be avoided, so that the two-way synchronization of the database is supported.

Description

Technical Field

[0001] The present application relates to the technical field of big data processing, and in particular, to a method, device, computer device, readable storage medium, and program product for two-way database synchronization. Background Art

[0002] During the process of two-way database synchronization, the phenomenon of "data loop" often occurs. When data changes occur in one database, the changed data will be synchronized to the other database, causing the data in the other database to change. The changes in the data of the other database will then be synchronized back. That is to say, the changed data in one database will be synchronized back to this database again, resulting in the same data being synchronized back and forth between the cloud and the edge, thus causing the "data loop" phenomenon, resulting in a sharp decline in database performance, continuously occupying bandwidth and system resources, and making it impossible to guarantee the synchronization of normal business data and the operation of the business system. Therefore, the current database data synchronization method cannot support two-way database synchronization. Summary of the Invention

[0003] Based on this, it is necessary to provide a method, device, computer device, computer-readable storage medium, and computer program product for two-way database synchronization that can support two-way database synchronization in view of the above technical problems.

[0004] In a first aspect, the present application provides a method for two-way database synchronization, including:

[0005] Determine a source database and a target database from multiple monitored databases;

[0006] Compare the source label of the changed data in the source database with the corresponding source label of the target database to obtain a comparison result;

[0007] When the comparison result meets a preset condition, synchronize the changed data to the target database.

[0008] In one embodiment, the step of determining a source database and a target database from multiple monitored databases includes:

[0009] Parse the log events of each database to obtain the parsed data of each database;

[0010] When it is monitored that any of the parsed data has changed, determine the database corresponding to the changed parsed data as the source database, and use the changed parsed data as the changed data;

[0011] Determine the database to which the changed data is to be synchronized as the target database.

[0012] In one embodiment, before comparing the source label of the changed data in the source database with the corresponding source label of the target database to obtain a comparison result, the method further includes:

[0013] Detecting whether the changed data has a source label to obtain a label detection result;

[0014] In the case where the label detection result indicates that the changed data does not have a source label, adding the source label corresponding to the source database to the changed data.

[0015] In one embodiment, the database two-way synchronization method further includes:

[0016] In the case where the comparison result indicates that the source label of the changed data is inconsistent with the source label of the target database, determining that the comparison result meets a preset condition.

[0017] In one embodiment, the database two-way synchronization method further includes:

[0018] In the case where the comparison result indicates that the source label of the changed data is consistent with the source label of the target database, stopping synchronizing the changed data to the target database.

[0019] In one embodiment, synchronizing the changed data to the target database includes:

[0020] Performing serialization processing or deserialization processing on the changed data to obtain data to be synchronized;

[0021] Synchronizing the data to be synchronized to the target database.

[0022] In a second aspect, the present application further provides a database two-way synchronization device, including:

[0023] A database determination module, configured to determine a source database and a target database from multiple monitored databases;

[0024] A label comparison module, configured to compare the source label of the changed data in the source database with the corresponding source label of the target database to obtain a comparison result;

[0025] A data synchronization module, configured to synchronize the changed data to the target database when the comparison result meets a preset condition.

[0026] In a third aspect, the present application further provides a computer device, including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0027] Determine the source database and the target database from multiple monitored databases;

[0028] Compare the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result;

[0029] When the comparison result meets the preset conditions, synchronize the changed data to the target database.

[0030] Fourthly, the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0031] Determine the source database and the target database from multiple monitored databases;

[0032] Compare the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result;

[0033] When the comparison result meets the preset conditions, synchronize the changed data to the target database.

[0034] Fifthly, the present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0035] Determine the source database and the target database from multiple monitored databases;

[0036] Compare the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result;

[0037] When the comparison result meets the preset conditions, synchronize the changed data to the target database.

[0038] For the above database two-way synchronization method, device, computer device, computer-readable storage medium and computer program product, the method determines the source database and the target database from multiple monitored databases as the two ends for data synchronization, compares the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result, so as to determine whether the source of the changed data is the target database. When the comparison result meets the preset conditions, it indicates that the initial source of the changed data is not the target database, and synchronize the changed data to the target database, avoiding the data loop problem caused by the changed data from the target database being synchronously reversed to the target database, thereby realizing the two-way data synchronization between databases. Brief Description of the Drawings

[0039] To more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the accompanying drawings required for the description of the embodiments of the present application or related technologies. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0040] Figure 1 It is an application environment diagram of the database two-way synchronization method in an embodiment;

[0041] Figure 2 It is a schematic flowchart of the database two-way synchronization method in an embodiment;

[0042] Figure 3 It is a schematic flowchart of the database two-way synchronization method in another embodiment;

[0043] Figure 4 It is a structural block diagram of the database two-way synchronization device in an embodiment;

[0044] Figure 5 It is an internal structure diagram of a computer device in an embodiment. Specific implementation manners

[0045] In order to make the purpose, technical solutions and advantages of the present application more clear, the following further details the present application in combination with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0046] As described in the background art, the data synchronization method of the database in the related technology has the problem of not supporting two-way database synchronization. After research by the inventor, it is found that the reason for this problem is that Flink CDC (Flink ChangeData Capture) is a data integration tool based on the Apache Flink (an open-source, distributed stream processing framework) stream processing engine, focusing on the change data capture technology to capture data changes in data sources such as databases in real time, and process and transmit these changed data in the form of a stream to achieve functions such as real-time synchronization, fusion and distribution of data between different systems, and provide support for various big data application scenarios such as real-time data analysis, data warehouse update, and data migration. The existing data synchronization of FlinkCDC only supports one-way data synchronization, which will cause circular synchronization of data between the source (source database) and sink (target database) libraries, resulting in a sharp decline in database performance, continuously occupying bandwidth and system resources, and ensuring that normal business data synchronization and business system operation cannot be guaranteed.

[0047] For the above reasons, the present application provides a database two-way synchronization method, aiming to support database two-way synchronization.

[0048] The database two-way synchronization method provided by the embodiments of the present application can be applied to an application environment as Figure 1 shown. The application environment includes: Flink CDC data synchronization tool 102, source database 104, and target database 106. Among them, the Flink CDC data synchronization tool 102 can be deployed on a server, and the source database 104 and the target database 106 can be integrated on the server or placed on the cloud or other network servers. The Flink CDC data synchronization tool 102 determines the source database 104 and the target database 106 from multiple monitored databases, compares the source tags of the changed data in the source database 104 with the corresponding source tags of the target database 106 to obtain a comparison result. When the comparison result meets the preset conditions, the Flink CDC data synchronization tool 102 synchronizes the changed data to the target database 106.

[0049] In an exemplary embodiment, as Figure 2 shown, a database two-way synchronization method is provided. Taking the Flink CDC data synchronization tool 102 system in Figure 1 as an example, the method includes the following steps S202 to S206. Among them:

[0050] Step S202: Determine the source database and the target database from multiple monitored databases.

[0051] Among them, a database is a collection of structured data, usually stored electronically in a computer system. In this embodiment, the database is the database accessed and monitored by the Flink CDC data synchronization tool; the source database can be a database with changed data during the monitoring process, and the target database can be a database that needs to be synchronized with the changed data.

[0052] Among them, the Flink CDC data synchronization tool is a streaming data integration framework based on Apache Flink. Its main purpose is to capture data changes in the database in real time and transfer them to the downstream system in the form of a stream. Once the data in the database changes (such as insert, update, delete), Flink CDC can immediately capture these changes and then synchronize the changed data to other systems in real time, such as data warehouses, search engines, caches, etc.

[0053] Optionally, the system determines a source database where data has changed and a target database that needs to be synchronized with the changed data from multiple databases that need to synchronize changed data monitored. It should be noted that in the subsequent synchronization process, if the current target database changes data, the current target database will be used as the new source database, and the current source database will be used as the new target database for data synchronization, so as to achieve two-way synchronization.

[0054] Step S204: Compare the source label of the changed data in the source database with the corresponding source label of the target database to obtain a comparison result.

[0055] Among them, changed data refers to all changes that have occurred in the database since the last extraction or backup, such as insertions, updates, or deletions. An insertion adds a new record to the database, an update modifies an existing record in the database, and a deletion removes a record from the database; changed data may also include changes to metadata, such as schema changes or permission changes. Schema changes include adding, deleting, or modifying tables, columns, indexes, or constraints, and permission changes include granting or revoking access permissions for users or roles.

[0056] Among them, the source label can be the label corresponding to the database where the changed data was initially generated.

[0057] Optionally, the system compares the source label of the changed data in the source database with the source label of the target database to obtain a comparison result, so as to determine whether the changed data to be synchronized comes from the target database to be synchronized.

[0058] Step S206: Synchronize the changed data to the target database when the comparison result meets the preset conditions.

[0059] Among them, the preset condition can be that the comparison result of the source label of the changed data and the source label of the target database is that the source labels are different.

[0060] Optionally, when the comparison result meets the preset conditions, it means that the initial source of the changed data is not the target database. If there will be no data loop problem after synchronizing the changed data to the target database, the system synchronizes the changed data to the target database.

[0061] In the above database two-way synchronization method, the method determines the source database and the target database from multiple monitored databases as the two ends for data synchronization, compares the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result, and determines whether the source of the changed data is the target database. When the comparison result meets the preset conditions, it indicates that the initial source of the changed data is not the target database, and the changed data is synchronized to the target database, avoiding the data loop problem caused by the changed data from the target database being reversely synchronized to the target database, thereby realizing the two-way data synchronization between databases.

[0062] In an exemplary embodiment, step S202 of determining the source database and the target database from multiple monitored databases includes:

[0063] Parsing the log events of each database to obtain the parsing data of each database; when it is monitored that any parsing data has changed, determining the database corresponding to the changed parsing data as the source database, and using the changed parsing data as the changed data; and determining the database to which the changed data to be synchronized is the target database.

[0064] Among them, the log event may refer to an event recorded by the database management system regarding database operations, status changes, and error information, and these events are written into the log records for fault recovery, audit tracking, performance analysis, and security monitoring.

[0065] Among them, the parsing data may be the relevant data of the data processing event of the database parsed from the log event.

[0066] Optionally, there is a connector between the Flink CDC data synchronization tool of the system and the database, and data is read from the log events (binlog) in the monitored database through the connector. Since the Flink CSC tool needs to support the two-way synchronization of the database, the source code of the connector part of the Flink CDC tool not only sets the logic of parsing the log events from the source database and synchronizing them to the target database, but also sets the logic of parsing the log events from the target database and synchronizing them to the source database. The system parses the log events of each database to obtain the parsing data of each database. When it is monitored that any parsing data has changed, such as in the case of data insertion, data update, or data deletion, the system determines the database corresponding to the changed parsing data as the source database, and determines the database to which the changed data to be synchronized as the target database.

[0067] In this embodiment, the Flink CDC tool realizes bidirectional synchronization between databases through a connector, captures data changes by using log events (binlog), realizes real-time bidirectional synchronization between databases, and has advantages such as automation, flexibility, and high efficiency. It not only improves data consistency and real-time performance but also simplifies the development and maintenance processes and is applicable to various complex business scenarios.

[0068] In an exemplary embodiment, before step S204 compares the source label of the changed data in the source database with the corresponding source label in the target database to obtain a comparison result, it further includes:

[0069] Detect whether the changed data has a source label to obtain a label detection result; in the case where the label detection result indicates that the changed data does not have a source label, add the source label corresponding to the source database to the changed data.

[0070] Among them, the label detection result may include whether the changed data has a source label and the information of the source label.

[0071] Optionally, the system detects whether the changed data has a source label to obtain a label detection result. In the case where the label detection result indicates that the changed data has a source label, read the information of the source label to lay a foundation for subsequent data synchronization. In the case where the label detection result indicates that the changed data does not have a source label, add the source label corresponding to the source database to the changed data.

[0072] It should be noted that the function implementation of setting the source label for the changed data is achieved by modifying the API (Application Programming Interface) of Flink CDC. Some logic of the stream operation needs to be modified, and an additional stream processing branch is added to process the data for reverse synchronization. Based on the preset source label, the changed data parsed from the log event stream is bound to the source database. In this way, by parsing the stream to read the source label of the changed data, the problem of circular bidirectional synchronization can be avoided. At the same time, it also involves modifications to state management. In the flink-runtime module, because bidirectional synchronization may require additional state storage and recovery logic to ensure that the state of bidirectional synchronization can be correctly restored in case of a failure.

[0073] It can be understood that each monitored database is pre-set with the source label of each database to distinguish the data ownership of each database and avoid duplicate data synchronization.

[0074] In this embodiment, the system will detect whether the source label of the changed data already exists. If it exists, the label information will be read; if not, the source label corresponding to the source database will be automatically added. By clarifying the source of each piece of data, through the source label, the system can determine whether the data has been synchronized, effectively avoiding duplicate synchronization of data, reducing unnecessary data transmission and processing overhead, saving system resources, and improving synchronization efficiency.

[0075] In an exemplary embodiment, the database two-way synchronization method described in the above embodiment further includes:

[0076] In the case where the source label of the changed data in the comparison result is inconsistent with the source label of the target database, it is determined that the comparison result meets the preset conditions.

[0077] Optionally, the system sets a bridging logic in the Flink CDC tool. In the bridging logic, the data streams of the changed data are compared and judged for the source label and the source label of the target database to determine whether the data stream of the changed data can cross the bridge. In the case where the system determines that the source label of the changed data in the comparison result is inconsistent with the source label of the target database, it indicates that the initial source of the changed data is not the target database and can be synchronized, thereby determining that the comparison result meets the preset conditions.

[0078] In this embodiment, when the source label of the changed data is inconsistent with the source label of the target database, it is determined that the comparison result meets the preset conditions, allowing the subsequent synchronization of the changed data to the target database, thereby avoiding the problems of conflicts and circular synchronization caused by the changed data originating from the target database, and enabling the modified Flink CDC tool to support database two-way synchronization.

[0079] In an exemplary embodiment, the database two-way synchronization method described in the above embodiment further includes:

[0080] In the case where the source label of the changed data in the comparison result is consistent with the source label of the target database, stop synchronizing the changed data to the target database.

[0081] Optionally, when the comparison result is that the source label of the changed data is consistent with the source label of the target database, it indicates that the comparison result does not meet the preset conditions, and the initial source of the changed data is the target database. If synchronization is performed, it will cause circular synchronization, and the system stops synchronizing the changed data to the target database.

[0082] In this embodiment, when it is detected that the source label of the changed data is consistent with the source label of the target database, data synchronization is stopped, avoiding the problem of data loops and ensuring the normal operation of the system.

[0083] In an exemplary embodiment, synchronizing the changed data to the target database content in step S206 includes:

[0084] Performing serialization processing or deserialization processing on the changed data to obtain the data to be synchronized; synchronizing the data to be synchronized to the target database.

[0085] Among them, serialization processing can be a process of converting the state of a data structure or object into a storable or transmittable format. In other words, it is to convert the data in memory (for example, a complex object) into forms such as a byte stream or a string. Deserialization processing can be a process of restoring the serialized data format (for example, a byte stream or a string) to the original data structure or object state.

[0086] Optionally, when the system performs serialization processing or deserialization processing on the changed data to obtain the data to be synchronized, it can be understood that serialization processing is used when the changed data has not been serialized, the format of the changed data is adapted to the source database but not to the target database. In this case, serialization processing is performed on the changed data to obtain the data to be synchronized; and deserialization processing means that the changed data has been serialized, the previous format of the changed data is adapted to the target database format, so deserialization processing is to be performed to obtain the synchronized data in a format adapted to the target database, and the data to be synchronized is synchronized to the target database in the form of a data stream.

[0087] In this embodiment, performing serialization processing or deserialization processing on the changed data to obtain the data to be synchronized, and synchronizing the data to be synchronized to the target database ensures the compatibility of data between different databases during the synchronization process.

[0088] In an exemplary embodiment, as Figure 3 shown, another method for two-way database synchronization is provided, including:

[0089] Step 1, when responsible for reading the original data, add the data source alias, that is, the database name (source label) to which the data belongs, through the custom addTagFunction (tag addition) function.

[0090] Figure 3 In it, source DB is the source database and sink DB is the target database.

[0091] Exemplarily, modify the Flink CDC core source code: First, locate the core code library of Flink CDC, which usually involves operations on database connectors (such as MySQL, PostgreSQL, etc.). These source codes are responsible for reading data from the binlog of the database. For MySQL (a database), the relevant code of MySQL CDC needs to be concerned. This part of the code is located in the flink-connector-mysql-cdc (MySQL database connector) module. The main modification point is in the processing logic of binlog events, because two-way synchronization requires handling binlog information from source to target and from target to source. For example, the original code may only handle the logic of reading binlog from the source database and synchronizing it to the target. The logic of reading binlog from the target database and synchronizing it back to the source needs to be added. The code for parsing and consuming binlog events needs to be modified to ensure that corresponding operations can be performed according to different binlog event types (such as insert, update, delete), and determine whether to block the data bridging logic by judging the tag information. Conflicts and loop synchronization problems that may occur need to be handled.

[0092] Step 2, add a bridging controller in the data writing addSink (target addition) module, add judgment logic, deserialize the tag information (source label) in the data stream, compare the database name with the database (target database) to be written. If they are different, the data bridges and is normally written to the target database.

[0093] Exemplarily, considering the transmission and processing of data in Flink, it may be necessary to modify the data serialization and deserialization code. These codes are distributed in the flink-formats module. For two-way synchronization, it is necessary to ensure the consistency and correctness of data during transmission in different directions. The existing serializers and deserializers need to be modified to meet the requirements of two-way data flow. When synchronizing data from the source database to the target database, the data needs to be serialized into a certain format. When synchronizing in the reverse direction, the data read from the target database also needs to be correctly deserialized and then corresponding operations are performed. Modifications need to be made to the core API of Flink because two-way synchronization involves the stream processing logic of Flink. For example, in the flink-core module, some logic of stream operations needs to be modified, and additional stream processing branches need to be added to handle the data for reverse synchronization. Mainly, the biglog stream is parsed and bound to the source database source for tagging. In this way, by parsing the tags of the binlog through the stream reading, the problem of circular two-way synchronization can be avoided. At the same time, modifications related to state management are involved. In the flink-runtime module, because two-way synchronization may require additional state storage and recovery logic to ensure that the state of two-way synchronization can be correctly restored in case of failures. The codes of sub-modules such as flink-json and flink-avro related to serialization and deserialization also need to be modified. Additional logic needs to be added to read the configuration items and bind the configuration items of the data source to handle the serialization, deserialization, and verification issues of two-way data, ensuring that the data is synchronized only once and the consistency of the data format.

[0094] Step 3. This step is the reverse process of the previous step. The data bridge determines the database tag information in the data stream and blocks the situation of writing to the target database. Cooperating with the previous step, it avoids writing the data back to the initial database again, thus avoiding the problems of data circular synchronization and database performance exhaustion.

[0095] Exemplarily, the binary data deserializer converts to a JSON-formatted string. The preset data source flag is read to verify the data source information to determine whether it is a two-way synchronization loop scenario. If so, the process is directly blocked. If not, the task can continue to execute and write to the template target database normally. If data records need to be transmitted across the network between Flink tasks, the data needs to be serialized and then written to the NetworkBufferPool (a class for managing buffers used in network operations). Then, the lower-level Task reads it out and performs deserialization operations, and finally, logical processing is carried out. To enable records and events to be written to the Buffer and then read from the Buffer during consumption, Flink provides a data record serializer (RecordSerializer), a deserializer (RecordDeserializer), and an event serializer (EventSerializer). The data sent by the Function is encapsulated into a SerializationDelegate (a serialization object), which exposes any element as an IOReadableWritable (an interface) for serialization, and the data to be serialized is passed in through "setInstance()" (updating the object instance). When constructing the StreamTransformation, the input and output types of the Function are determined through the TypeExtractor tool. The TypeExtractor class can automatically extract or restore type information based on clues such as method signatures and subclass information.

[0096] In this embodiment, in terms of technical implementation, by modifying the FlinkCDC source code to add data source tags to the binlog, the two-way synchronization of the database is successfully achieved, laying a solid technical foundation for the cross-region two-way synchronization of the group's data, strongly supporting the feasibility of subsequent cross-region real-time data synchronization and big screen aggregation, and ensuring that data can flow and be integrated efficiently and accurately between different regions. On the one hand, the economic cost is significantly reduced, avoiding additional investments that may be incurred due to poor data synchronization, such as purchasing expensive data synchronization software or building a complex data transmission architecture. On the other hand, the labor cost is greatly saved. The automated data synchronization mechanism significantly reduces manual intervention and manual operations, freeing up human resources to be invested in more valuable data analysis and business innovation.

[0097] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0098] Based on the same inventive concept, an embodiment of the present application also provides a database two-way synchronization device for implementing the above-mentioned database two-way synchronization method. The implementation solutions provided by this device to solve problems are similar to the implementation solutions described in the above method. Therefore, the specific limitations in one or more embodiments of the database two-way synchronization device provided below can refer to the limitations on the database two-way synchronization method in the above text, and will not be repeated here.

[0099] In an exemplary embodiment, as Figure 4 shown, a database two-way synchronization device 400 is provided, including: a database determination module 402, a tag comparison module 404, and a data synchronization module 406, where:

[0100] The database determination module 402 is configured to determine a source database and a target database from multiple monitored databases.

[0101] The tag comparison module 404 is configured to compare the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result.

[0102] The data synchronization module 406 is configured to synchronize the changed data to the target database when the comparison result meets a preset condition.

[0103] Further, in an embodiment, the database determination module 402 is further configured to parse the log events of each database to obtain the parsed data of each database; when it is monitored that any parsed data has changed, determine the database corresponding to the changed parsed data as the source database, and use the changed parsed data as the changed data; determine the database to which the changed data to be synchronized is the target database.

[0104] Further, in one embodiment, the label comparison module 404 is further configured to detect whether there is a source label for the changed data to obtain a label detection result; and in the case that the label detection result indicates that there is no source label for the changed data, add a source label corresponding to the source database to the changed data.

[0105] Further, in one embodiment, the label comparison module 404 is further configured to determine that the comparison result meets a preset condition when the source label of the changed data is inconsistent with the source label of the target database in the comparison result.

[0106] Further, in one embodiment, the label comparison module 404 is further configured to stop synchronizing the changed data to the target database when the source label of the changed data is consistent with the source label of the target database in the comparison result.

[0107] Further, in one embodiment, the data synchronization module 406 is further configured to perform serialization processing or deserialization processing on the changed data to obtain data to be synchronized; and synchronize the data to be synchronized to the target database.

[0108] Each module in the above database two-way synchronization device 400 can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor in the computer device in hardware form or be independent of the processor, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0109] In an exemplary embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 5 shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as changed data, source labels of changed data, and source labels of the target database. The input / output interface of the computer device is used for the processor to exchange information with external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. The computer program, when executed by the processor, implements a database two-way synchronization method.

[0110] Those skilled in the art can understand,Figure 5 The structure shown is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0111] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0112] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0113] In one embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0114] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logics based on quantum computing, artificial intelligence (AI) processors, etc., without limitation.

[0115] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered to be within the scope recorded in the present application.

[0116] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.

Claims

1. A database bidirectional synchronization method, characterized in that: The method comprises: Determine the source database and the target database from among the multiple monitored databases; Compare the source tags of the changed data in the source database with the corresponding source tags in the target database to obtain a comparison result; When the comparison result meets a preset condition, the changed data is synchronized to the target database.

2. The method according to claim 1, characterized in that Determining the source database and the target database from the monitored multiple databases includes: Parsing the log events of each of the databases to obtain parsed data of each of the databases; In the case where any of the parsed data is monitored to have a change, the database corresponding to the parsed data with a change is determined as the source database, and the parsed data with a change is used as the change data; The database to be synchronized with the changed data is determined as a target database.

3. The method according to claim 1, characterized in that: Before comparing the source tags of the changed data in the source database with the source tags corresponding to the target database to obtain the comparison result, the method further includes: Detect whether the changed data has a source tag, and obtain a tag detection result; When the tag detection result is that the changed data does not have a source tag, a source tag corresponding to the source database is added to the changed data.

4. The method according to claim 1, characterized in that The method further comprises: When the comparison result is that the source tag of the changed data is inconsistent with the source tag of the target database, it is determined that the comparison result meets a preset condition.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: When the comparison result is that the source tag of the changed data is consistent with the source tag of the target database, synchronizing the changed data to the target database is stopped.

6. The method according to claim 1, characterized in that The step of synchronizing the changed data to the target database includes: Serializing or deserializing the changed data to obtain data to be synchronized; The data to be synchronized is synchronized to the target database.

7. A database bidirectional synchronization device, characterized in that: The device comprises: A database determination module is used to determine a source database and a target database from multiple monitored databases; A label comparison module, used to compare the source label of the changed data in the source database with the corresponding source label of the target database to obtain a comparison result; The data synchronization module is used to synchronize the changed data to the target database when the comparison result meets the preset conditions.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images