CN115687503A - Method, device and equipment for synchronizing data among databases and storage medium - Google Patents

Abstract

The disclosure provides a method, a device, equipment and a storage medium for data synchronization among databases, and relates to the technical field of databases. The method comprises the following steps: the first database acquires a log of the second database; the first database analyzes the log of the second database to obtain a target transaction number and an identifier of a currently circulated database of a target transaction corresponding to the executed target transaction number, wherein the identifier of the currently circulated database comprises the identifier of the second database; determining that the identifier of the currently circulated database does not comprise the identifier of the first database, and executing a target transaction in the first database; and generating a log of the first database, wherein the log of the first database comprises the target transaction number and the identification of the updated circulated database of the executed target transaction, and the identification of the updated circulated database comprises the identification of the second database and the identification of the first database. The method can avoid repeated synchronization data.

Description

Method, device, equipment and storage medium for synchronizing data among databases

Technical Field

The present disclosure relates to the field of database technologies, and in particular, to a method and an apparatus for synchronizing data between databases, an electronic device, and a computer-readable storage medium.

Background

Data replication between databases (otherwise referred to as data synchronization) mainly relies on the playback of binary logs (binlogs), such as building a slave database to a master database, and keeping the binary logs consistent with the data of the master database by pulling and replaying the slave database. In some cases, such as a sudden database failure, continued replication of data after repair, and such as a circular synchronization between databases, etc., it may occur that executed transactions are repeatedly executed.

In the related art, a Global Transaction Identifier (GTID) is introduced into MySQL (relational database management system) in version 5.6 to identify a location where a certain database executes a Transaction, so that when data replication is performed next time, it can be quickly determined which transactions have already been executed, and data confusion caused by repeated execution of executed requests can be avoided. However, in actual scenes such as a database that does not support GTID, or a GTID that cannot be set due to restriction, the problem of duplicate data cannot be solved.

As described above, how to provide a data synchronization method with stronger applicability to avoid repeated execution of transactions becomes an urgent problem to be solved.

The above information disclosed in this background section is only for enhancement of understanding of the background of the disclosure and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.

Disclosure of Invention

The present disclosure is directed to a method, an apparatus, a device and a readable storage medium for synchronizing data between databases, which at least to some extent improves applicability.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

The embodiment of the disclosure provides a method for synchronizing data among databases, which includes: the first database acquires a log of the second database; the first database analyzes the log of the second database to obtain a target transaction number and an identifier of a currently circulated database of a target transaction corresponding to the executed target transaction number, wherein the identifier of the currently circulated database comprises the identifier of the second database; determining that the identifier of the currently circulated database does not include the identifier of the first database, and executing the target transaction in the first database; generating a log of the first database, wherein the log of the first database comprises the target transaction number and an identification of an updated circulated database in which the target transaction is executed, and the identification of the updated circulated database comprises an identification of the second database and an identification of the first database.

The embodiment of the present disclosure provides a data synchronization device between databases, including: the second database log acquisition module is used for acquiring logs of a second database by the first database; a second database log analyzing module, configured to analyze, by the first database, a log of the second database, to obtain a target transaction number and an identifier of a currently circulated database in which a target transaction corresponding to the target transaction number is executed, where the identifier of the currently circulated database includes the identifier of the second database; the target transaction determination execution module is used for determining that the identifier of the currently circulated database does not comprise the identifier of the first database, and executing the target transaction in the first database; a first database log generating module, configured to generate a log of the first database, where the log of the first database includes the target transaction number and an identifier of an updated circulated database in which the target transaction has been executed, and the identifier of the updated circulated database includes an identifier of the second database and an identifier of the first database.

According to an embodiment of the present disclosure, the second database log obtaining module includes: a link establishing module for establishing a link from the second database to the first database; the database identifier generation module is used for generating the identifier of the first database if the identifier of the first database does not exist; a routing table establishing module, configured to establish a routing table in the first database; and the second database log takeover module is used for starting the replication component by the first database and taking over the log of the second database.

According to an embodiment of the present disclosure, the target transaction number includes a first target transaction number, and the identifier of the currently circulated database includes a first currently circulated database identifier; wherein the second database log parsing module comprises: a first target transaction number obtaining module, configured to analyze, by the first database, the log of the second database to obtain the first target transaction number; a first event sequence obtaining module, configured to, if the type of the first target transaction corresponding to the first target transaction number is a data operation language type, parse the first target transaction to obtain a first event sequence, where the first event sequence includes a first start event, the first currently-circulated database identifier, a first operation statement for first data, and a first end event; and the first routing information recording module is used for recording the first currently circulated database identifier and the data operation language type in the routing table correspondingly.

According to an embodiment of the present disclosure, the identifier for updating the circulated database includes a first updated circulated database identifier; wherein the target transaction determination execution module comprises: a first routing judgment module, configured to obtain the first currently-transferred database identifier from the routing table, and judge whether the first currently-transferred database identifier includes an identifier of the first database; a first target transaction execution module, configured to execute the first target transaction in the first database if the identifier of the first currently circulated database does not include the identifier of the first database; wherein, the first database log generation module comprises: a first circulated database identifier updating module, configured to rewrite the first currently circulated database identifier in the routing table to the first updated circulated database identifier; and the first transaction route writing module is used for correspondingly writing the first updated circulated database identifier and the first target transaction number into a log of the first database.

According to an embodiment of the present disclosure, the target transaction number includes a second target transaction number, and the identifier of the currently circulated database includes a second currently circulated database identifier; wherein the second database log parsing module comprises: a second target transaction number obtaining module, configured to analyze, by the first database, the log of the second database to obtain the first target transaction number; a second event sequence obtaining module, configured to, if the type of the second target transaction corresponding to the second target transaction number is a data definition language routing type, parse the second target transaction to obtain a second event sequence, where the second event sequence includes a second start event, the second currently-circulated database identifier, a first data definition language statement, and a second end event; and the second routing information recording module is used for correspondingly recording the second currently circulated database identifier, the first data definition language statement and the data definition language type in the routing table.

