Main and standby replication method and system for single-machine time sequence database DDL (Double Data Language)
By using WAL logs in the time series database to transmit DDL SQL statements and attaching unique IDs and version numbers, the table structure consistency problem between the master and slave databases is solved, and lightweight DDL master-slave replication is implemented for a single-machine time series database, which is suitable for the Internet of Things and monitoring systems.
Patent Information
- Application Number
- CN202510698046.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-28
- Publication Date
- 2025-09-16
AI Technical Summary
When DDL operations in traditional time series databases are synchronized between the primary and standby databases, there are problems such as table ID conflicts and missing version verification. As a result, the standby database may execute old versions or miss key operations, and the table structure consistency of the primary and standby nodes cannot be guaranteed.
The master database transmits DDL SQL statements through the WAL log and appends the unique ID and version number of the time series table. The slave database executes the statements in the order of the log LSN and verifies the continuity of the table version to ensure that the table structure changes on the master and slave nodes are completely consistent.
Through LSN sequentiality and metadata version verification, table ID conflicts and version inconsistencies are avoided, ensuring the consistency of the operation sequence and status of the master and standby nodes. This is suitable for single-machine master-standby disaster recovery scenarios and guarantees the reliability of time series data in the Internet of Things and monitoring systems.
Smart Images
Figure CN120653488A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of time series databases, and in particular to a method and system for master-slave replication of DDL data in a stand-alone time series database. Background Art
[0002] In traditional technologies, the core challenge facing time series data synchronization is that the DDL operations of time series databases (such as creating time partitions and modifying retention policies) rely on strict time order and table structure version consistency. Traditional replication solutions do not explicitly manage the unique identifier (ID) and version number of the time series table, which may cause the backup database to misjudge the table structure status.
[0003] Although WAL logs can guarantee the order of operations, they are not associated with the metadata version of the time series table. The slave database may execute old version DDL or miss key operations (such as partition ID conflicts).
[0004] In summary, traditional technical solutions have the following defects:
[0005] 1. SQL statement replay alone cannot avoid table ID conflicts (for example, duplicate table IDs automatically generated by the active and standby nodes);
[0006] 2. Due to the lack of a version verification mechanism, the slave database may overwrite the latest table structure of the master database (for example, after executing ALTER TABLE on the master database, the slave database mistakenly executes CREATE TABLE of an older version).
[0007] How to bind the sequential nature of the WAL log (LSN) with the metadata (ID, version) of the time series table to form a complete consistency check chain; and how to implement lightweight table ID allocation and version tracking in a single-machine master-slave architecture to avoid distributed coordination overhead are currently urgent issues to be solved in time series databases. Summary of the Invention
[0008] The technical task of the present invention is to address the above shortcomings and provide a stand-alone time series database DDL master-slave replication method and system, which can solve the sequentiality and version conflict problems unique to time series data, is suitable for stand-alone master-slave disaster recovery scenarios, and ensures the reliability of time series data in the Internet of Things, monitoring systems, etc.
[0009] The technical solution adopted by the present invention to solve its technical problem is:
[0010] A standalone time series database DDL master-slave replication method uses the master database to transmit DDL SQL statements through the WAL log, appending the unique ID (table_id) and version number (version) of the time series table. The slave database executes the statements in the order of the log LSN and verifies the continuity of the table version to ensure that the table structure changes on the master and slave nodes are completely consistent. The specific implementation method is as follows:
[0011] The master database assigns a unique ID table_id and an incrementing version number version to each time series table, and encapsulates the DDL SQL statement, table_id, version, and LSN into a WAL log.
[0012] The standby database executes logs in LSN order and verifies whether the current_version of the target table is equal to the prev_version of the log to ensure version continuity.
[0013] This method leverages the natural sequential nature of LSNs and metadata version verification to ensure the order of operations. Combining table IDs and version numbers ensures complete consistency of table structures between active and standby nodes, resolving the sequential nature and version conflicts inherent in time series data. It is suitable for single-node active / standby disaster recovery scenarios, ensuring the reliability of time series data in IoT, monitoring systems, and other applications.
[0014] Furthermore, the master database generates WAL logs and manages metadata. The specific implementation process is as follows:
[0015] 1) Generation of the master database time series table ID and version number:
[0016] The master database assigns a unique ID (TableID, such as metrics_001) to each time series table. The ID remains unchanged during the table's lifecycle.
[0017] Each DDL operation (such as CREATE TABLE, ALTER TABLE) generates an incremental version number (Version, such as V1 for the initial version and V2 for the modified version). The version number is bound to the LSN of the WAL log.
[0018] 2) WAL log enhanced encapsulation:
[0019] Each DDL log contains:
[0020] Original SQL statement: used for replay execution in the standby database;
[0021] LSN: Log Sequence Number, automatically generated by the master database kernel and strictly monotonically increasing;
[0022] Time series table metadata, including:
[0023] table_id: unique identifier of the target table;
[0024] current_version: the table version number after the operation;
[0025] prev_version: table version number before the operation (used for version verification);
[0026] Time partition information, including partition time range and granularity.
[0027] Furthermore, the time partition information is obtained by parsing the SQL statement.
[0028] Furthermore, the standby database performs metadata verification in log order. The specific implementation process is as follows:
[0029] 1) The standby database executes in the order driven by the log LSN:
[0030] The standby database maintains an LSN sequence queue to ensure execution in ascending order of log LSNs, including:
[0031] Assume that the master database generates a WAL log with LSN = 1000. When the slave database receives the log, if LSN = 1001 but LSN = 1000 has not been executed, the log is temporarily stored until LSN = 1000 is completed.
[0032] The synchronization breakpoint can be quickly located through the LSN heartbeat packets (including the current maximum LSN) sent regularly by the master database.
[0033] 2) Time series table metadata verification, including:
[0034] Table ID uniqueness check:
[0035] When creating a table for the first time on a standby database, you must use the table_id assigned by the primary database to avoid conflicts caused by locally generated IDs.
[0036] If a table_id that is not created locally is received, the execution is rejected and an ID conflict is prompted;
[0037] Version number continuity check:
[0038] Before executing DDL, verify whether the current_version of the target table in the standby database is equal to the prev_version in the log. If so, the DDL can be executed; otherwise, it can be skipped or rolled back.
[0039] For example, if the current version of metrics_001 in the standby database is V2, a log with prev_version = V2 can be executed. If prev_version = V1, the log is considered to be an old version and will be skipped or rolled back.
[0040] Furthermore, this method achieves consistency assurance through a double check chain design:
[0041] Sequence chain: LSN → operation execution order;
[0042] Version chain: table_id→prev_version→current_version→table structure status;
[0043] The master and slave databases are bound by logs to ensure consistent operation order and version status between the master and slave nodes.
[0044] When the standby database's table version is outdated due to misoperation (such as manual DDL execution),
[0045] The standby database obtains a full metadata snapshot of the primary database, including the table_id, version number, and SQL statements of all tables.
[0046] The standby database replays the logs according to the LSN, overwriting the incorrect table structure and restoring the database to a consistent state with the primary database.
[0047] Furthermore, the specific implementation process of creating a time series table in the main database is as follows:
[0048] S1. Client executes command:
[0049] CREATE TIMESERIES TABLE metrics;
[0050] S2, main database processing:
[0051] S2.1. Assign table_id = metrics_001, initial version V1;
[0052] S2.2. Generate a WAL log, LSN = 1000, including:
[0053]
[0054] S2.3. Send logs to the standby database, with the LSN sequence being 1000.
[0055] S3. Execution and verification of the standby database:
[0056] Receiving logs:
[0057] Verify that LSN=1000 is the current maximum executable sequence number and that no preceding logs are missing;
[0058] Parsing table_id = metrics_001. This table does not exist locally, so creation is allowed.
[0059] Execute the SQL statement to create a table and record current_version = V1.
[0060] Furthermore, the specific implementation process of modifying the table structure of the main database is as follows:
[0061] S1. Client executes command:
[0062] ALTER TABLE metrics_001ADD COLUMN location STRING;
[0063] S2, main database processing:
[0064] The version number increases to V2, and a log with LSN = 1001 is generated, which contains:
[0065]
[0066] S3, standby database execution:
[0067] Verify that LSN=1001 is the current maximum executable serial number and no preceding logs are missing;
[0068] Verify that the current version of metrics_001 is V1 and matches the log prev_version;
[0069] Execute the ALTER operation to update the version to V2 to ensure consistency with the main database.
[0070] The present invention also claims protection for a stand-alone time series database DDL master-slave replication system, in which the master database transmits DDL SQL statements through the WAL log and appends the unique ID (table_id) and version number (version) of the time series table; the slave database executes according to the log LSN sequence and verifies the continuity of the table version to ensure that the table structure changes of the master and slave nodes are completely consistent;
[0071] The system specifically implements the DDL master-slave replication of a single-machine time series database through the above method.
[0072] The present invention also claims protection for a device for implementing DDL master-slave replication of a stand-alone time series database, comprising: at least one memory and at least one processor;
[0073] The at least one memory is configured to store a machine-readable program;
[0074] The at least one processor is configured to call the machine-readable program to implement the above method.
[0075] The present invention also claims protection for a computer-readable medium having computer instructions stored thereon, which are capable of implementing the above method when executed by a processor.
[0076] Compared with the prior art, the present invention provides a stand-alone time series database DDL master-slave replication method and system with the following advantages:
[0077] 1. Absolute sequentiality: LSN ensures that the slave database completely replicates the DDL execution order of the primary database, avoiding foreign key and partition dependency errors caused by disorder.
[0078] 2. Strong version consistency: By verifying the table_id and version number, the slave database is prevented from executing old or conflicting DDL statements, ensuring that the table structure is byte-for-byte consistent with the master database.
[0079] 3. Lightweight implementation: No distributed coordination components are required. The single-machine kernel automatically manages LSN and version numbers, adapting to low-cost active-standby architecture. BRIEF DESCRIPTION OF THE DRAWINGS
[0080] Figure 1 This is a flowchart of a stand-alone time series database DDL master-slave replication method provided by an embodiment of the present invention;
[0081] Figure 2 The figure shows a full recovery process when the standby database version verification fails, provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0082] The present invention will be further described below with reference to specific embodiments.
[0083] This embodiment of the present invention provides a standalone time series database DDL master-slave replication method. The master database transmits DDL SQL statements through the WAL log, appending the unique ID (table_id) and version number (version) of the time series table. The slave database executes the statements in the order of the log LSN and verifies the continuity of the table version to ensure that the table structure changes on the master and slave nodes are completely consistent. The specific implementation method is as follows:
[0084] The master database assigns a unique ID table_id and an incrementing version number version to each time series table, and encapsulates the DDL SQL statement, table_id, version, and LSN into a WAL log.
[0085] The standby database executes logs in LSN order and verifies whether the current_version of the target table is equal to the prev_version of the log to ensure version continuity.
[0086] 1. The master database generates WAL logs and manages metadata. The specific implementation process is as follows:
[0087] 1. Generation of the master database time series table ID and version number:
[0088] The master database assigns a unique ID (TableID, such as metrics_001) to each time series table. The ID remains unchanged during the table's lifecycle.
[0089] Each DDL operation (such as CREATE TABLE, ALTER TABLE) generates an incremental version number (Version, such as the initial version is V1, and the modified version is V2), and the version number is bound to the LSN of the WAL log.
[0090] 2. WAL log enhanced encapsulation:
[0091] Each DDL log contains:
[0092] Original SQL statement: used for replay execution in the standby database;
[0093] LSN: Log Sequence Number, automatically generated by the master database kernel and strictly monotonically increasing;
[0094] Time series table metadata, including:
[0095] table_id: unique identifier of the target table;
[0096] current_version: the table version number after the operation;
[0097] prev_version: table version number before the operation (used for version verification);
[0098] Time partition information, such as partition time range and granularity (obtained from SQL statement parsing).
[0099] Log format example:
[0100]
[0101]
[0102] Second, the standby database performs metadata verification in log order. The specific implementation process is as follows:
[0103] 1. The standby database executes in the order driven by the log LSN:
[0104] The standby database maintains an LSN sequence queue to ensure execution in ascending order of log LSNs, including:
[0105] When receiving a log, if LSN=1001 but LSN=1000 has not been executed, the log is temporarily stored until LSN=1000 is completed;
[0106] The synchronization breakpoint is quickly located through the LSN heartbeat packets (including the current maximum LSN) sent regularly by the master database.
[0107] 2. Time series table metadata verification, including:
[0108] 2.1. Table ID uniqueness check:
[0109] When creating a table for the first time on a standby database, you must use the table_id assigned by the primary database to avoid conflicts caused by locally generated IDs.
[0110] If a table_id that is not created locally is received, the execution is rejected and an ID conflict is prompted.
[0111] 2.2. Version number continuity check:
[0112] Before executing DDL, verify whether the current_version of the target table in the standby database is equal to the prev_version in the log. If so, the DDL can be executed; otherwise, it can be skipped or rolled back.
[0113] For example, if the current version of metrics_001 in the standby database is V2, the received log with prev_version = V2 can be executed. If prev_version = V1, it is considered an old version log and is skipped or rolled back.
[0114] This method achieves consistency assurance through a double check chain design:
[0115] Sequence chain: LSN → operation execution order;
[0116] Version chain: table_id→prev_version→current_version→table structure status;
[0117] The master and slave databases are bound by logs to ensure that the operation sequence and version status of the master and slave nodes are consistent.
[0118] Conflict Resolution Process:
[0119] Scenario: The standby database's table version is outdated due to incorrect operation (such as manual DDL execution).
[0120] deal with:
[0121] 1. The standby database obtains a full metadata snapshot of the primary database, including the table_id, version number, and SQL statements of all tables.
[0122] 2. The standby database replays the logs according to the LSN, overwriting the incorrect table structure and restoring the database to a consistent state with the primary database. The following is an example of creating a time series table on the primary database:
[0123] 1. Client execution:
[0124]
[0125] 2. Main database processing:
[0126] 2.1. Assign table_id = metrics_001, initial version V1;
[0127] 2.2. Generate WAL log, LSN = 1000, including:
[0128]
[0129] 2.3. Send logs to the standby database, with the LSN sequence being 1000.
[0130] 3. Backup database execution and verification:
[0131] Receiving logs:
[0132] Verify that LSN=1000 is the current maximum executable sequence number and that no preceding logs are missing;
[0133] Parsing table_id = metrics_001. This table does not exist locally, so creation is allowed.
[0134] Execute the SQL statement to create a table and record current_version = V1.
[0135] An example of modifying the table structure of the main database is as follows:
[0136] 1. Client executes command:
[0137] ALTER TABLE metrics_001ADD COLUMN location STRING;
[0138] 2. Main database processing:
[0139] The version number increases to V2, and a log with LSN = 1001 is generated, which contains:
[0140]
[0141] 3. Backup database execution:
[0142] Verify that LSN=1001 is the current maximum executable serial number and no preceding logs are missing;
[0143] Verify that the current version of metrics_001 is V1 and matches the log prev_version;
[0144] Execute the ALTER operation to update the version to V2 to ensure consistency with the main database.
[0145] This method leverages the natural sequential nature of LSNs and metadata version verification to ensure the order of operations. Combining table IDs and version numbers ensures complete consistency of table structures between active and standby nodes, resolving the sequential nature and version conflicts inherent in time series data. It is suitable for single-node active / standby disaster recovery scenarios, ensuring the reliability of time series data in IoT, monitoring systems, and other applications.
[0146] An embodiment of the present invention also provides a stand-alone time series database DDL master-slave replication system, in which the master database transmits DDL SQL statements through WAL logs and appends the unique ID (table_id) and version number (version) of the time series table; the slave database executes according to the log LSN sequence and verifies the continuity of the table version to ensure that the table structure changes of the master and slave nodes are completely consistent; the system specifically implements the stand-alone time series database DDL master-slave replication method described in the above embodiment.
[0147] The master database assigns a unique ID table_id and an incrementing version number version to each time series table, and encapsulates the DDL SQL statement, table_id, version, and LSN into a WAL log.
[0148] The standby database executes logs in LSN order and verifies whether the current_version of the target table is equal to the prev_version of the log to ensure version continuity.
[0149] 1. The master database generates WAL logs and manages metadata. The specific implementation process is as follows:
[0150] 1. Generation of the master database time series table ID and version number:
[0151] The master database assigns a unique ID (TableID, such as metrics_001) to each time series table. The ID remains unchanged during the table's lifecycle.
[0152] Each DDL operation (such as CREATE TABLE, ALTER TABLE) generates an incremental version number (Version, such as the initial version is V1, and the modified version is V2), and the version number is bound to the LSN of the WAL log.
[0153] 2. WAL log enhanced encapsulation:
[0154] Each DDL log contains:
[0155] Original SQL statement: used for replay execution in the standby database;
[0156] LSN: Log Sequence Number, automatically generated by the master database kernel and strictly monotonically increasing;
[0157] Time series table metadata, including:
[0158] table_id: unique identifier of the target table;
[0159] current_version: the table version number after the operation;
[0160] prev_version: table version number before the operation (used for version verification);
[0161] Time partition information, such as partition time range and granularity (obtained from SQL statement parsing).
[0162] Second, the standby database performs metadata verification in log order. The specific implementation process is as follows:
[0163] 1. The standby database executes in the order driven by the log LSN:
[0164] The standby database maintains an LSN sequence queue to ensure execution in ascending order of log LSNs, including:
[0165] When receiving a log, if LSN=1001 but LSN=1000 has not been executed, the log is temporarily stored until LSN=1000 is completed;
[0166] The synchronization breakpoint is quickly located through the LSN heartbeat packets (including the current maximum LSN) sent regularly by the master database.
[0167] 2. Time series table metadata verification, including:
[0168] 2.1. Table ID uniqueness check:
[0169] When creating a table for the first time on a standby database, you must use the table_id assigned by the primary database to avoid conflicts caused by locally generated IDs.
[0170] If a table_id that is not created locally is received, the execution is rejected and an ID conflict is prompted.
[0171] 2.2. Version number continuity check:
[0172] Before executing DDL, verify whether the current_version of the target table in the standby database is equal to the prev_version in the log. If so, the DDL can be executed; otherwise, it can be skipped or rolled back.
[0173] For example, if the current version of metrics_001 in the standby database is V2, the received log with prev_version = V2 can be executed. If prev_version = V1, it is considered an old version log and is skipped or rolled back.
[0174] An embodiment of the present invention further provides a device for implementing DDL master-slave replication of a stand-alone time series database, comprising: at least one memory and at least one processor;
[0175] The at least one memory is configured to store a machine-readable program;
[0176] The at least one processor is configured to call the machine-readable program to implement the stand-alone time series database DDL master-slave replication method described in the above embodiment.
[0177] Embodiments of the present invention also provide a computer-readable medium storing computer instructions that, when executed by a processor, implement the standalone time series database DDL master-slave replication method described in the above embodiments. Specifically, a system or device equipped with a storage medium can be provided. The storage medium stores software program code that implements the functions of any of the above embodiments, and enables a computer (or CPU or MPU) of the system or device to read and execute the program code stored in the storage medium.
[0178] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute part of the present invention.
[0179] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code can be downloaded from a server computer via a communication network.
[0180] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.
[0181] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU installed on the expansion board or expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.
[0182] The present invention has been shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the scope of protection of the present invention.
Claims
1. A stand-alone time series database DDL master-slave replication method, characterized by: The master database transmits DDL SQL statements through the WAL log, and appends the unique ID and version number of the time series table. The slave database executes them in the order of the log LSN and verifies the continuity of the table version to ensure that the table structure changes on the master and slave nodes are completely consistent. The specific implementation method is as follows: The master database assigns a unique ID table_id and an incrementing version number version to each time series table, and encapsulates the DDL SQL statement, table_id, version, and LSN into a WAL log. The standby database executes logs in LSN order and verifies whether the current_version of the target table is equal to the prev_version of the log to ensure version continuity.
2. A standalone time series database DDL master-slave replication method according to claim 1, characterized in that: The master database generates WAL logs and manages metadata. The specific implementation process is as follows: 1) Generation of the master database time series table ID and version number: The master database assigns a unique ID to each time series table, and the ID remains unchanged during the table's lifecycle. Each DDL operation generates an incremental version number, which is bound to the LSN of the WAL log; 2) WAL log enhanced encapsulation: Each DDL log contains: Original SQL statement: used for replay execution in the standby database; LSN: Log Sequence Number, automatically generated by the master database kernel and strictly monotonically increasing; Time series table metadata, including: table_id: unique identifier of the target table; current_version: the table version number after the operation; prev_version: table version number before the operation; Time partition information, including partition time range and granularity.
3. A standalone time series database DDL master-slave replication method according to claim 2, characterized in that: The time partition information is obtained by parsing the SQL statement.
4. A standalone time series database DDL master-slave replication method according to claim 1, characterized in that: The standby database performs metadata verification in log order. The specific implementation process is as follows: 1) The standby database executes in the order driven by the log LSN: The standby database maintains an LSN sequence queue to ensure execution in ascending order of log LSNs, including: Assume that the master database generates a WAL log with LSN = 1000. When the slave database receives the log, if LSN = 1001 but LSN = 1000 has not been executed, the log is temporarily stored until LSN = 1000 is completed. Quickly locate synchronization breakpoints through LSN heartbeat packets regularly sent by the master database. 2) Time series table metadata verification, including: Table ID uniqueness check: When creating a table for the first time on a standby database, you must use the table_id assigned by the primary database to avoid conflicts caused by locally generated IDs. If a table_id that is not created locally is received, the execution is rejected and an ID conflict is prompted; Version number continuity check: Before executing DDL, verify whether the current_version of the target table in the standby database is equal to the prev_version in the log. If so, the DDL can be executed; otherwise, it can be skipped or rolled back.
5. The method for DDL master-slave replication of a single-machine time series database according to claim 1, characterized in that: Through the dual check chain design, consistency is guaranteed: Sequence chain: LSN → operation execution order; Version chain: table_id→prev_version→current_version→table structure status; The master and slave databases are bound by logs to ensure consistent operation order and version status between the master and slave nodes. When the standby database's table version falls behind due to misoperation, The standby database obtains a full metadata snapshot of the primary database, including the table_id, version number, and SQL statements of all tables. The standby database replays the logs according to the LSN, overwriting the incorrect table structure and restoring the database to a consistent state with the primary database.
6. A standalone time series database DDL master-slave replication method according to claim 1, characterized in that: The specific implementation process of creating a time series table in the main database is as follows: S1. Client executes command: CREATE TIMESERIES TABLE metrics; S2, main database processing: S2.
1. Assign table_id = metrics_001, initial version V1; S2.
2. Generate a WAL log, LSN = 1000, including: S2.
3. Send logs to the standby database, with the LSN sequence being 1000. S3. Execution and verification of the standby database: Receiving logs: Verify that LSN=1000 is the current maximum executable sequence number and that no preceding logs are missing; Parsing table_id = metrics_001. This table does not exist locally, so creation is allowed. Execute the SQL statement to create a table and record current_version = V1.
7. A standalone time series database DDL master-slave replication method according to claim 1 or 6, characterized in that: The specific implementation process of modifying the table structure of the main database is as follows: S1. Client executes command: ALTER TABLE metrics_001ADD COLUMN location STRING; S2, main database processing: The version number increases to V2, and a log with LSN = 1001 is generated, which contains: S3, standby database execution: Verify that LSN=1001 is the current maximum executable serial number and no preceding logs are missing; Verify that the current version of metrics_001 is V1 and matches the log prev_version; Execute the ALTER operation to update the version to V2 to ensure consistency with the main database.
8. A single-machine time series database DDL master-slave replication system, characterized by: The master database transmits DDL SQL statements through the WAL log, appending the unique ID and version number of the time series table. The slave database executes the statements in the order of the log LSN and verifies the continuity of the table version to ensure that the table structure changes on the master and slave nodes are completely consistent. The system specifically implements the DDL master-slave replication of a single-machine time series database through the method described in any one of claims 1 to 7.
9. A device for implementing DDL master-slave replication in a single-machine time series database, characterized in that: include: at least one memory and at least one processor; The at least one memory is configured to store a machine-readable program; The at least one processor is configured to call the machine-readable program to implement the method according to any one of claims 1 to 7.
10. A computer-readable medium, characterized in that The computer readable medium stores computer instructions, which, when executed by a processor, can implement the method according to any one of claims 1 to 7.