Application upgrading method, equipment and medium

Abstract

The invention discloses an application upgrading method and device and a medium, belongs to the field of data processing, and is used for solving the problem that application upgrading interrupts services, and the method comprises the steps that when an application upgrading request is received, a new version metadata package is loaded and analyzed, and an executable database change statement is generated; creating a blank shadow table according to the executable database change statement; the shadow table has the same structure as the new version database table; locking the shadow table, and performing data synchronization on the shadow table according to the service data of the old version production table; the old version production table is in a read-write state; and when data synchronization succeeds, replacing the old version production table with the shadow table. And under the condition of not interrupting the service, smooth upgrading and rollback of the running state application are realized.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to an application upgrading method, device and medium. Background Art

[0002] During the iterative upgrade process of database application systems, database table structure changes and data migration are key steps. Metadata-driven low-code platforms can dynamically generate database table structures and business processes based on JSON metadata published during design, simplifying development and deployment.

[0003] Traditional database upgrades typically involve directly executing Data Definition Language (DDL) statements on production tables to perform structural changes. However, this approach requires locking production tables for extended periods, preventing business systems from reading and writing data normally. This creates downtime windows, leading to service interruptions and availability issues. Furthermore, the data migration process is tightly coupled with table structure changes. Any exceptions during the data migration process can lead to data inconsistencies and complex rollbacks, making it difficult to ensure data integrity and accuracy.

[0004] Therefore, when upgrading running applications, how to safely upgrade the system from the old version to the new version without interrupting services and quickly roll back when problems arise is a difficult problem that needs to be solved urgently. Summary of the Invention

[0005] The embodiments of the present application provide an application upgrade method, device, and medium for solving the problem of how to safely upgrade a system from an old version to a new version without interrupting service, and quickly roll back when problems arise.

[0006] The embodiments of this application adopt the following technical solutions: On the one hand, an embodiment of the present application provides an application upgrade method, which includes: when receiving an application upgrade request, loading and parsing the new version metadata compression package to generate an executable database change statement; creating a blank shadow table based on the executable database change statement; the shadow table has the same structure as the new version database table; locking the shadow table, and performing data synchronization on the shadow table based on the business data of the old version production table; the old version production table is in a readable and writable state; when data synchronization is successful, replacing the old version production table with the shadow table.

[0007] In one example, performing data synchronization on the shadow table based on the business data of the old version production table specifically includes: fully copying the business data of the old version production table on the shadow table; capturing the business data change operations of the old version production table during the upgrade period based on the Binlog log records during the upgrade period; and incrementally synchronizing the business data change operations on the shadow table.

[0008] In one example, the method further includes: stopping the current application upgrade when an error occurs in the full replication and / or incremental synchronization; and deleting the shadow table.

[0009] In one example, replacing the old version production table with the shadow table specifically includes: locking the old version production table for a preset period of time; renaming the old version production table to the old version data table backup, and renaming the shadow table to the production table.

[0010] In one example, before loading and parsing the new version metadata compression package to generate an executable database change statement, the method also includes: taking a snapshot of the old version metadata and database table structure to obtain an old version snapshot file; uploading the old version backup to a remote object storage service to generate an old version snapshot file with a version number; and persisting the storage address and hash value of the old version snapshot file in the remote object storage service to the database.

[0011] In one example, after the production table is renamed as the old version data table backup and the shadow table is renamed as the production table, the method further includes: activating the new version metadata to switch the business requests when the application is running to the new version; if the new version runs abnormally, when the old version data table backup is not cleared, renaming the old version data table backup to the production table; extracting the old version metadata from the old version snapshot file, replacing the new version metadata with the old version metadata, and rolling back the application to the old version; and deleting the shadow table.

[0012] In one example, the method further includes: when the old version data table backup is cleared, extracting the old version metadata and database table structure from the old version snapshot file; rebuilding a blank old version database table according to the database table structure; rolling back the Binlog log records to the time when data synchronization is completed to roll back the shadow table data; copying the rolled back shadow table data to the blank old version database table; replacing the new version metadata with the old version metadata, and rolling back the application to the old version.

[0013] In one example, creating a blank shadow table according to the executable database change statement specifically includes: merging the old version database table structure according to the executable database change statement to obtain the new version database table structure; and creating a blank shadow table according to the new version database table structure.

[0014] On the other hand, an embodiment of the present application provides an application upgrade device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute an application upgrade method described in any one of the above items.

[0015] On the other hand, an embodiment of the present application provides an application upgrade non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions can execute any of the above-mentioned application upgrade methods.

