Metadata synchronization method, device, electronic device and storage medium

Abstract

An embodiment of the present invention discloses a metadata synchronization method, device, electronic device and storage medium, wherein the method includes: when executing a target DDL command, determining whether all existing DDL commands in a DDL operation log have been executed based on a metadata table of a computing node; if not, waiting for a DDL replay process to execute the latest DDL command and updating the metadata table accordingly, and then locking the DDL operation log; appending information of the target DDL command to the DDL operation log and executing the target DDL command, thereby realizing distributed database metadata synchronization based on a global operation log, ensuring that each computing node in a cluster executes exactly the same DDL operation sequence, thereby generating exactly the same metadata in each computing node.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed database management systems, and in particular to a metadata synchronization method, device, electronic device and storage medium. Background Art

[0002] A distributed database management system (DDBMS) typically consists of three components: compute nodes, storage nodes, and metadata nodes. Metadata nodes are responsible for storing cluster metadata, including the cluster topology and metadata about user data managed by the cluster, such as user table definition statements. Compute nodes are primarily responsible for the following tasks: accepting client connection requests, verifying requests, and establishing connection status; processing query requests sent by client connections and returning results to the client; interacting with storage nodes to complete data reading and writing; and implementing the Distributed Transaction Coordinator (DTC) to ensure the reliable submission of distributed transactions.

[0003] Each compute node of the DDBMS can execute DDL and DML statements. Therefore, it is necessary to ensure that each compute node in the cluster executes exactly the same sequence of DDL operations, thereby generating exactly the same metadata in each compute node. Summary of the Invention

[0004] The main purpose of the present invention is to provide a metadata synchronization method, device, electronic device and storage medium, which can solve the problem of metadata synchronization of computing nodes in a distributed database.

[0005] To achieve the above objectives, the present application provides a metadata synchronization method in a first aspect, the method comprising:

[0006] When executing the target DDL command, determine whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node;

[0007] If not, wait for the DDL replay process to execute the latest DDL command and update the metadata table accordingly, then lock the DDL operation log;

[0008] Append the target DDL command information to the DDL operation log, and execute the target DDL command.

[0009] Optionally, determining whether all existing DDL commands in the DDL operation log have been executed based on the metadata table includes:

[0010] Comparing the replication identifier in the metadata table with the maximum identifier of the DDL operation log, the replication identifier being used to mark the replication position of the computing node in the DDL operation log;

[0011] If the copy identifier is the same as the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have been executed;

[0012] If the copy identifier is different from the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have not been executed.

[0013] Optionally, the DDL replay process includes:

[0014] Pull out from the DDL operation log all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table;

[0015] Execute the DDL command that has not been executed;

[0016] The updating of the metadata table includes: updating the replication identifier in the metadata table according to the executed DDL command.

[0017] Optionally, the DDL command recorded in the DDL operation log includes an identifier of a computing node that initiates execution of the DDL command;

[0018] The step of pulling from the DDL operation log all DDL commands that have not been executed by the computing node and that start from the replication identifier in the metadata table includes:

[0019] According to the computing node identifier, all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table are pulled from the DDL operation log.

[0020] Optionally, the method further includes:

[0021] The DDL transaction of the target DDL command is committed.

[0022] Optionally, the DDL transaction for submitting the target DDL command includes:

[0023] Commit the transaction branches of the storage node and metadata node;

[0024] The execution identifier in the metadata table of the computing node is updated to the identifier of the target DDL command, and the transaction branch of the computing node is submitted. The execution identifier is used to mark the latest DDL command executed by the computing node.

[0025] Optionally, locking the DDL operation log includes:

[0026] Block other DDL commands until the target DDL command's task is completed and then continue to execute.

[0027] To achieve the above-mentioned purpose, the second aspect of the present application provides a metadata synchronization device, comprising:

[0028] a determination module, configured to determine, when executing a target DDL command, based on a metadata table of a computing node, whether all existing DDL commands in a DDL operation log have been executed;

[0029] A locking module, configured to lock the DDL operation log after waiting for the DDL replay process to execute the latest DDL command and update the metadata table accordingly if all existing DDL commands in the DDL operation log have not been executed;

[0030] An execution module is used to append information of the target DDL command to the DDL operation log and execute the target DDL command.

[0031] Optionally, the determining module is specifically configured to:

[0032] Comparing the replication identifier in the metadata table with the maximum identifier of the DDL operation log, the replication identifier being used to mark the replication position of the computing node in the DDL operation log;

[0033] If the copy identifier is the same as the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have been executed;

[0034] If the copy identifier is different from the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have not been executed.