According to an embodiment of the present disclosure, the apparatus further comprises: a third target transaction number obtaining module, configured to analyze, by the first database, the log of the second database to obtain a third target transaction number, where the second target transaction is a routing transaction of a third target transaction corresponding to the third target transaction number; a first data definition language statement obtaining module, configured to parse the third target transaction to obtain the first data definition language statement when it is determined that the type of the third target transaction is the data definition language type; and the second current circulated database identifier obtaining module is used for obtaining the second current circulated database identifier from the routing table according to the first data definition language statement.

According to an embodiment of the present disclosure, the apparatus further comprises: a second route judgment module, configured to obtain the second currently circulated database identifier from the routing table, and judge whether the second currently circulated database identifier includes an identifier of the first database; a second target transaction executing module, configured to execute the second target transaction and the third target transaction in the first database if the identifier of the current second circulated database does not include the identifier of the first database; a second transferred database identifier updating module, configured to rewrite the second currently transferred database identifier in the routing table to the second updated transferred database identifier; and the second transaction routing writing module is used for correspondingly writing the second updated circulated database identifier and the second target transaction number into the log of the first database.

According to an embodiment of the present disclosure, the apparatus further comprises: and the target transaction determining and executing module is used for not executing the target transaction in the first database under the condition that the currently circulated database identification comprises the identification of the first database.

According to an embodiment of the present disclosure, the apparatus further comprises: the log transmission module of the first database is used for transmitting the log of the first database to the second database by the first database, so that the second database analyzes the log of the first database, obtains the target transaction number and the updated circulated database identifier of the executed target transaction, and does not execute the target transaction in the second database under the condition that the updated circulated database identifier comprises the identifier of the second database.

An embodiment of the present disclosure provides an apparatus, including: a memory, a processor and executable instructions stored in the memory and executable in the processor, the processor implementing any of the methods described above when executing the executable instructions.

Embodiments of the present disclosure provide a computer-readable storage medium having stored thereon computer-executable instructions that, when executed by a processor, implement any of the methods described above.

Embodiments of the present disclosure provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method provided in the various alternative implementations described above.

The data synchronization method between databases provided by the embodiments of the present disclosure obtains and analyzes a log of a second database through a first database, obtains a target transaction number and an identifier of a currently circulated database including an identifier of the second database of a target transaction corresponding to an executed target transaction number, determines that the identifier of the currently circulated database does not include the identifier of the first database, executes the target transaction in the first database, updates the identifier of the circulated database of the target transaction so as to include the identifier of the second database and the identifier of the first database, and then generates the log of the first database including the target transaction number and the identifier of the updated circulated database of the executed target transaction. The identification of the circulated database of the executed target transaction and the change of the target transaction are correspondingly recorded in the database log, and the source database log is analyzed and then whether the transaction is executed or not is judged when the target transaction is executed in the data synchronization process of the target database, so that repeated data synchronization can be avoided.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

FIG. 1 shows a schematic diagram of a circular synchronization between databases.

FIG. 2 illustrates an exemplary system architecture diagram to which the present disclosure may be applied.

Fig. 3 is a flowchart illustrating a method for synchronizing data between databases according to an embodiment of the present disclosure.

Fig. 4 is a schematic diagram illustrating a processing procedure of step S302 shown in fig. 3 in an embodiment.

Fig. 5 is a schematic diagram illustrating a routing table in accordance with an exemplary embodiment.

Fig. 6 is a schematic diagram illustrating a processing procedure of steps S304 to S308 shown in fig. 3 in an embodiment.

Fig. 7 is an interaction flow diagram according to the bidirectional synchronization shown in fig. 6.

Fig. 8 is a schematic diagram illustrating the processing procedure of steps S304 to S308 shown in fig. 3 in another embodiment.

Fig. 9 is a flow chart of a method of data synchronization according to the method shown in fig. 6 and 8.

Fig. 10 is an interaction flow diagram of a ring synchronization according to fig. 9.

Fig. 11 is a block diagram illustrating an apparatus for synchronizing data between databases according to an embodiment of the present disclosure.

Fig. 12 is a block diagram illustrating another apparatus for synchronizing data between databases in the embodiment of the present disclosure.

Fig. 13 shows a schematic structural diagram of an electronic device in an embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and a repetitive description thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, apparatus, steps, etc. In other instances, well-known structures, methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

Furthermore, in the description of the present disclosure, unless otherwise explicitly specified or limited, the terms "connected" and the like are to be construed broadly, e.g., can be electrically connected or can communicate with each other; may be directly connected or indirectly connected through an intermediate. "plurality" means at least two, e.g., two, three, etc., unless explicitly defined otherwise. The specific meaning of the above terms in the present disclosure can be understood as a specific case by a person of ordinary skill in the art.

Terms referred to in the embodiments of the present disclosure are explained below.

Database (Database, db): in short, the user can add, query, update, delete and the like to the data in the electronic file cabinet, namely the place for storing the electronic file. A "database" is a collection of data that is stored together in a manner that can be shared by multiple users, has as little redundancy as possible, and is independent of the application.

A Database Management System (DBMS) is a computer software System designed for managing a Database, and generally has basic functions such as storage, interception, security assurance, and backup. The database management system may classify the database according to the database model it supports, such as relational, XML (Extensible Markup Language); or classified according to the type of computer supported, e.g., server cluster, mobile phone; or classified according to the Query Language used, such as SQL (Structured Query Language), XQuery; or by performance impulse emphasis, e.g., maximum size, maximum operating speed; or other classification schemes. Regardless of the manner of classification used, some DBMSs are capable of supporting multiple query languages across categories, for example, simultaneously.