[0016] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: Without interrupting services, application upgrades and rollbacks are completed without user awareness or with minimal user awareness. The system is safely upgraded from the old version to the new version, and can be quickly rolled back when problems arise, ensuring business continuity and data security to the greatest extent. The specific plan is as follows: Parallel evolution: Instead of directly modifying the running old database, a shadow database structure that conforms to the new blueprint is secretly created in the background. This allows full synchronization of business data from the old version's production tables. Incremental changes to the old data can be synchronized in real time while the old version's production tables are read-write. This allows for parallel changes to the shadow table to avoid locking the currently running production table.

[0017] Instant switchover: When the shadow structure is ready and the data is fully synchronized, traffic is instantly switched to the new structure.

[0018] Safe rollback: If there is a problem with the new version, you can use the backup snapshots and logs to quickly roll back the application state (metadata and database) to the version before the upgrade. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solution of the present application, some embodiments of the present application will be described in detail below with reference to the accompanying drawings, in which: Figure 1 A flowchart of an application upgrade method provided in an embodiment of the present application; Figure 2 A schematic diagram of the structure of an application upgrade device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] To make the objectives, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0021] Some embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart of an application upgrade method provided in an embodiment of the present application. This method can be applied to various business areas, such as internet finance, e-commerce, instant messaging, gaming, and government affairs. Certain input parameters or intermediate results in this process can be manually adjusted to help improve accuracy.

[0023] The analysis method involved in the embodiments of the present application can be implemented by a terminal device or a server, and the present application does not impose any special restrictions on this. For ease of understanding and description, the following embodiments are described in detail using a server as an example.

[0024] It should be noted that the server can be a single device or a system composed of multiple devices, that is, a distributed server, and this application does not make any specific restrictions on this.

[0025] The meanings involved in this application are explained as follows: Metadata: Structured data that describes application logic and database structure, such as table structure definitions and business process definitions in JSON format.

[0026] Running state: refers to the state of the application running in the production environment after deployment, as distinguished from the design state (development / design environment).

[0027] Hot upgrade: The process of upgrading and updating an application without stopping system services.

[0028] Version rollback: The process of reverting an application from a newer version to a previous stable version.

[0029] Metadata: Contains table structure definition (fields, primary keys, indexes, etc.) and logical model.

[0030] Current version metadata (old version metadata): metadata corresponding to the currently running version of the database (can be cached or reverse-engineered from the database).

[0031] New version metadata: a new version of the application blueprint released in the design state.

[0032] Gap analysis: Compare old and new metadata to generate structural differences.

[0033] Incremental DDL script: SQL script generated from the differential analysis results.

[0034] Figure 1 The process in includes the following steps: S101: When an application upgrade request is received, the new version metadata compressed package is loaded and parsed to generate an executable database change statement.

[0035] It should be noted that by loading the pre-designed new version JSON metadata in the running state, the new database table structure and business process instance can be obtained based on the new version metadata, but the old version will continue to provide services in the initial stage.

[0036] Application metadata refers to a JSON file that records the application's design blueprint through metadata. This metadata includes the application's basic configuration (such as the application ID, name, description, access address, sharing configuration, homepage, menu style, etc.), menu structure (menu ID, name, icon, location, parent menus, etc.), forms, processes, and pages. These metadata are used for front-end rendering during design to achieve visual application design, and thus support metadata conversion.

[0037] It should be noted that the application designer designs a new version of the application on the low-code platform (modifying forms, processes, menus, etc.). The platform saves these designs as a new set of JSON metadata files.

[0038] The app operator (subscriber) subscribes to the app's update notifications on the platform (registering via email). The platform stores this subscription relationship in the database.

[0039] In other words, application operators can monitor application version changes through the application subscription feature. Subscriptions are based on an email server. By registering the subscriber's email address and target application with the low-code development platform, the platform will persist the subscription relationship in the database. When the application designer releases a new version, the platform will proactively send an email to the application subscriber via the email server, notifying the subscriber of the application name, version number, and Minio address.

[0040] The operation and maintenance personnel or the release system initiates the upgrade operation through the platform interface or API and uploads the new version of the metadata compressed package.

[0041] It should be noted that the new version is essentially a new set of JSON metadata files (blueprints) that describe what the application should look like and what the database structure should be.

[0042] In some embodiments of the present application, before upgrading, a complete snapshot of the metadata of the current application version and the corresponding database table structure is taken and remotely backed up to form an independent version record. In addition, each snapshot file is stored independently to avoid overwriting.