[0035] Optionally, the metadata synchronization device further includes a replay module, configured to:

[0036] Pull out from the DDL operation log all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table;

[0037] Execute the DDL command that has not been executed;

[0038] The replication identifier in the metadata table is updated according to the executed DDL command.

[0039] Optionally, the DDL command recorded in the DDL operation log includes an identifier of a computing node that initiates execution of the DDL command;

[0040] The replay module is specifically used for:

[0041] According to the computing node identifier, all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table are pulled from the DDL operation log.

[0042] Optionally, the execution module is further configured to:

[0043] The DDL transaction of the target DDL command is committed.

[0044] Optionally, the execution module is specifically configured to:

[0045] Commit the transaction branches of the storage node and metadata node;

[0046] The execution identifier in the metadata table of the computing node is updated to the identifier of the target DDL command, and the transaction branch of the computing node is submitted. The execution identifier is used to mark the latest DDL command executed by the computing node.

[0047] Optionally, the locking module is specifically used to:

[0048] Block other DDL commands until the target DDL command's task is completed and then continue to execute.

[0049] A third aspect of the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the first aspect and any possible implementation thereof.

[0050] To achieve the above-mentioned objectives, the fourth aspect of the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor executes the various steps in the method described in the first aspect.

[0051] The present application provides a metadata synchronization method. When executing a target DDL command, the method determines whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node; if not, the method waits for the DDL replay process to execute the latest DDL command and updates the metadata table accordingly, and then locks the DDL operation log; appends the information of the target DDL command to the DDL operation log, and executes the target DDL command. This method can achieve distributed database metadata synchronization based on the global operation log, ensuring that each computing node in the cluster executes exactly the same DDL operation sequence, thereby generating exactly the same metadata in each computing node. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0053] in:

[0054] Figure 1 A flowchart of a metadata synchronization method provided in an embodiment of the present application;

[0055] Figure 2 A flowchart of a DDL replay process provided in an embodiment of the present application;

[0056] Figure 3 A schematic diagram of metadata synchronization between computing nodes using DDL operation logs provided in an embodiment of the present application;

[0057] Figure 4 A schematic diagram of the structure of a metadata synchronization device provided in an embodiment of the present application;

[0058] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0060] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0061] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0062] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application.

[0063] See also Figure 1 , is a flow chart of a metadata synchronization method in an embodiment of the present application, which can be applied to computing nodes in a distributed database management system. Figure 1 As shown, the method includes:

[0064] 101. When executing a target DDL command, determine whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node.

[0065] The execution subject in the embodiment of the present application may be a metadata synchronization device, or may be an electronic device. In a specific implementation, the electronic device may be a computing node terminal.

[0066] First, let's briefly introduce DDBMS. DDBMS usually consists of compute nodes, storage nodes, and metadata nodes. As mentioned in the background, compute nodes are mainly responsible for the following tasks:

[0067] Accept client connection request, verify request, and establish connection status;

[0068] Process the query request sent by the client connection and return the result to the client;

[0069] Interact with storage nodes to complete data reading and writing;

[0070] Implement the Distributed Transaction Coordinator (DTC) to complete the reliable submission of distributed transactions.

[0071] The metadata node is responsible for storing cluster metadata, including the cluster topology and metadata of user data managed by the cluster, such as user table definition statements.

[0072] Storage nodes are responsible for storing data and, under the coordination of the compute node DTC, executing and submitting distributed transaction branches. They form a cluster based on a data change replication mechanism to achieve high availability.

[0073] User requests executed by a DDBMS are mainly divided into two categories: one is called DDL, which is the statement in which the user defines the storage method of data (such as tables, containers, etc.); the other is called DML, which is the statement for reading and writing data in established storage units (such as tables, containers, etc.).

[0074] Every compute node in a DDBMS can execute DDL and DML statements. Therefore, it is necessary to ensure that every compute node in the cluster executes the exact same sequence of DDL operations, thereby generating the exact same metadata in each compute node. To achieve this goal, the embodiments of this application include the following key points and are divided into two main parts: a DDL sequence execution mechanism and a DDL replay mechanism.

[0075] Figure 1 The steps of the illustrated embodiment are mainly a DDL sequence execution mechanism.

[0076] Specifically, in the embodiment of the present application, the metadata table ddl_coord is used in the computing node to record the DDL command processing status of the computing node, mainly including two aspects: replication and execution.

[0077] The target DDL command can be any DDL command to be executed by the compute node. When executing the DDL command, the compute node can first determine, based on the metadata table, whether all existing DDL commands in the DDL operation log have been executed. If it is determined that the compute node has executed all existing DDL commands in the DDL operation log, the target DDL command can be directly executed; if not, step 102 can be executed.