GTID: a Global Transaction Identifier (GTID), a globally unique identifier associated to each committed Transaction generated by the (source) database.

Binlog: the binary log of MySQL is mainly used for copying MySQL between a master server and a slave server.

DDL: the Data Definition Language (SQL) is a Language in which a set of SQL (Structured Query Language) languages is responsible for Data structure Definition and database object Definition.

DML: the Data management Language (SQL) is a set of instructions in the SQL Language that is responsible for executing Data access work on database objects.

As described above, in the case of a database failure generation site, circular synchronization, and the like, a problem of data duplication may occur, for example, fig. 1 shows a circular synchronization diagram between databases, as shown in fig. 1, data written in a database a is synchronized to a database B through a synchronization link 102, is synchronized to a database C through a synchronization link 104, and may be synchronized back to the database C through a synchronization link 106, resulting in an infinite loop of data in the synchronization link. For such problems, mysql5.6 and above may obtain how much data the database has currently replicated based on the location information of the GTID, and if interrupted during replication, may determine from which location to continue replication based on the GTID. However, at least two limitations restrict the application of this method. One of the limitations is to use GTID-supported database, and there are many reasons why MySQL5.6 and above version database is not supported in practical applications, including: a database version which does not support GTID is required to be used, for example, the version of MySQL 5.5 and below does not support GTID, but the version of MySQL 5.5 is still largely used in the environment of Internet Data Center (IDC); the database displays that the GTID state is forbidden and cannot be opened; the cloud service provider prohibits GTID, etc. in some versions. The second limitation is that the external MySQL is adopted, a Super (Super) authority is required for setting GTID in the data synchronization process, and basically all cloud service providers do not provide accounts with the Super authority in the database, which is a more fundamental restriction factor.

Therefore, the present disclosure provides a method for synchronizing data between databases, in which an identifier of a streamed database for which a target transaction has been executed and a target transaction change are recorded in a database log in a corresponding manner, and when the target transaction is executed in a data synchronization process of the target database, a source database log is analyzed and then whether the transaction has been executed is determined, so that data can be prevented from being repeatedly synchronized.

Fig. 2 illustrates an exemplary system architecture 20 to which the inter-database data synchronization methods, apparatus of the present disclosure may be applied.

As shown in fig. 2, the system architecture 20 may include a terminal device 202, a network 204, and a server 206. The terminal device 202 may be various electronic devices having a display screen and supporting input, output, including but not limited to a smartphone, a tablet, a laptop, a desktop computer, a wearable device, a virtual reality device, a smart speaker, a smart watch, a smart home, and so on. The network 204 is used to provide a medium for communication links between the terminal device 202 and the server 206. Network 204 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others, which are not limiting in this application. The server 206 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, a middleware service, a domain name service, a security service, a Content Delivery Network (CDN), a big data and artificial intelligence platform, and the like.

A user may use terminal device 202 to interact with server 206 over network 204 to receive or transmit data, etc. For example, a user operates on a business system application on a terminal device 202, the generated operation data is uploaded to a background processing server through a network 204, and the background processing server synchronizes the data to a database server through the network 204. Also for example, the user may obtain the data synchronization result of the server 206 on the terminal device 202 through the network 204 and view it through the database management software on the terminal device 202.

It should be understood that the number of terminal devices, networks, and servers in fig. 2 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

FIG. 3 is a flowchart illustrating a method of data synchronization between databases, according to an example embodiment. The method shown in fig. 3 may be applied to, for example, a server of the above system, and may also be applied to a terminal device of the above system.

Referring to fig. 3, the method 30 provided by the embodiment of the present disclosure may include the following steps S302 to S308.

In step S302, the first database acquires a log of the second database.

In some embodiments, for example, for the case where the first database and the second database are both MySQL, to synchronize the data of the second database with the first database, the first database may obtain a binary log Binlog of the second database, which records data updates or potential updates of MySQL.

In other embodiments, for example, in the case where the first database and the second database are both Oracle (a database facing an internet computing environment), to synchronize the data of the second database with the first database, the first database may obtain a redo log (redo log) of the second database, which records the operation entry of Oracle.

In some embodiments, a link may be established from the second database to the first database to replicate the Binlog of the second database by a replication component (Replicator), and specific embodiments may refer to fig. 4.

In step S304, the first database parses the log of the second database, and obtains the target transaction number and the identifier of the currently circulated database of the target transaction corresponding to the executed target transaction number, where the identifier of the currently circulated database includes the identifier of the second database.

In some embodiments, for example, in the case that both the first database and the second database are MySQL, when data operation is performed on the databases, database information that data flows through may be recorded in the Binlog of the databases, and the first database may parse the Binlog of the second database to obtain the identifier of the circulated database corresponding to each transaction.

In some embodiments, mySQL may be identified using a Universally Unique Identifier (UUID), for example, a uuuid () function may be used to generate a random 36-bit value as the database Identifier.

In some embodiments, the operations of the database are all in transaction units, the transaction is a logical unit in the execution process of the database management system, and is composed of a limited database operation sequence, and the transactions in the log of the second database can be sequentially used as target transactions for analysis, subsequent replication and other operations.

In some embodiments, for example, the target transaction number includes a first target transaction number and a second target transaction number, and the identification of the currently circulated database includes a first currently circulated database identification and a second currently circulated database identification. The database change operation recorded in the binary log may be divided into two types, namely DDL and DML, which respectively represent the change of the data structure and the change of the data in the data table, and the recording format of the routing information of the two types of transactions in the routing table may refer to fig. 5.