[0043] Based on this, a snapshot of the metadata and database table structure of the old version is taken to obtain the old version snapshot file.

[0044] Then, upload the old version backup to a remote object storage service to generate an old version snapshot file with a version number. The remote object storage service can be Minio.

[0045] Finally, the storage address and hash value of the old version snapshot file in the remote object storage service are persisted to the database.

[0046] It should be noted that the old version snapshot file ensures that no matter whether the upgrade is successful or not, there is a known, clean old version state to fall back to.

[0047] In some embodiments of the present application, the process of generating an executable database change statement is as follows: First, when a new version of metadata compressed package is received through the HTTP interface, the compressed package is decompressed to the memory or temporary directory using an open source compression tool.

[0048] Then, the difference analysis engine is started to compare the new version metadata with the currently running metadata (old version metadata) to generate executable database change statements.

[0049] Among them, changes are divided into table level, column level, index level, and constraint level. The difference results are returned to the user in JSON format and displayed to the user through a visual table.

[0050] It should be noted that the platform may simulate the execution of DDL or execute it in a test environment to further verify the feasibility of the change, and return the change preview and risks to the user. After the operation and maintenance personnel confirm that everything is correct, they click the Execute Change button.

[0051] S102: Creating a blank shadow table according to the executable database change statement; the shadow table has the same structure as the new version database table.

[0052] In some embodiments of the present application, the present application does not directly modify the running old database, but secretly creates a shadow database structure that conforms to the new blueprint in the background, thereby avoiding directly locking the production table of the running application.

[0053] Based on this, the process of creating a blank shadow table is as follows: First, based on the executable database change statement, the old version database table structure is merged to obtain the new version database table structure. For example, if the executable database change statement is to add field A, then the new version database table structure will have field A.

[0054] Then, create a blank shadow table based on the new version database table structure.

[0055] That is to say, for the data table that needs to be changed, a blank shadow table is created in the background, and the shadow table structure is consistent with the target change structure; the change operation is implemented on the shadow table to avoid directly locking the production table.

[0056] S103: Lock the shadow table, and synchronize the shadow table with the business data of the old version production table; the old version production table is in a readable and writable state.

[0057] In some embodiments of the present application, upon receiving an application upgrade request, Binlog backup is enabled. Before performing any actual database changes, the platform instructs the database to enable Binlog (if not already enabled) to record user write operations to the running production tables during the upgrade. In other words, the database's binary log is enabled before the upgrade begins, allowing for subsequent incremental restores.

[0058] Based on this, the process of performing data synchronization on the shadow table is as follows: Fully copy the business data of the old version production table on the shadow table.

[0059] In addition, based on the Binlog log records during the upgrade, the business data change operations of the old version production table during the upgrade are captured.

[0060] Incrementally synchronize business data changes on the shadow table.

[0061] In summary, the new version creates the corresponding tables and indexes in the background and performs data migration or field mapping. During this period, the mapping logic defined in the metadata synchronizes change requests to the old table to the new table to ensure data consistency.