[0078] In an optional implementation, the above step 101 includes:

[0079] 11. Compare the replication identifier in the metadata table with the maximum identifier in the DDL operation log. The replication identifier is used to mark the replication position of the compute node in the DDL operation log.

[0080] 12. If the replication identifier is the same as the maximum identifier in the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have been executed;

[0081] 13. If the copy identifier is different from the maximum identifier in the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have not been executed.

[0082] In the embodiment of the present application, a global DDL operation log is used to store DDL commands and related information. Each DDL command is identified by a monotonically increasing unique ID. This DDL operation log is stored in the metadata node.

[0083] Specifically, when a compute node executes any DDL statement, it must ensure that it has executed all existing DDL commands in the DDL operation log. The replication identifier in the metadata table records which DDL command the compute node has replicated to (the ddl_coord.repl_max tag is used in the embodiment of this application). Therefore, by comparing its ddl_coord.repl_max with the maximum identifier (maximum ID) in the DDL log, the DDL statement can be executed only if the two are the same; if they are not the same, step 103 can be executed.

[0084] 102. After the DDL replay process executes the latest DDL command and updates the metadata table accordingly, the DDL operation log is locked.

[0085] Specifically, if ddl_coord.repl_max is different from the maximum ID in the DDL log, wait until the DDL replay process executes the latest DDL command and updates the metadata table accordingly (updates ddl_coord.repl_max), then lock the DDL operation log before executing the target DDL command.

[0086] The DDL replay process will be described later. The DDL replay mechanism retrieves DDL commands that have not yet been executed by the compute node from the metadata cluster's DDL operation log. This allows the target DDL command to be executed after all existing DDL commands in the DDL operation log have been executed.

[0087] In an optional implementation, locking the DDL operation log includes:

[0088] Block other DDL commands until the target DDL command is completed.

[0089] In this embodiment of the present application, when multiple concurrent DDLs are being executed, the locking operation on the DDL operation log causes other DDL commands to block and wait for the DDL to complete before continuing to execute the DDL transaction. This achieves global ordered execution of concurrent DDLs (they are written to the DDL log serially, and therefore globally ordered).

[0090] 103. Append the target DDL command information to the DDL operation log, and execute the target DDL command.

[0091] Specifically, after locking the DDL operation log, the computing node executes the key part of the DDL—writing the DDL operation log, and can also send appropriate DDL commands to the target storage node if necessary.

[0092] In an optional embodiment, after step 103, the method further includes:

[0093] Submit the DDL transaction for the target DDL command above.

[0094] After appending the target DDL command information to the DDL operation log, you can enter the DDL transaction commit process.

[0095] In an optional implementation, the DDL transaction for submitting the target DDL command includes:

[0096] Commit the transaction branches of the storage node and metadata node;

[0097] The execution identifier in the metadata table of the computing node is updated to the identifier of the target DDL command, and the transaction branch of the computing node is submitted. The execution identifier is used to mark the latest DDL command executed by the computing node.

[0098] The execution identifier in the metadata table records the ID of the latest DDL command executed in the computing node (the ddl_coord.my_max tag is used in the embodiment of the present application).

[0099] In the metadata cluster's DDL log (a data table), there's a column containing monotonically increasing integers, such as 1, 2, 3, and so on. This column is called the logID. Each DDL log entry has a unique logID. When a compute node executes a DDL command, it appends a DDL log entry to the DDL log table (that is, writes it to the end of the DDL log). This row of data has a logID that uniquely identifies the DDL command.

[0100] Specifically, the computing node may first submit the transaction branches of the storage node and metadata node, then update the ddl_coord.my_max of the computing node to the ID of this DDL command and submit the transaction branch of the computing node.

[0101] The embodiment of the present application determines whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node when executing the target DDL command; if not, waits for the DDL replay process to execute the latest DDL command and updates the metadata table accordingly, and then locks the DDL operation log; appends the information of the target DDL command to the DDL operation log, and executes the target DDL command, so as to achieve distributed database metadata synchronization based on the global operation log, ensure that each computing node in the cluster executes exactly the same DDL operation sequence, and thus generate exactly the same metadata in each computing node.

[0102] See Figure 2, Figure 2 A flow chart of a DDL replay process provided in an embodiment of the present application. Figure 2 As shown, the method includes:

[0103] 201. Pull out from the DDL operation log all DDL commands that have not been executed on the computing node, starting from the replication identifier in the metadata table;