The DDL is represented as an Event (Event) in the binary log, the Event is the minimum unit of the database operation and corresponds to a database operation defined by the above transaction, and the Event corresponding to the DDL type transaction is the DDL statement itself. For example, the third target transaction in FIG. 7 may be a DDL type transaction.

The DML is represented in the binary log as a series of binary events, starting with a Begin event and ending with a Commit event, and there may be a plurality of operations in between, such as inserting a piece of data in the a table (this is an event), deleting a piece of data in the B table (this is another event), and so on, and the form of a DML type transaction may be: begin, insert, delete, update. For example, the first target transaction may be a DML-type transaction, and a specific embodiment of the synchronization flow of the first target transaction may be described with reference to fig. 6. For example, the second target transaction may be a routing transaction of a DDL type transaction, which may also be regarded as a special DML type transaction, and reference may be made to fig. 8 for a specific embodiment of the synchronization flow of the DDL type transaction (i.e., the third target transaction) corresponding to the second target transaction.

In step S306, it is determined that the identifier of the currently circulated database does not include the identifier of the first database, and the target transaction is executed in the first database.

In some embodiments, for example, if the target transaction is a DML-type transaction, the target transaction is parsed to obtain an identifier of the currently circulated database, and it is determined whether the identifier of the currently circulated database includes an identifier of the first database, and when the identifier of the first database is not included, the target transaction including a DML operation may be executed in the first database, for example, a specific implementation may refer to fig. 6.

In other embodiments, for example, if the target transaction is a routing transaction of a DDL-type transaction, the target transaction is analyzed to obtain an identifier of a currently circulated database, the identifier is correspondingly recorded in a routing table, then the corresponding DDL-type transaction is waited, and whether a corresponding DDL operation should be executed is determined according to the identifier of the currently circulated database, and a specific implementation manner may refer to fig. 7.

In other embodiments, for example, where it is determined that the currently circulated database identification includes an identification of the first database, the target transaction is not executed in the first database.

In step S308, a log of the first database is generated, where the log of the first database includes the target transaction number and an identifier of the updated circulated database of the executed target transaction, and the identifier of the updated circulated database includes an identifier of the second database and an identifier of the first database.

In some embodiments, for example, if the target transaction is a DML type transaction, the identifier of the circulated database is updated and written into the log of the first database after the corresponding DML operation is performed, and the specific implementation manner may refer to fig. 6.

In other embodiments, for example, after performing the DDL operation, the identifier of the streamed database may also be updated and written to the log of the first database, and the detailed description may refer to fig. 7.

In some embodiments, for example, the first database transmits the log of the first database to the second database, so that the second database parses the log of the first database, obtains the target transaction number and the updated circulated database identification of the executed target transaction, and in the case that it is determined that the updated circulated database identification includes the identification of the second database, does not execute the target transaction in the second database. That is, when performing bidirectional synchronization between the first database and the second database, the above method may be used to obtain routing information on the synchronization link and perform determination before data synchronization, and reference may be made to fig. 7 for a specific embodiment.

According to the data synchronization method between databases provided by the embodiment of the disclosure, a binary log replication process is modified, the identifier of a circulated database with an executed target transaction and the change of the target transaction are correspondingly recorded in a database log, so that each replicated transaction records the identifier of the database with which the replicated transaction flows, and whether the transaction is executed is judged after a source database log is analyzed when the target transaction is executed in the data synchronization process of the target database.

Fig. 4 is a schematic diagram illustrating a processing procedure of step S302 shown in fig. 3 in an embodiment. As shown in fig. 4, in the embodiment of the present disclosure, the step S302 may further include the following steps S402 to S408.

Step S402, a link from the second database to the first database is established.

Step S404, if the identifier of the first database does not exist, generating an identifier of the first database.

In some embodiments, it may be determined whether the first database and the second database have unique identifiers, and if not, the identifier of the first database and the identifier of the second database may be generated correspondingly.

In other embodiments, the second database already obtains the unique database identifier at the time of log generation, so it is also possible to determine only whether the first database has the unique identifier, and if not, generate the identifier of the first database.

Step S406, a routing table is established in the first database. The routing table is a form of database that records the passage of transactions.

In some embodiments, the routing information entry in the routing table may include a transaction type, a circulated database identifier, and the like, and the routing information entry for different transaction types may be different, and the detailed description may refer to fig. 5.

Step S408, the first database starts a copy component, and takes over the log of the second database.

According to the method for obtaining the source database log provided by the embodiment of the disclosure, after the identifiers of the source database and the target database are obtained, the database through which the transaction in the log passes can be recorded after the log is analyzed by establishing the routing table with a certain format.

Fig. 5 is a schematic diagram illustrating a routing table in accordance with an exemplary embodiment. As shown in fig. 5, the entry of the routing table includes an operation type, a routing information content (i.e., a circulated database identifier), and additional information, for a DML type transaction, the circulated database identifier includes a recorded database ID sequence that passes through from the beginning of generation, and a DML (A1: B1: C1) indicates that the current DML statement has been written into three databases a, B, and C in sequence, where A1, B1, and C1 represent UUIDs of databases a, B, and C, respectively, and can be uniformly and randomly generated during task establishment without duplication. For DDL, the content of the DDL statement itself is additionally recorded in a column of the additional information in the routing table, and a special DML transaction is used to record the routing information of the DDL statement, which is executed before the DDL statement in the synchronization process, and the specific embodiment may refer to fig. 8.

Fig. 6 is a schematic diagram illustrating a processing procedure of step S304 to step S308 shown in fig. 3 in an embodiment. In fig. 6, the target transaction to be synchronized is the first target transaction of DML type. As shown in fig. 6, in the embodiment of the present disclosure, the above steps may further include the following steps S602 to S614.

Step S602, the first database parses the log of the second database to obtain the first target transaction number.