[0062] It should be noted that when the full replication of business data begins, the platform starts the real-time data synchronization mechanism. The platform tools (or the database's own functions such as CDC) continuously read the Binlog, and the synchronization tool applies these captured change operations to the shadow table in real time.

[0063] To summarize, copy the production table's data to the shadow table and enable real-time replication (or read the Binlog) to synchronize write operations (additions, updates, and deletions) to the production table during the upgrade to the shadow table, ensuring data consistency between the two tables. This ensures that the shadow table's data is ultimately consistent with the production table, even if the production table is still being modified during the data migration.

[0064] S104: When data synchronization is successful, the shadow table replaces the old version production table.

[0065] In some embodiments of the present application, the platform continuously monitors the status of full replication and incremental synchronization until it confirms that the data in the shadow table is consistent with the production table (for example, usually by comparing the number of records, key field checksums, or Binlog position points).

[0066] It's important to note that full replication uses small batch transactions, and each incremental synchronization change also uses small transactions. Production tables remain readable and writable throughout the entire process. In other words, transaction boundaries are strictly controlled throughout the process to minimize long transactions locking tables. Upgrade operations use small transactions or tools to migrate data in batches to ensure continuous business availability.

[0067] If an unrecoverable error occurs during shadow table creation, data replication, or synchronization, a rollback will be performed. That is, if an exception or interruption is detected during the upgrade process, the shadow table switchover will be abandoned and the newly created shadow table will be deleted.

[0068] Based on this, if an error occurs during full replication and / or incremental synchronization, the application upgrade is stopped and the shadow table is deleted.

[0069] In some embodiments of the present application, the process of replacing the old version production table with the shadow table is as follows: First, lock the old version production table for a preset period of time.

[0070] It should be noted that the platform may issue a very short-lived write lock.

[0071] Then, rename the old version production table to the old version data table backup, and rename the shadow table to the production table.

[0072] In summary, once the shadow table data is synchronized and consistent with the main table (the current production table), the shadow table replaces the production table, bringing the new table structure online. During the switchover process, methods such as database renaming or routing switching can be used to ensure smooth request switching. Users will barely notice any interruption; the application is already running on the new version, using the new database structure.

[0073] In some embodiments of the present application, after the switch is completed, the new version is verified and monitored. If the new version passes the verification, the business request is switched to the new version; if an upgrade abnormality is found, the new structure is immediately canceled, the database tables or modifications created by the new version are deleted, and the old version metadata and database structure are restored based on the snapshot backup to achieve rapid rollback.

[0074] Based on this, the new version metadata is activated to switch the business requests in the application running state to the new version.

[0075] If the new version runs abnormally and the old version data table backup is not cleared, rename the old version data table backup to the production table.

[0076] Extract the old version metadata from the old version snapshot file, replace the new version metadata with the old version metadata, and roll back the application to the old version.

[0077] In addition, the shadow table is deleted.

[0078] It should be noted that when the old version data table backup is cleared, the old version metadata and database table structure are extracted from the old version snapshot file.

[0079] Roll back the Binlog log records to the time when data synchronization is completed to roll back the shadow table data, and copy the rolled back shadow table data to the blank old version database table.

[0080] In addition, the old version metadata replaces the new version metadata.

[0081] That is to say, when the shadow table data is rolled back, the business data change operations on the shadow table data during the operation of the new version will be deleted, and the remaining business data is actually the business data of the old version production table.

[0082] It should be noted that although the embodiments of this application are based on Figure 1 Steps S101 to S104 are described in sequence, but this does not mean that steps S101 to S104 must be performed in a strict order. Figure 1 The order shown in FIG1 is to introduce and explain step S101 to step S104 in order to facilitate those skilled in the art to understand the technical solution of the embodiment of the present application. In other words, in the embodiment of the present application, the order between step S101 to step S104 can be appropriately adjusted according to actual needs.

[0083] pass Figure 1This method allows users to upgrade and roll back applications without interrupting services or with minimal user awareness. This allows the system to be safely upgraded from the old version to the new version, and quickly roll back when problems arise, ensuring business continuity and data security to the greatest extent possible. The specific solution is as follows: Versioned snapshot: Before each upgrade, a complete backup of the currently running application state (metadata blueprint + corresponding database structure) is performed.

[0084] Parallel evolution: Instead of directly modifying the running old database, a shadow database structure that conforms to the new blueprint is secretly created in the background. This allows full synchronization of business data from the old version's production tables. Incremental changes to the old data can be synchronized in real time while the old version's production tables are read-write. This allows for parallel changes to the shadow table to avoid locking the currently running production table.

[0085] Instant switchover: When the shadow structure is ready and the data is fully synchronized, traffic is instantly switched to the new structure.

[0086] Safe rollback: If there is a problem with the new version, you can use the backup snapshots and logs to quickly roll back the application state (metadata and database) to the version before the upgrade.

[0087] In a metadata-driven data architecture, DDL changes during application upgrades typically update metadata records, while the physical table structure remains unchanged. After the metadata is updated, the system gradually adjusts the physical structure through background tasks. Based on this, this application offers the following advantages: 1. Ensure business continuity and achieve zero-downtime upgrades: Old-version production tables remain readable and writable during data synchronization, without disrupting business processes. Users are unaware of system upgrades, avoiding service interruptions, order losses, and user experience degradation caused by downtime. This is particularly suitable for scenarios with high availability requirements, such as e-commerce and finance.

[0088] 2. Reduce upgrade risks and ensure data consistency.

[0089] 1. Data integrity assurance: Create and lock the shadow table first, then synchronize data from the old table to avoid data write conflicts caused by structural changes during the upgrade process.

[0090] After successful synchronization, the table is replaced atomically (for example, by renaming) to ensure consistent data state during the switch, avoiding inconsistencies where some data is in the old structure and some in the new structure.

[0091] 2. Rollback feasibility: If synchronization fails, the shadow table can be directly discarded, and the production table remains in the old version state, reducing the impact of the upgrade failure.

[0092] 3. Automated processing improves operation and maintenance efficiency.

[0093] 1. Full-process automation: From metadata parsing to generating change statements, creating shadow tables, data synchronization, and table replacement, all are automatically completed by the system, reducing manual operation errors.

[0094] Avoid syntax errors or logic loopholes that may result from manually writing SQL statements, and improve the reliability of the upgrade process.

[0095] 2. Standardized process: Using a fixed process to handle database changes of different versions makes it easier for the operation and maintenance team to reuse solutions and reduce maintenance costs.

[0096] 4. Supports smooth transition of complex structural changes: supports complex changes such as adding new fields to the table structure, modifying field types, adding indexes, etc., without the need to shut down and rebuild the table.

[0097] In summary, this solution leverages the capabilities of the metadata layer to enable smooth upgrades and rollbacks for running applications. Specifically, through the design of shadow tables and online synchronization, database upgrades can be completed without disrupting business operations. This achieves the multiple goals of high availability, data consistency, and automated operations and maintenance, making it particularly suitable for critical business systems with strict service continuity requirements.

[0098] Based on the same idea, some embodiments of the present application also provide devices and non-volatile computer storage media corresponding to the above methods.

[0099] Figure 2 A schematic diagram of the structure of an application upgrade device provided in an embodiment of the present application includes: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any one of the above-mentioned application upgrading methods.

[0100] Some embodiments of the present application provide an application upgrade non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions can execute any of the above-described application upgrade methods.

[0101] The various embodiments in this application are described in a progressive manner. Similar portions between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the device and medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For relevant portions, refer to the descriptions of the method embodiments.

[0102] The devices and media provided in the embodiments of the present application correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects to their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0103] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0104] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the technical principles of the present application should fall within the scope of protection of the present application.