[0104] 202. Execute the DDL commands that have not been executed above.

[0105] 203. Update the replication flag in the metadata table according to the executed DDL command.

[0106] In an optional embodiment, the DDL command recorded in the DDL operation log includes an identifier of a computing node that initiates execution of the DDL command;

[0107] All DDL commands that have not been executed by the computing node and are pulled from the DDL operation log starting from the replication identifier in the metadata table include:

[0108] According to the computing node identifier, all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table are pulled from the DDL operation log.

[0109] Specifically, each compute node has a unique compute node identifier (compute node ID) within the cluster. Each DDL operation log entry stored by a compute node contains the ID of the compute node that initiated the DDL command. This compute node ID can be used to exclude DDL commands executed by each compute node from the DDL operation log.

[0110] In its background process, the compute node can pull all DDL commands executed by non-compute nodes starting from the compute node's ddl_coord.repl_max from the metadata cluster's DDL operation log, and then process each DDL command in ascending order of ID:

[0111] For each DDL command, you can execute it in a separate transaction running locally on the compute node, then update ddl_coord.repl_max to the identifier of the DDL command, and then commit the transaction.

[0112] As mentioned earlier, the metadata cluster's DDL log contains a column containing monotonically increasing integers, such as 1, 2, and 3. This column is called the logID, and each DDL log entry has a unique logID. When a compute node executes a DDL command, it appends a DDL log entry to the DDL log table (that is, writes it to the end of the DDL log). This row of data has a logID that uniquely identifies the DDL command.

[0113] The replication identifier stored in the compute node's ddl_coord is the logID described above. It indicates which log entry in the DDL log table the compute node replicated. When a compute node replays a DDL log, it executes a DDL log entry in each transaction and updates the replication identifier in ddl_coord with its logID to reliably record the replayed position. Each subsequent replay starts at logID+1.

[0114] By updating the replication flag in the metadata table ddl_coord, after each DDL transaction is committed, the replication flag in the metadata table ddl_coord fully corresponds to the metadata actually stored on the compute node. Therefore, if the compute node restarts for any reason, replication can resume from the last successful replication point, ensuring that the compute node correctly replicates the metadata of the DDL operation log.

[0115] Figure 3 The embodiment of the present application provides a schematic diagram of using DDL operation logs to synchronize metadata between computing nodes. Figure 3 As shown, a global DDL operation log is used to store DDL commands and related information. Each DDL command is identified by a monotonically increasing unique ID. This DDL operation log is stored in the metadata node. Compute node 1 adds the DDL to the DDL operation log based on the DDL log coordinates recorded in its metadata table. Compute node 2 replays the DDL from the DDL operation log based on the DDL log coordinates recorded in its metadata table. This process is not detailed here.

[0116] Based on the description of the above metadata synchronization method embodiment, the present application embodiment also discloses a metadata synchronization device, see Figure 4 , the metadata synchronization device 400 includes:

[0117] A determination module 410 is configured to determine, when executing a target DDL command, whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node;

[0118] A locking module 420 is configured to lock the DDL operation log after the DDL replay process executes the latest DDL command and updates the metadata table accordingly if all existing DDL commands in the DDL operation log have not been executed.

[0119] The execution module 430 is configured to append information of the target DDL command to the DDL operation log and execute the target DDL command.

[0120] In an optional implementation, the determining module 410 is specifically configured to:

[0121] Comparing the replication identifier in the metadata table with the maximum identifier of the DDL operation log, the replication identifier being used to mark the replication position of the computing node in the DDL operation log;

[0122] If the copy identifier is the same as the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have been executed;

[0123] If the copy identifier is different from the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have not been executed.

[0124] In an optional implementation, the metadata synchronization device further includes a replay module, configured to:

[0125] Pull out from the DDL operation log all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table;

[0126] Execute the DDL command that has not been executed;

[0127] The replication identifier in the metadata table is updated according to the executed DDL command.

[0128] In an optional implementation, the DDL command recorded in the DDL operation log includes an identifier of a computing node that initiates execution of the DDL command;

[0129] The replay module is specifically used for:

[0130] According to the computing node identifier, all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table are pulled from the DDL operation log.

[0131] In an optional implementation, the execution module 430 is further configured to:

[0132] The DDL transaction of the target DDL command is committed.

[0133] In an optional implementation, the execution module 430 is specifically configured to:

[0134] Commit the transaction branches of the storage node and metadata node;

[0135] The execution identifier in the metadata table of the computing node is updated to the identifier of the target DDL command, and the transaction branch of the computing node is submitted. The execution identifier is used to mark the latest DDL command executed by the computing node.