Step S604, if the type of the first target transaction corresponding to the first target transaction number is the data operation language type, analyzing the first target transaction to obtain a first event sequence, where the first event sequence includes a first start event, a first currently circulated database identifier, a first operation statement for the first data, and a first end event.

Step S606, the first currently circulated database identifier and the data operation language type are recorded in the routing table correspondingly.

Specifically, the unique ID of the database, for example, the UUID of the first currently circulated database may be used as the identifier of the first currently circulated database, and the unique ID may be recorded in the routing table corresponding to the data operation language type.

Step S608, obtaining the identifier of the first currently circulated database from the routing table, and determining whether the identifier of the first currently circulated database includes the identifier of the first database.

Step S609, if the identifier of the first currently circulated database includes the identifier of the first database, the first target transaction is not executed in the first database.

Step S610, if the identifier of the first currently circulated database does not include the identifier of the first database, executing the first target transaction in the first database.

Step S612, rewriting the first currently circulated database identifier in the routing table into the first updated circulated database identifier.

Step S614, writing the first updated circulated database identifier and the first target transaction number into the log of the first database correspondingly.

Fig. 7 is an interaction flow diagram according to the bidirectional synchronization shown in fig. 6. As shown in fig. 7, the data synchronization between database a and database B is two-node bidirectional synchronization, first, database a executes DML type transaction 1, inserts (insert) a piece of data XXX into database a, then this piece of data is written into database a, and records binary log Binlog (1, a) representing the Binlog of currently executing transaction 1, and the data is generated by database a. Namely, part of the contents of Binlog (1, A) is:

Begin；

Insert XXX；

Commit；

binlog (1, a) is then ready for replay at database B, along with a copy of the binary log. <xnotran> Binlog (1,A) , 1 A _ * * * db _ (route) : </xnotran>

Insert into_***db_.route values

(“uuid of A”)