Claims

1. An application upgrade method, characterized in that: The method comprises: When receiving an application upgrade request, the new version metadata compressed package is loaded and parsed to generate executable database change statements; Creating a blank shadow table according to the executable database change statement; the shadow table has the same structure as the new version database table; The shadow table is locked, and data synchronization is performed on the shadow table based on the business data of the old version production table; the old version production table is in a readable and writable state; When data synchronization is successful, the shadow table replaces the old version production table.

2. The method according to claim 1, characterized in that The step of performing data synchronization on the shadow table based on the business data of the old version production table specifically includes: Fully copy the business data of the old version production table to the shadow table; Capture business data change operations on the old version production table during the upgrade period based on Binlog log records during the upgrade period; Incrementally synchronize the business data change operation on the shadow table.

3. The method according to claim 2, characterized in that The method further comprises: If an error occurs during full replication and / or incremental synchronization, the application upgrade is stopped. Delete the shadow table.

4. The method according to claim 1, wherein The step of replacing the old version production table with the shadow table specifically includes: Locking the old version of the production table for a preset period of time; The old version production table is renamed as the old version data table backup, and the shadow table is renamed as the production table.

5. The method according to claim 1, wherein Before loading and parsing the new version metadata compressed package to generate an executable database change statement, the method further includes: Take a snapshot of the metadata and database table structure of the old version to obtain the old version snapshot file; Upload the old version backup to a remote object storage service to generate an old version snapshot file with a version number; The storage address and hash value of the old version snapshot file in the remote object storage service are persisted to the database.

6. The method according to claim 5, characterized in that After renaming the production table to the old version data table backup and renaming the shadow table to the production table, the method further includes: Activate the new version metadata to switch business requests in the application running state to the new version; If the new version runs abnormally, and the old version data table backup is not cleared, rename the old version data table backup to the production table; Extracting old version metadata from the old version snapshot file, replacing the new version metadata with the old version metadata, and rolling back the application to the old version; Delete the shadow table.

7. The method according to claim 6, characterized in that The method further comprises: When the old version data table backup is cleared, the old version metadata and database table structure are extracted from the old version snapshot file; Rebuild the blank old version database table according to the database table structure; Roll back the Binlog log records to the time when data synchronization is completed to roll back the shadow table data; Copy the rolled-back shadow table data to the blank old version database table; The metadata of the old version is used to replace the metadata of the new version, and the application is rolled back to the old version.

8. The method according to claim 1, characterized in that The step of creating a blank shadow table according to the executable database change statement specifically includes: According to the executable database change statement, the old version database table structure is merged to obtain the new version database table structure; Create a blank shadow table based on the new version database table structure.

9. An application upgrade device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the application upgrading method described in any one of claims 1 to 8.

10. An application upgrade non-volatile computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions can execute an application upgrade method as described in any one of claims 1 to 8.

Images