[0136] In an optional embodiment, the locking module 420 is specifically configured to:

[0137] Block other DDL commands until the target DDL command's task is completed and then continue to execute.

[0138] Understandably, Figure 4 The relevant contents of each module in the method have been described in detail in the aforementioned method embodiment. For details, please refer to the contents of the method embodiment and will not be repeated here.

[0139] The metadata synchronization device 400 in the embodiment of the present application can determine whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node when executing the target DDL command; if not, wait for the DDL replay process to execute the latest DDL command, and after updating the metadata table accordingly, lock the DDL operation log; append the information of the target DDL command to the DDL operation log, and execute the target DDL command, so as to realize distributed database metadata synchronization based on the global operation log, ensure that each computing node in the cluster executes exactly the same DDL operation sequence, thereby generating exactly the same metadata in each computing node.

[0140] In one embodiment of the present application, an electronic device is also provided. Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 5 As shown, the electronic device 500 includes a processor 501 and a memory 502. The memory 502 stores a computer program. When the computer program is executed by the processor 501, the following operations are performed: Figure 1-Figure 2 Any step in the above method embodiment is shown.

[0141] In one embodiment, a computer-readable storage medium is further provided. The computer-readable storage medium stores a computer program. When the computer program is executed by the processor 501, the processor 501 executes any step in the above method embodiment.

[0142] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0143] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, 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, they should be considered to be within the scope of this specification.

[0144] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. A metadata synchronization method, characterized in that: The method comprises: When executing the target DDL command, determine whether all existing DDL commands in the DDL operation log have been executed based on the metadata table of the computing node; The determining, based on the metadata table, whether all existing DDL commands in the DDL operation log have been executed includes: comparing a replication identifier in the metadata table with a maximum identifier in the DDL operation log, the replication identifier being used to mark a replication position of the computing node in the DDL operation log; if the replication identifier and the maximum identifier in the DDL operation log are the same, determining that all existing DDL commands in the DDL operation log have been executed; if the replication identifier and the maximum identifier in the DDL operation log are different, determining that all existing DDL commands in the DDL operation log have not been executed; If not, wait for the DDL replay process to execute the latest DDL command and update the metadata table accordingly, then lock the DDL operation log; Append the target DDL command information to the DDL operation log, and execute the target DDL command.

2. The metadata synchronization method according to claim 1, characterized in that: The DDL replay process includes: Pull out from the DDL operation log all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table; Execute the DDL command that has not been executed; The updating of the metadata table includes: updating the replication identifier in the metadata table according to the executed DDL command.

3. The metadata synchronization method according to claim 2, characterized in that: The DDL command recorded in the DDL operation log includes the computing node identifier that initiates the execution of the DDL command; The step of pulling from the DDL operation log all DDL commands that have not been executed by the computing node and that start from the replication identifier in the metadata table includes: According to the computing node identifier, all DDL commands that have not been executed by the computing node starting from the replication identifier in the metadata table are pulled from the DDL operation log.

4. The metadata synchronization method according to claim 1, wherein: The method further comprises: The DDL transaction of the target DDL command is committed.

5. The metadata synchronization method according to claim 4, characterized in that: The DDL transaction for submitting the target DDL command includes: Commit the transaction branches of the storage node and metadata node; The execution identifier in the metadata table of the computing node is updated to the identifier of the target DDL command, and the transaction branch of the computing node is submitted. The execution identifier is used to mark the latest DDL command executed by the computing node.

6. The metadata synchronization method according to claim 5, characterized in that: The locking of the DDL operation log includes: Block other DDL commands until the target DDL command's task is completed and then continue to execute.

7. A metadata synchronization device, characterized in that: include: a determination module, configured to determine, when executing a target DDL command, based on a metadata table of a computing node, whether all existing DDL commands in a DDL operation log have been executed; The determining module is specifically configured to compare the replication identifier in the metadata table with the maximum identifier of the DDL operation log, wherein the replication identifier is used to mark the replication position of the computing node in the DDL operation log; If the copy identifier is the same as the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have been executed; If the copy identifier is different from the maximum identifier of the DDL operation log, it is determined that all existing DDL commands in the DDL operation log have not been executed; A locking module, configured to lock the DDL operation log after waiting for the DDL replay process to execute the latest DDL command and update the metadata table accordingly if all existing DDL commands in the DDL operation log have not been executed; An execution module is used to append information of the target DDL command to the DDL operation log and execute the target DDL command.

8. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor is caused to perform the steps of the method according to any one of claims 1 to 6.

Images