After judging that the data contained in Binlog (1, a) is the information generated in the database a and is currently to be written to the database B, it is judged that the data can be written to the database B. When data is written into database B, binlog (1, a:

Begin；

Insert into_***db_.route values

(“uuid of A”；“uuid of B”)

Insert XXX；

Commit；

then, binlog (1, a.

In fig. 7, the flow of database B performing DML type transaction 2 for inserting a piece of data YYY in database B and synchronizing to database a is similar to the flow of database a performing DML type transaction 1 for inserting data XXX in database a and synchronizing to database B.

Fig. 8 is a schematic diagram illustrating a processing procedure of step S304 to step S308 shown in fig. 3 in another embodiment. In fig. 8, the target transaction to be synchronized is a second target transaction of DDL routing type, and the corresponding DDL transaction is synchronized. As shown in fig. 8, in the embodiment of the present disclosure, the above steps may further include the following steps S802 to S822.

Step S802, the first database analyzes the log of the second database to obtain a second target transaction number.

Step S804, if the type of the second target transaction corresponding to the second target transaction number is the data definition language routing type, analyzing the second target transaction to obtain a second event sequence, where the second event sequence includes a second start event, a second currently-circulated database identifier, a first data definition language statement, and a second end event.

Step S806, correspondingly recording the second currently circulated database identifier, the first data definition language statement, and the data definition language type in the routing table.

Step S808, the first database analyzes the log of the second database to obtain a third target transaction number, where the second target transaction is a routing transaction of the third target transaction corresponding to the third target transaction number.

Step S810, analyzing the third target transaction under the condition that the type of the third target transaction is determined to be the data definition language type, and obtaining the first data definition language statement.

Step S812, obtaining the identifier of the second currently circulated database from the routing table according to the statement of the first data definition language.

Step S814, obtaining the identifier of the second currently circulated database from the routing table, and determining whether the identifier of the second currently circulated database includes the identifier of the first database.

In step S816, if the identifier of the second circulated database includes the identifier of the first database, the second target transaction and the third target transaction are not executed in the first database.

In step S818, if the identifier of the second circulated database does not include the identifier of the first database, the second target transaction and the third target transaction are executed in the first database.

Step S820, the second currently circulated database identifier in the routing table is rewritten into the second updated circulated database identifier.

Step S822, writing the second updated circulated database identifier and the second target transaction number into the log of the first database correspondingly.

Fig. 9 is a flow chart of a data synchronization method according to fig. 6 and 8, fig. 10 is an interactive flow chart of a circular synchronization according to fig. 9, and the method of fig. 9 can be applied to a synchronization link 1004 from a database B to a database C in fig. 10, for example. Referring to fig. 9 and 10, the ring synchronization method may include the following steps S902 to S916.

Step S902, establishing a synchronization link 1004 from the database B to the database C, determining whether the database B and the database C have the unique ID of the database, if not, one is generated (for convenience of description, B and C are used to refer to the two databases directly below), and a route table is built in a _ db _ library in the target database C.

Step S904, the Replicator replication component is started, takes over the binary log of the database B,

step S906, for the current transaction 1, if it is a transaction of general DML type, execute step S908; if the transaction is a special routing transaction (which can be judged by the format in the Route table corresponding to the transaction, see fig. 5) with the event sequence being Begin, route, and Commit, such as a routing transaction of a DDL type transaction, then step S912 is skipped.

Step S908, parsing Binlog (1, a.

In step S910, it is determined whether transaction 1 should be written to the target database of the link, here database C. As known by Route (A: B), if transaction 1 has not passed through database C before, then this data can be written to database C, thus rewriting Route as Route (A: B: C) to be written to C with the transaction.

If for synchronization link 1006, i.e., database C to database A, route (A: B: C) indicates that the transaction previously flowed through A, then the transaction may be discarded; after the processing, the process goes to step S906 to continue processing the next transaction.

Step S912, analyzing the affair 1, if the affair is a special routing affair of the DDL type affair, recording the routing information affair in a route table in a memory, jumping to the step S906 to continue processing the next affair, and waiting for a subsequent corresponding DDL affair; if it is the DDL transaction itself, the previously obtained routing information of the DDL transaction is obtained, and the process proceeds to step S914.

Step S914, similar to DML, judging whether the DDL statement should be written into the target library according to Route (), if not, discarding; if it should be written, route () is rewritten and the DDL routing transaction is executed together with the DDL transaction itself.

Step S916, repeatedly executing step S906 to step S914 until all the target transactions are synchronized, and the data synchronization task is finished.

As shown in fig. 10, the data synchronization between database a, database B, and database C is two-node bidirectional synchronization, and the data synchronization on synchronization link 1002 and synchronization link 1006 can be processed by a flow similar to that of fig. 9. While fig. 10 depicts the general scenario of ring synchronization in terms of three nodes, it is contemplated that the method may be extended to any finite node ring synchronization scenario, provided that similar step operations are performed for each link.

With the change of the database version, the GTID is the standard configuration of the high-version database, so the scheme based on the GTID is a standard scheme for solving similar problems, but for the period when the current new and old versions exist at the same time, especially for the subsequent long-term existing scene where the GTID cannot be used (especially the problem of Super authority will exist all the time), the Data processing method provided by the embodiment of the disclosure does not depend on the GTID, and based on the routing tracking of things, the fundamental problem of Data ring synchronization is solved, and the method is more general in the actual application scene, is an important basis of Data synchronization in the DTS (Data Transmission Service), and can continue to play a role for a long time.

According to the data processing method provided by the embodiment of the disclosure, in a more general scene, namely under the condition of no GTID support, the ring synchronization that the replication among the databases conforms to the logic is possible. The embodiment of the disclosure provides a method for ring data synchronization between databases, which can avoid the problem of unexpected data repeated writing, avoid repeated execution of data change DML type transactions, avoid repeated execution of structure change DDL type transactions, and is applicable to general scenarios of data synchronization between databases.

The problem of annular synchronization is solved at a synchronous link layer, so that the construction of the synchronous link between databases is more convenient, data confusion is not needed to be worried about, and the upper-layer service logic based on the synchronous link is simpler, for example, in multipoint annular synchronization, each point only needs to be worried about the part of the point; in addition, the multi-point annular synchronization can enable the robustness of the system to be stronger, and the fault of one point does not affect the normal operation of other points.

Fig. 11 is a block diagram illustrating an apparatus for synchronizing data between databases according to an example embodiment. The apparatus shown in fig. 11 can be applied to, for example, a server side of the system described above, and can also be applied to a terminal device of the system described above.

Referring to fig. 11, the apparatus 110 provided by the embodiment of the present disclosure may include a second database log obtaining module 1102, a second database log parsing module 1104, a target transaction determination executing module 1106, and a first database log generating module 1108.

The second database log obtaining module 1102 may be used for the first database to obtain a log of the second database.

The second database log analyzing module 1104 may be configured to analyze the log of the second database by the first database, and obtain the target transaction number and an identifier of a currently circulated database of the target transaction corresponding to the executed target transaction number, where the identifier of the currently circulated database includes the identifier of the second database.

The target transaction determination execution module 1106 may be configured to determine that the identity of the currently circulated database does not include the identity of the first database, and execute the target transaction in the first database.

The first database log generation module 1108 may be configured to generate a log of the first database, the log of the first database including the target transaction number and an identification of an updated circulated database of executed target transactions, the identification of the updated circulated database including an identification of the second database and an identification of the first database.

Fig. 12 is a block diagram illustrating an apparatus for synchronizing data between databases according to an example embodiment. The apparatus shown in fig. 12 may be applied to, for example, a server side of the system, and may also be applied to a terminal device of the system.

Referring to fig. 12, the apparatus 120 provided in this disclosure may include a second database log obtaining module 1202, a second database log parsing module 1204, a target transaction determining non-executing module 1205, a target transaction determining executing module 1206, a first database log generating module 1208, a third target transaction number obtaining module 1210, a first data definition language statement obtaining module 1212, a second currently circulated database identification obtaining module 1214, a second routing determining module 1216, a second target transaction executing module 1218, a second circulated database identification updating module 1220, a second transaction routing writing module 1222, and a log transmitting module 1224 of the first database, where the second database log obtaining module 1202 may include a link establishing module 12022, a database identification generating module 12024, a routing table establishing module 12026, and a second database log module 12028, the second database log generating module 1204 may include a first target transaction number obtaining module 12042, a first transaction sequence obtaining module 12044, a first routing information record 12046, a second target transaction log taking over module 12048, a target transaction number obtaining module 12064, and a target transaction number obtaining module 1224 of the first database may include a first transaction number obtaining module 12064, and a target transaction log determining module 12082 may include a target transaction number obtaining module 12064.

The second database log acquisition module 1202 may be configured to acquire a log of a second database from a first database.

Link establishment module 12022 may be used to establish a link from the second database to the first database.

Database identification generation module 12024 may be used to generate an identification of the first database if the identification of the first database does not exist.

The routing table setup module 12026 may be used to setup a routing table in the first database.

The second database log takeover module 12028 may be used for the first database to initiate a replication component to take over the log of the second database.

The second database log parsing module 1204 may be configured to parse, by the first database, the log of the second database, and obtain the target transaction number and an identifier of a currently circulated database of the target transaction corresponding to the executed target transaction number, where the identifier of the currently circulated database includes the identifier of the second database. The target transaction number comprises a first target transaction number and a second target transaction number, and the identifier of the currently circulated database comprises a first currently circulated database identifier and a second currently circulated database identifier.

The first target transaction number obtaining module 12042 may be configured to the first database parsing the log of the second database to obtain the first target transaction number.

The first event sequence obtaining module 12044 may be configured to, if the type of the first target transaction corresponding to the first target transaction number is a data operation language type, parse the first target transaction to obtain a first event sequence, where the first event sequence includes a first start event, a first currently circulated database identifier, a first operation statement for the first data, and a first end event.

The first routing information recording module 12046 may be configured to record the first currently circulated database identifier and the data operation language type in a routing table.

The second target transaction number obtaining module 12048 may be configured to parse, by the first database, the log of the second database to obtain the first target transaction number.

The second event sequence obtaining module 120410 may be configured to, if the type of the second target transaction corresponding to the second target transaction number is the data definition language routing type, parse the second target transaction to obtain a second event sequence, where the second event sequence includes a second start event, a second currently-flowed database identifier, a first data definition language statement, and a second end event.

The second routing information recording module 120412 may be configured to record the second currently circulated database identifier and the first data definition language statement in the routing table corresponding to the data definition language type.

The target transaction do not execute module 1205 is operable to not execute the target transaction in the first database if it is determined that the currently circulated database identification comprises an identification of the first database.

The target transaction determination execution module 1206 may be operable to determine that the identity of the currently circulated database does not include the identity of the first database in which to execute the target transaction.

The first routing determining module 12062 may be configured to obtain the first currently-circulated database identifier from the routing table, and determine whether the first currently-circulated database identifier includes an identifier of the first database.

The first target transaction execution module 12064 may be configured to execute the first target transaction in the first database if the first currently streamed database identification does not include the identification of the first database.

The first database log generation module 1208 may be configured to generate a log of the first database, where the log of the first database includes the target transaction number and an identifier of an updated circulated database of the executed target transaction, and the identifier of the updated circulated database includes an identifier of the second database and an identifier of the first database. The identification of the updated circulated database includes a first updated circulated database identification.

The first migrated database id update module 12082 may be configured to rewrite the first currently migrated database id in the routing table to the first updated migrated database id.

The first transaction route writing module 12084 may be configured to write the first updated streamed database identifier to the log of the first database corresponding to the first target transaction number.

The third target transaction number obtaining module 1210 may be configured to analyze, by the first database, the log of the second database, and obtain a third target transaction number, where the second target transaction is a routing transaction of a third target transaction corresponding to the third target transaction number.

The first data definition language statement obtaining module 1212 may be configured to parse the third target transaction to obtain the first data definition language statement when the type of the third target transaction is determined to be the data definition language type.

The second currently circulated database identification obtaining module 1214 is operable to obtain a second currently circulated database identification from the routing table according to the first data definition language statement.

The second route determining module 1216 may be configured to obtain the second currently-circulated database identifier from the routing table, and determine whether the second currently-circulated database identifier includes the identifier of the first database.

The second target transaction execution module 1218 may be configured to execute the second target transaction and the third target transaction in the first database if the current second circulated database identifier does not include the identifier of the first database.

The second circulated database identification updating module 1220 may be configured to rewrite the second currently circulated database identification in the routing table to a second updated circulated database identification.

The second transaction routing write module 1222 may be configured to write a second updated circulated database identification to the log of the first database corresponding to the second target transaction number.

The log transmission module 1224 of the first database may be configured to transmit, by the first database, the log of the first database to the second database, so that the second database parses the log of the first database, obtains the target transaction number and the updated circulated database identifier of the executed target transaction, and if it is determined that the updated circulated database identifier includes the identifier of the second database, the target transaction is not executed in the second database.

The specific implementation of each module in the apparatus provided in the embodiment of the present disclosure may refer to the content in the foregoing method, and is not described herein again.

Fig. 13 shows a schematic structural diagram of an electronic device in an embodiment of the present disclosure. It should be noted that the apparatus shown in fig. 13 is only an example of a computer system, and should not bring any limitation to the function and the scope of the application of the embodiments of the present disclosure.

As shown in fig. 13, the apparatus 1300 includes a Central Processing Unit (CPU) 1301 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1302 or a program loaded from a storage section 1308 into a Random Access Memory (RAM) 1303. In the RAM 1303, various programs and data necessary for the operation of the device 1300 are also stored. The CPU1301, the ROM 1302, and the RAM 1303 are connected to each other via a bus 1304. An input/output (I/O) interface 1305 is also connected to bus 1304.

The following components are connected to the I/O interface 1305: an input portion 1306 including a keyboard, a mouse, and the like; an output section 1307 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 1308 including a hard disk and the like; and a communication section 1309 including a network interface card such as a LAN card, a modem, or the like. The communication section 1309 performs communication processing via a network such as the internet. A drive 1310 is also connected to the I/O interface 1305 as needed. A removable medium 1311 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1310 as necessary, so that a computer program read out therefrom is mounted into the storage portion 1308 as necessary.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such embodiments, the computer program may be downloaded and installed from a network through communications component 1309 and/or installed from removable media 1311. The above-described functions defined in the system of the present disclosure are executed when the computer program is executed by a Central Processing Unit (CPU) 1301.

It should be noted that the computer readable medium shown in the present disclosure may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer-readable signal medium may include a propagated data signal with computer-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present disclosure may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor comprises a second database log obtaining module, a second database log analyzing module, a target transaction determining and executing module and a first database log generating module. Where the names of these modules do not in some cases constitute a limitation on the module itself, for example, the second database log retrieval module may also be described as "the module for which the first database retrieves logs from the second database".

The embodiments of the present disclosure also provide a computer-readable medium, which may be contained in the device described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

the first database acquires a log of the second database; the first database analyzes the log of the second database to obtain a target transaction number and an identifier of a currently circulated database of a target transaction corresponding to the executed target transaction number, wherein the identifier of the currently circulated database comprises the identifier of the second database; determining that the identifier of the currently circulated database does not comprise the identifier of the first database, and executing a target transaction in the first database; and generating a log of the first database, wherein the log of the first database comprises the target transaction number and the identification of the updated circulated database of the executed target transaction, and the identification of the updated circulated database comprises the identification of the second database and the identification of the first database.

Embodiments of the present disclosure provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in the above-mentioned various alternative implementation modes.

Exemplary embodiments of the present disclosure are specifically illustrated and described above. It is to be understood that the present disclosure is not limited to the precise arrangements, instrumentalities, or instrumentalities described herein; on the contrary, the disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (12)

1. A method for synchronizing data between databases, comprising:

the first database acquires a log of the second database;

the first database analyzes the log of the second database to obtain a target transaction number and an identifier of a currently circulated database of a target transaction corresponding to the executed target transaction number, wherein the identifier of the currently circulated database comprises the identifier of the second database;

determining that the identifier of the currently circulated database does not include the identifier of the first database, and executing the target transaction in the first database;

generating a log of the first database, wherein the log of the first database comprises the target transaction number and an identification of an updated circulated database in which the target transaction is executed, and the identification of the updated circulated database comprises an identification of the second database and an identification of the first database.

2. The method of claim 1, wherein the first database obtaining a log of a second database comprises:

establishing a link from the second database to the first database;

if the identifier of the first database does not exist, generating the identifier of the first database;

establishing a routing table in the first database;

and the first database starts a copy component to take over the log of the second database.

3. The method of claim 2, wherein the target transaction number comprises a first target transaction number, and wherein the identification of the currently circulated database comprises a first currently circulated database identification;

the analyzing, by the first database, the log of the second database to obtain a target transaction number and an identifier of a currently circulated database in which a target transaction corresponding to the target transaction number has been executed includes:

the first database analyzes the log of the second database to obtain the first target transaction number;

if the type of the first target transaction corresponding to the first target transaction number is a data operation language type, analyzing the first target transaction to obtain a first event sequence, wherein the first event sequence comprises a first start event, the first currently circulated database identifier, a first operation statement aiming at first data and a first end event;

and recording the first currently circulated database identification and the data operation language type in the routing table correspondingly.

4. The method of claim 3, wherein the identification of the updated circulated database comprises a first updated circulated database identification;

wherein said determining that the identity of the currently circulated database does not include the identity of the first database, executing the target transaction in the first database comprises:

obtaining the first current circulated database identifier from the routing table, and judging whether the first current circulated database identifier comprises the identifier of the first database;

if the first currently circulated database identifier does not comprise the identifier of the first database, executing the first target transaction in the first database;

wherein the generating the log of the first database comprises:

rewriting the first currently circulated database identifier in the routing table to the first updated circulated database identifier;

and correspondingly writing the first updated circulated database identifier and the first target transaction number into a log of the first database.

5. The method of claim 2, wherein the target transaction number comprises a second target transaction number, and wherein the identification of the currently circulated database comprises a second currently circulated database identification;

the analyzing, by the first database, the log of the second database to obtain a target transaction number and an identifier of a currently circulated database in which a target transaction corresponding to the target transaction number has been executed includes:

the first database analyzes the log of the second database to obtain the second target transaction number;

if the type of the second target transaction corresponding to the second target transaction number is a data definition language routing type, analyzing the second target transaction to obtain a second event sequence, wherein the second event sequence comprises a second start event, a second currently circulated database identifier, a first data definition language statement and a second end event;

and correspondingly recording the second currently circulated database identification, the first data definition language statement and the data definition language type in the routing table.

6. The method of claim 5, further comprising:

the first database analyzes the log of the second database to obtain a third target transaction number, wherein the second target transaction is a routing transaction of the third target transaction corresponding to the third target transaction number;

analyzing the third target transaction under the condition that the type of the third target transaction is judged to be the data definition language type, and obtaining the first data definition language statement;

and obtaining the second currently circulated database identification from the routing table according to the first data definition language statement.

7. The method of claim 6, further comprising:

obtaining the second currently circulated database identifier from the routing table, and judging whether the second currently circulated database identifier includes the identifier of the first database;

if the current second circulated database identifier does not comprise the identifier of the first database, executing the second target transaction and the third target transaction in the first database;

rewriting the second current circulated database identifier in the routing table to the second updated circulated database identifier;

and correspondingly writing the second updated circulated database identifier and the second target transaction number into the log of the first database.

8. The method of claim 1, further comprising:

in the event that it is determined that the currently circulated database identification includes an identification of the first database, the target transaction is not executed in the first database.

9. The method of claim 1, further comprising:

the first database transmits the log of the first database to the second database so that the second database can analyze the log of the first database, obtain the target transaction number and the updated circulated database identifier of the executed target transaction, and under the condition that the updated circulated database identifier comprises the identifier of the second database, the target transaction is not executed in the second database.

10. An apparatus for synchronizing data between databases, comprising:

the second database log acquisition module is used for acquiring the log of the second database by the first database;

a second database log analysis module, configured to analyze, by the first database, a log of the second database, to obtain a target transaction number and an identifier of a currently circulated database that has executed a target transaction corresponding to the target transaction number, where the identifier of the currently circulated database includes an identifier of the second database;

the target transaction determination execution module is used for determining that the identifier of the currently circulated database does not comprise the identifier of the first database, and executing the target transaction in the first database;

a first database log generating module, configured to generate a log of the first database, where the log of the first database includes the target transaction number and an identifier of an updated circulated database in which the target transaction has been executed, and the identifier of the updated circulated database includes an identifier of the second database and an identifier of the first database.

11. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 9.

12. An electronic device, comprising: at least one processor; a storage device configured to store at least one program that, when executed by the at least one processor, causes the at least one processor to implement the method of any one of claims 1 to 9.

Images