Backup set version determination method, device, and equipment in database, medium, and product

Abstract

The application discloses a backup set version determination method and device in a database, equipment, a medium and a product. The method comprises the following steps: acquiring a backup set sub-version list and a backup set data version list; determining a default backup set sub-version number and a default backup set data version number of a current backup set; sequentially checking the backup set sub-version list, if the attribute corresponding to the backup set sub-version number comprises an attribute causing the change of the storage format of the current backup set, determining the backup set sub-version number as the target sub-version number of the current backup set; sequentially checking the backup set data version list, if the attribute corresponding to the backup set data version number comprises an attribute affecting the data analysis of the current backup set, determining the backup set data version number as the target data version number of the current backup set; determining the target sub-version number and the target data version number as the version information of the current backup set, and storing the version information in a metadata file. The frequent upgrade of the version number of the execution code can be avoided.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to methods, apparatus, devices, media, and products for determining backup set versions in a database. Background Technology

[0002] When a database performs a backup, it generates a backup set containing a specific storage format and data parsing rules. As the database kernel continues to evolve, version compatibility checks must be performed to ensure that the executable code can be correctly identified and executed for subsequent operations.

[0003] In existing technologies, backup sets use consecutive address codes to encode backup set attributes. During backup set restoration and verification, the executable code reads the metadata file and parses out the backup set version information. This information is then compared with the executable code's own backup set version information. If the executable code's backup set major version number equals the parsed major version number and the executable code's backup set minor version number is greater than or equal to the parsed minor version number, the backup set is considered compatible; otherwise, it is incompatible. However, even if changes to the backup set do not involve adjustments to the database data or changes to the backup set format, the backup set minor version number will still be upgraded, causing older versions of the executable code to become incompatible. Summary of the Invention

[0004] This invention provides a method, apparatus, device, medium, and product for determining backup set versions in a database, in order to solve the problem of avoiding upgrades to backup set sub-version numbers without format changes.

[0005] According to one aspect of the present invention, a method for determining the version of a backup set in a database is provided, comprising: Obtain a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated. Based on the backup set sub-version number in the backup set sub-version list, determine the default backup set sub-version number of the current backup set; based on the backup set data version number in the backup set data version list, determine the default backup set data version number of the current backup set. The backup set sub-version list is checked sequentially. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it does not include an attribute, then the default backup set version number is determined as the target sub-version number. The backup set data version list is checked sequentially. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it does not include an attribute, then the default backup set data version number is determined as the target data version number. The target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in the metadata file.

[0006] According to another aspect of the present invention, a backup set version determination apparatus for a database is provided, comprising: The acquisition module is used to acquire a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated. The first determining module is used to determine the default backup set sub-version number of the current backup set based on the backup set sub-version number in the backup set sub-version list, and to determine the default backup set data version number of the current backup set based on the backup set data version number in the backup set data version list. The second determining module is used to sequentially check the backup set sub-version list. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it does not include an attribute, then the default backup set version number is determined as the target sub-version number. The third determining module is used to sequentially check the backup set data version list. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it does not include an attribute, then the default backup set data version number is determined as the target data version number. The storage module is used to determine the target sub-version number and the target data version number as the version information of the current backup set, and store the version information in a metadata file.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method described in any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the method described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the method described in any embodiment of the present invention.

[0010] The technical solution of this invention involves obtaining a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number added when an attribute that affects data parsing is updated. Based on the backup set version numbers in the backup set sub-version list, a default backup set sub-version number for the current backup set is determined. Based on the backup set data version numbers in the backup set data version list, a default backup set data version number for the current backup set is determined. The backup set version list is then checked sequentially. If the attribute corresponding to the backup set version number includes attributes that cause a change in the backup set storage format, the default backup set data version number for the current backup set is determined. If the storage format of the current backup set changes due to an attribute change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it is not included, then the default backup set sub-version number is determined as the target sub-version number. The backup set data version list is checked sequentially. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it is not included, then the default backup set data version number is determined as the target data version number. The target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in a metadata file. The technical solution of this embodiment of the invention, through the backup set sub-version list, can maintain the backup set sub-version number when the storage format of the backup set changes due to the addition of attributes. The storage format can be independently iterated and upgraded without affecting the data parsing version. Through the backup set data version list, the backup set data version number corresponding to the parsing of data in the backup set when a new attribute is added can also be maintained. By setting the default backup set sub-version number and the default backup set data version number, it is possible to ensure that all backup sets have available version information, thus avoiding meaningless version number inflation.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a method for determining the version of a backup set in a database, provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a method for determining the version of a backup set in a database, provided by an embodiment of the present invention; Figure 3 This is a flowchart of a method for determining the version of a backup set in a database, provided in Embodiment 2 of the present invention; Figure 4 This is a schematic diagram of the structure of a metadata file provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a backup set version determination device in a database provided in Embodiment 3 of the present invention; Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] A backup set is a collection used to store backup data and information generated during the backup process. A backup set can contain one or more backup piece files and a backup metadata file. The metadata file stores information about the backup set, including information about the backup set itself, database creation parameters of the backup set source library, data file information, and backup piece information. The major version number and minor version numbers of the backup set are stored in the metadata file. The major version number controls compatibility between older executable code and newer backup sets. The major version number is typically not upgraded; it is only upgraded synchronously when the major version is upgraded. The minor version number controls compatibility between older executable code and newer backup sets. When the backup set format changes or the data is altered, causing the new version of the backup set to be unable to be correctly parsed by the older executable code, the minor version number needs to be upgraded.

[0017] Backup sets use consecutive address encoding for their attributes. During backup set restoration and verification, the executable code reads the metadata file and parses out the backup set version information. This information is then compared with the executable code's own backup set version information. If the executable code's backup set major version number equals the parsed backup set major version number and the executable code's backup set minor version number is greater than or equal to the parsed backup set minor version number, the backup set is considered compatible; otherwise, it is incompatible.

[0018] The following problems exist in the existing technology: The executable code can only correctly parse the metadata file when its version information matches the backup set version information exactly. Since backup set attributes are encoded using consecutive addresses, each time an attribute is added, the backup set sub-version number needs to be globally upgraded. This means the executable code version needs frequent upgrades to ensure it can parse the latest backup set. Frequent version upgrades negatively impact the user experience. In existing technologies, older versions of executable code may be compatible with newer backup sets, but because they don't meet compatibility criteria, they are still considered incompatible, leading to backup and restore operations failing. An upgrade to the executable code version is then necessary to perform the corresponding operations. For example, a new version of executable code might be used to generate a backup set, but the backup set doesn't contain any new attributes and is structurally identical to the old version; in this case, the old version of executable code is actually compatible. In existing technologies, even changes to the backup set that don't involve adjustments to the database data or changes to the backup set format will still upgrade the backup set sub-version number, causing the old version of executable code to become incompatible. For backup and restore operations that don't require access to database data, such as displaying backup set information or deleting a backup set, the old version of executable code should be able to parse the metadata file and execute normally.

[0019] Example 1 Figure 1 This is a flowchart illustrating a method for determining a backup set version in a database according to Embodiment 1 of the present invention. This embodiment is applicable to situations where the backup set in the database is being updated. The method can be executed by a backup set version determination device, which can be implemented in hardware and / or software and can be configured in an electronic device. For example, the electronic device can be a computer, workstation, or server. Figure 1 As shown, the method includes: S110. Obtain the backup set sub-version list and the backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated.

[0020] In this embodiment, the backup set sub-version list can be a list used to maintain the corresponding increase in backup set sub-version numbers when an attribute that causes a change in the backup set's storage format is updated. The backup set sub-version number can be a version number used to identify the storage format generation of the backup set. When the storage format of the backup set is updated, the updated backup set sub-version number is recorded in the corresponding position in the backup set sub-version list. The backup set sub-version numbers are stored in the backup set sub-version list in ascending order. The backup set data version list can be a list used to maintain the corresponding backup set data version numbers when an attribute that affects data parsing is updated. The backup set data version number can be a version number used to identify the data parsing rule generation in the backup set. The data can be database data. Database data can be business database data stored in the database. For example, database data can include tuples, indexes, and / or data pages, etc. In the backup set data version list, each backup set data version number is stored in ascending order. The backup set sub-version list and the backup set data version list can be maintained globally by the database. The backup set sub-version list and the backup set data version list can be stored in memory or persistently stored on disk, and this invention does not impose any restrictions on this.

[0021] For example, attributes that cause changes to the storage format of a backup set can be attributes that cause changes to the physical structure or organization of the backup files. For instance, attributes that cause changes to the storage format of a backup set can be: attributes that add, delete, and / or rearrange fields in the backup set header, resulting in structural changes to the data header of the backup set; and / or attributes that cause changes to the organization of files or segments in the backup set.

[0022] For example, attributes affecting data parsing can be understood as those that cause the backed-up library data to be parsed using different parsing methods during restoration. For instance, attributes affecting data parsing could include: attributes that cause changes in the decompression method of the backup set's library data, such as attributes that cause changes in the compression logic of the library data; attributes that cause changes in the data type of the library data; and / or attributes that cause changes in the verification of the library data, such as attributes that change the verification method of the library data.

[0023] Specifically, through a specific data interface, such as in a database, the backup set sub-version list and backup set data version list stored in a specific location are read.

[0024] S120. Based on the backup set sub-version number in the backup set sub-version list, determine the default backup set sub-version number of the current backup set; based on the backup set data version number in the backup set data version list, determine the default backup set data version number of the current backup set.

[0025] In this embodiment, the default backup set sub-version number can be a default version number determined based on the backup set sub-version list. The default backup set data version number can be a default version number determined based on the backup set data version list. The default backup set sub-version number and the default backup set data version number ensure that the backup set has available backup set sub-version numbers and backup set data version numbers under all circumstances. The current backup set can be backup data being generated or to be generated during the backup operation. It is necessary to confirm the version of the current backup as a basis for compatibility judgment.

[0026] Specifically, the smallest backup set sub-version number in the backup set sub-version list is determined as the default backup set version number for the current backup set; the smallest backup set data version number in the backup set data version list is determined as the default backup set data version number.

[0027] S130. Check the backup set sub-version list in sequence. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it does not include an attribute, then the default backup set sub-version number is determined as the target sub-version number.

[0028] In this embodiment, the target sub-version number can be understood as the final determined sub-version number of the current backup set. The target sub-version number can be the generation number of the latest storage format of the current backup set. Updates to the storage format corresponding to the target sub-version number include substantial changes to the storage format of the current backup set.

[0029] Specifically, following the order in the backup set sub-version list, the backup set sub-version numbers are checked sequentially from smallest to largest. If the update corresponding to the backup set sub-version number includes a substantial change to the storage format of the current backup set, then the backup set version number is determined as the target sub-version number. Otherwise, the target sub-version number is set to the default backup set version number.

[0030] For example, each backup set sub-version number corresponds to a different attribute that causes storage format changes. The selection of the target sub-version number should be based on matching the attributes that actually cause storage format changes involved in the current backup set, rather than simply based on the size of the version number. If the largest sub-version number is directly used as the target sub-version number, an incompatible storage format may be incorrectly introduced if the current backup set does not contain the corresponding storage format change attribute, thus causing the backup set generation or recovery to fail.

[0031] S140. Check the backup set data version list in sequence. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then determine the backup set data version number as the target data version number of the current backup set. If it does not include an attribute, then determine the default backup set data version number as the target data version number.

[0032] In this embodiment, the target data version number can be understood as the final version number of the backup set data. The target data version number can be the generation number of the latest parsing method for the current backup set. Updates to the parsing method corresponding to the target data version number include substantial changes to the parsing method of the current backup set.

[0033] Specifically, following the order in the backup set data version list, the updates corresponding to the backup set data version numbers are checked sequentially from smallest to largest to see if they have a substantial impact on the parsing method of the current backup set. If there are updates that affect the data parsing of the current backup set, the corresponding backup set data version number is determined as the target data version number of the current backup set; otherwise, the target data version number is set to the default backup set data version number.

[0034] S150. The target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in the metadata file.

[0035] In this embodiment, the version information can be the information of the final version of the current backup set. The version information may include the target sub-version number and the target data version number, which are used to jointly determine the read, write, and recovery methods of the current backup set.

[0036] Specifically, the target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in the metadata file for retrieval during subsequent compatibility assessments.

[0037] In one example Figure 2This is a flowchart illustrating a method for determining a backup set version in a database, provided by an embodiment of the present invention. First, the minimum value in the backup set sub-version list is set as the default backup set sub-version number, and the minimum value in the backup set data version list is set as the default backup set data version number. The backup set sub-version list is then checked sequentially to determine if the attribute corresponding to the backup set sub-version number includes an attribute that would cause a change in the storage format of the current backup set. If so, the corresponding backup set sub-version number is determined as the target sub-version number of the current backup set, until the backup set sub-version list has been traversed. The backup set data version list is then checked sequentially to determine if the attribute corresponding to the backup set data version number includes an attribute that would affect the data parsing of the current backup set. If so, the backup set data version number is determined as the target data version number of the current backup set, until the backup set data version list has been traversed. The target sub-version number and the target data version number are then determined as the version information of the current backup set, and this version information is stored in a metadata file.

[0038] The technical solution of this invention involves obtaining a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number added when an attribute that affects data parsing is updated. Based on the backup set version numbers in the backup set sub-version list, a default backup set sub-version number for the current backup set is determined. Based on the backup set data version numbers in the backup set data version list, a default backup set data version number for the current backup set is determined. The backup set version list is then checked sequentially. If the attribute corresponding to the backup set version number includes attributes that cause a change in the backup set storage format, the default backup set data version number for the current backup set is determined. If the storage format of the current backup set changes due to an attribute change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it is not included, then the default backup set sub-version number is determined as the target sub-version number. The backup set data version list is checked sequentially. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it is not included, then the default backup set data version number is determined as the target data version number. The target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in a metadata file. The technical solution of this embodiment of the invention, through the backup set sub-version list, can maintain the backup set sub-version number when the storage format of the backup set changes due to the addition of attributes. The storage format can be independently iterated and upgraded without affecting the data parsing version. Through the backup set data version list, the backup set data version number corresponding to the parsing of data in the backup set when a new attribute is added can also be maintained. By setting the default backup set sub-version number and the default backup set data version number, it is possible to ensure that all backup sets have available version information, thus avoiding meaningless version number inflation.

[0039] In one embodiment, the compatibility check method for the current backup set includes: A1. Check whether the major version number of the current backup set is consistent with the major version number of the executable code, and determine the major version number check result.

[0040] In this embodiment, the major version number can be a version number used to control the compatibility between the old version of the executable code and the new version of the backup set. The major version number is typically not upgraded; it is only upgraded synchronously when the major version is upgraded. The executable code can be understood as an executable program module that performs backup generation or backup recovery operations. By comparing the version information of the current backup set with the version information carried by the executable code, it can be determined whether the executable code is compatible with the current backup set. The major version number check result can be the result of checking whether the major version number carried by the executable code is compatible with the major version number of the current backup set.

[0041] Specifically, the metadata file in the database is queried to obtain the major version number of the current backup set. Based on this major version number, it is compared with the major version number carried by the executable code to determine the major version number check result. If they match, the major version number check result indicates that the major version number carried by the executable code is compatible with the major version number of the current backup set; if they do not match, the major version number check result indicates that the major version number carried by the executable code is incompatible with the major version number of the current backup set.

[0042] For example, if the major version number check result indicates incompatibility, subsequent compatibility checks can be skipped, and the executable code can be directly returned as incompatible with the backup set version.

[0043] A2. Check whether the target sub-version number of the current backup set is less than the maximum value in the sub-version list of the backup set, and determine the sub-version number check result.

[0044] In this embodiment, the sub-version number check result can be the compatibility check result of the sub-version numbers of the backup set and the executable code, respectively.

[0045] Specifically, during the comparison, the executable code can directly retrieve the backup set sub-version list maintained globally by the database. The maximum value in this list is used instead of the backup set version number carried by the executable code, avoiding frequent upgrades to the version number. Specifically, the metadata file in the backup set is queried to obtain the target sub-version number of the current backup set from its version information. This target sub-version number is compared with the maximum value in the backup set sub-version list. If the target sub-version number is less than the maximum value, the sub-version number check indicates compatibility; otherwise, it indicates incompatibility.

[0046] A3. Check whether the target data version number of the current backup set is less than the maximum value of the backup set data version list, and determine the data version number check result.

[0047] In this embodiment, the data version number check result can be the compatibility check result of the data version numbers of the current backup set and the corresponding backup sets of the executable code.

[0048] Specifically, during the comparison, the maximum value in the backup set data version list can be directly read to replace the backup set data version number carried by the executable code. If the target data version number of the current backup set is less than the maximum value in the backup set data version list, the data version number check result indicates compatibility; otherwise, it indicates incompatibility.

[0049] A4. Determine the compatibility result based on the main version number check result, the sub-version number check result, and the data version number check result. The compatibility result includes whether the version of the current backup set is compatible with the version of the executable code.

[0050] In this embodiment, the compatibility result can be an indication of whether the version of the current backup set is compatible with the version of the executable code. Based on the compatibility result, it can be determined whether the subsequent operations to be performed by the executable code can continue to be executed.

[0051] Specifically, the compatibility result is determined based on one or more of the major version number check result, the minor version number check result, and the data version number check result. For example, if the major version number check result, the minor version number check result, and the data version number check result all indicate compatibility, then the compatibility result indicates that the version of the current backup set is compatible with the version of the executable code.

[0052] In one embodiment, determining the compatibility result based on the major version number check result, the sub-version number check result, and the data version number check result includes: B1. Determine the target check result based on the type of operation performed on the current backup set. The target check result includes one or more of the main version number check result, the sub-version number check result, and the data version number check result.

[0053] In this embodiment, the operation type can be the type of operation that the executable code is to perform on the current backup set. For example, the operation type could be displaying information about the current backup set or data restoration. The target check result can be a check result determined based on the compatibility requirements of the operation type. The target check result can be one or more of the major version number check result, the minor version number check result, and the data version number check result.

[0054] Specifically, the target check result is determined based on the type of operation performed on the current backup set as indicated by the execution code.

[0055] For example, if the operation type is to display information about the current backup set, the target check result includes the major version number check result and the minor version number check result; if the operation type is data restoration, the target check result includes the major version number check result, the minor version number check result, and the data version number check result.

[0056] B2. If all the target check results meet the preset conditions, then the compatibility result indicates that the version of the current backup set is compatible with the version of the executable code.

[0057] In this embodiment, the preset conditions can be pre-set rules for determining version compatibility. For example, the preset conditions can be that the target check results, including the major version number check result, the sub-version number check result, and the data version number check result, all indicate compatibility.

[0058] Specifically, if the target check results all meet the preset conditions, the compatibility result indicates that the version of the current backup set is compatible with the version of the executable code.

[0059] Example 2 Figure 3 This is a flowchart illustrating a method for determining a backup set version in a database, as provided in Embodiment 2 of the present invention. This embodiment is an optimization based on any of the above embodiments and mainly includes a detailed description of the backup set version update process. It should be noted that technical details not described in detail in this embodiment can be found in any of the above embodiments. Figure 3 As shown, the method includes: S310, Retrieve newly added attributes in the backup set.

[0060] Specifically, before generating the backup set, the various attributes updated in this update are received from a specific data interface, compared with the existing attributes in the backup set, and the newly added attributes are determined.

[0061] S320. If the attribute includes an attribute that does not affect data parsing, then the attribute is determined as a self-describing attribute, the self-describing attribute is registered, and the information of the self-describing attribute is stored in the metadata file.

[0062] In this embodiment, self-describing attributes can be newly added attributes that do not affect the parsing of library data. Self-describing attributes can identify attributes that are updated in this instance and do not affect the parsing of library data, while keeping the backup set version unchanged.

[0063] Specifically, if the newly added attribute does not affect the data parsing of the backup set database, the information of the self-describing attribute will be registered in the metadata file. For example, the information of the self-describing attribute may include: the number of self-describing attributes added in this update and the specific information of each self-describing attribute, including the length of the specific information, the attribute number, the data type of the attribute value, the length of the attribute name, the name of the attribute, the length of the attribute value, and the attribute value.

[0064] S330. If the attribute includes an attribute that affects data parsing, then add the backup set data version number corresponding to the attribute to the backup set data version list.

[0065] Specifically, if the newly added attributes include those that affect data parsing, the backup set data version number corresponding to this update will be added to the latest position in the backup set data version list.

[0066] S340. If the attribute includes an attribute that causes a change in the storage format of the backup set, then add the backup set sub-version number corresponding to the attribute to the backup set version list.

[0067] Specifically, if the newly added attribute includes one that causes a change in the backup set storage format, then the backup set sub-version number corresponding to this update will be added to the latest position in the backup set version list.

[0068] S350. Obtain the backup set sub-version list and the backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated.

[0069] S360. Based on the backup set sub-version number in the backup set sub-version list, determine the default backup set sub-version number of the current backup set; based on the backup set data version number in the backup set data version list, determine the default backup set data version number of the current backup set.

[0070] S370. Check the backup set sub-version list in sequence. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then determine the backup set sub-version number as the target sub-version number of the current backup set. If it does not include an attribute, then determine the default backup set sub-version number as the target sub-version number.

[0071] S380. Check the backup set data version list in sequence. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then determine the backup set data version number as the target data version number of the current backup set. If it does not include an attribute, then determine the default backup set data version number as the target data version number.

[0072] S390. The target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in the metadata file.

[0073] The technical solution of this invention involves: acquiring newly added attributes in the backup set; if the attribute includes an attribute that does not affect data parsing, then the attribute is identified as a self-describing attribute, the self-describing attribute is registered, and the information of the self-describing attribute is stored in a metadata file; if the attribute includes an attribute that affects data parsing, then the backup set data version number corresponding to the attribute is added to the backup set data version list; if the attribute includes an attribute that causes a change in the backup set storage format, then the backup set sub-version number corresponding to the attribute is added to the backup set sub-version list; acquiring a backup set sub-version list and a backup set data version list, wherein the backup set sub-version list includes the backup set sub-version numbers added when updating attributes that cause a change in the backup set storage format, and the backup set data version list includes the backup set data version numbers added when updating attributes that affect data parsing; and determining the default of the current backup set based on the backup set sub-version numbers in the backup set sub-version list. The backup set sub-version number is determined based on the backup set data version number in the backup set data version list, to establish a default backup set data version number for the current backup set. The backup set sub-version list is then checked sequentially. If the attribute corresponding to the backup set sub-version number includes an attribute that causes a change in the storage format of the current backup set, then the backup set sub-version number is determined as the target sub-version number for the current backup set; otherwise, the default backup set version number is determined as the target sub-version number. The backup set data version list is then checked sequentially. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number for the current backup set; otherwise, the default backup set data version number is determined as the target data version number. The target sub-version number and the target data version number are then used to determine the version information of the current backup set, and this version information is stored in a metadata file. The technical solution of this invention stores attributes unrelated to library data parsing as self-describing attributes in the metadata file. This allows older versions of the executable code that support self-describing attributes to be correctly parsed, thus avoiding frequent version upgrades.

[0074] In one embodiment, registering the self-describing attribute includes: S3201. Register the first attribute information of the self-describing attribute in the self-describing attribute identifier list, wherein the first attribute information includes the identifier of the self-describing attribute.

[0075] In this embodiment, the first attribute information may be information about a self-describing attribute registered in a self-describing attribute identifier list. The first attribute information may include the identifier of the self-describing attribute, such as the name and number of the self-describing attribute. The self-describing attribute identifier list may be a list used to store the identifiers of self-describing attributes. The self-describing attribute identifier list may be a list globally maintained by a database.

[0076] Specifically, the self-describing attribute is parsed to obtain the first attribute information of the self-describing attribute, and the first attribute information is registered in the corresponding position in the self-describing attribute identifier list.

[0077] S3202. Register the second attribute information of the self-describing attribute in the self-describing attribute list. The second attribute information includes the first attribute information, the data type of the self-describing attribute, and the visibility information of the self-describing attribute.

[0078] In this embodiment, the second attribute information may be information about a self-describing attribute registered in a self-describing attribute list. The second attribute information may include first attribute information, the data type of the self-describing attribute, and visibility information of the self-describing attribute. Visibility information may indicate whether the self-describing attribute is visible to the user. The self-describing attribute list may be a list used to store the second attribute information. The self-describing attribute list may be a list maintained globally by a database.

[0079] Specifically, the self-describing attribute is parsed to obtain the second attribute information of the self-describing attribute, and the second attribute information is registered in the self-describing attribute list.

[0080] In one embodiment, storing the information of the self-describing attribute in a metadata file includes: The number of self-describing attributes is recorded in the fixed-length attribute of the metadata file, and the information of the self-describing attributes is registered in a serialized manner at the end of the variable-length attribute.

[0081] In this embodiment, a fixed-length attribute can be a region of fixed length in the metadata file. A variable-length attribute can be a region of variable length located after the region of the fixed-length attribute in the metadata file. Variable-length attributes can store extended information about the data.

[0082] Specifically, the number of self-descriptive attributes updated this time is recorded in the fixed-length attribute of the metadata file, and the specific information of the self-descriptive attributes is stored in a structured manner at the end of the variable-length attribute in a certain order.

[0083] For example, Figure 4This is a schematic diagram of the structure of a metadata file provided by an embodiment of the present invention. Before optimization, the metadata file includes a backup set header and file headers of multiple data files, wherein the file headers of the data files include fixed-length attributes and variable-length attributes. After optimization, the file headers of the data files can store the number of self-descriptive attributes updated this time and the specific information of each self-descriptive attribute, wherein the specific information of each self-descriptive attribute includes the length of the specific information, the attribute number (i.e., ID), the data type of the attribute value, the length of the attribute name, the name of the attribute, the length of the attribute value, and the attribute value.

[0084] The present invention will be described by way of example below: This invention proposes a method for optimizing backup set compatibility, comprising: Self-describing attributes are introduced. Attributes unrelated to library data parsing are stored as self-describing attributes in the backup set. Self-describing attributes include fields such as data length, attribute name, attribute ID, and data type. A global list of self-describing attribute IDs (i.e., a list of self-describing attribute identifiers) and a global list of self-describing attributes are maintained. When a new self-describing attribute is added, the self-describing attribute ID is added synchronously, and the corresponding information is added to the self-describing attribute list. Newly added self-describing attributes can be correctly parsed even with older versions of the executable code, avoiding frequent version upgrades. A backup set sub-version list is introduced. When adding an attribute changes the storage format of the backup set, a corresponding backup set sub-version number is added to the backup set sub-version list. A backup set data version list is introduced. When a new attribute affects the parsing of library data in the backup set, a corresponding backup set data version number is added to the backup set data version list. Backup set version information is dynamically generated. The backup set version information is no longer set to a globally maintained version number but is dynamically set based on the specific content stored in the backup set. When adding an attribute causes a change in the storage format of the backup set or the parsing method of the library data, a corresponding backup set sub-version number and backup set data version number are added. When a backup set needs to store attributes that have been changed, the version number of the backup set sub-set or the backup set data version number corresponding to that change is set to the backup set. Backup set compatibility control is improved; backup and restore operations accessing database data now include compatibility checks for backup set data versions.

[0085] Compared to traditional backup set compatibility judgment methods, the backup set compatibility optimization method proposed in this invention adds self-describing attributes, a backup set sub-version list, and a backup set data version list. If new attributes are added to the database file that do not affect data parsing, these new attributes will be stored as self-describing attributes in the metadata file during backup, and can be directly read from it when parsing the backup set. If new attributes are added to the database file that affect data parsing or cause changes to the storage format of the backup set, version control is performed on these new attributes using the backup set sub-version list and the backup set data version list. During parsing, the compatibility between the executable code and the backup set is determined based on the backup set sub-version and backup set data version.

[0086] In one example, self-describing attributes include: if new attributes are added to the database file that do not affect data parsing, these new attributes will be stored as self-describing attributes in the metadata file when backing up the database files. The information that needs to be recorded includes: the number of self-describing attributes, and the specific information for each self-describing attribute (length of this information, attribute ID, data type of the attribute value, length of the attribute name, attribute name, length of the attribute value, and attribute value). Furthermore, the database system needs to maintain two global lists: a self-describing attribute ID list and a self-describing attribute list. The self-describing attribute ID list records the attribute name and attribute ID (i.e., the first attribute information), while the self-describing attribute list records the attribute name, attribute ID, data type of the attribute value, and whether it is visible to the user (i.e., the second attribute information). When new attributes that do not affect data parsing are added to the database file, the database system will register the new attribute information in both the self-describing attribute ID list and the self-describing attribute list. When parsing the backup set, the self-describing attributes are read sequentially from the metadata file in a deserialized manner according to their number.

[0087] For example, taking a data file as an example, if three new attributes are added to the data file that do not affect data parsing, the following operations need to be performed: First, the database system will register the newly added attribute information in the self-describing attribute ID list and the self-describing attribute list; during the backup operation, these three attributes will be stored in the metadata file as self-describing attributes. The storage method can be to record the number of self-describing attributes in fixed-length attributes, and to register the specific information of each self-describing attribute in a serialized manner at the end of variable-length attributes (the length of this specific information, attribute ID, data type of the attribute value, length of the attribute name, attribute name, length of the attribute value, and attribute value).

[0088] In one example, the backup set sub-version list includes: a global backup set sub-version list maintained by the database system, with the original backup set sub-version number serving as the smallest backup set version number in the backup set version list; if an attribute is added to the database file that would change the storage format of the backup set, a corresponding backup set version number is added, and the backup set version numbers are incremented sequentially.

[0089] In one example, the backup set data version list includes: a global backup set data version list maintained by the database system, with 0 as the smallest backup set data version number in the list. If an attribute that affects data parsing is added to the database file, a corresponding backup set data version number is added, and the backup set data version numbers are incremented sequentially.

[0090] In one example, the process of dynamically generating backup set versions includes: During backup operations, the backup set sub-version number and backup set data version number are dynamically set based on the actual data stored in the backup set. The process is as follows: Set the default backup set version information (i.e., the default backup set sub-version number and the default backup set data version number). The backup set sub-version number and the backup set data version number are set to the minimum values ​​in the backup set sub-version list and the backup set data version number, respectively. Check the backup set sub-version numbers sequentially according to their order. If the backup set contains attributes that cause a change in the backup set's storage format, upgrade the backup set sub-version number to the sub-version number corresponding to that change (i.e., the target sub-version number). Check the backup set data version numbers sequentially according to their order. If the backup set contains attributes that affect data parsing, upgrade the backup set data version number to the data version number corresponding to that change (i.e., the target data version number). Once the backup set version information is set (i.e., the target sub-version number and the target data version number are determined as the version information of the current backup set), write it to the metadata file.

[0091] In one example, the compatibility check method includes: The compatibility check strategy for the major version number of the backup set remains unchanged. If the major version number of the executable code and the backup set are exactly the same, they are considered compatible; otherwise, they are incompatible (i.e., the major version number of the current backup set is checked against the major version number of the executable code to determine the major version number check result). If the sub-version number of the backup set is greater than or equal to the maximum value in the list of sub-versions of the executable code, it is considered incompatible; otherwise, it is compatible (i.e., the target sub-version number of the current backup set is checked against the maximum value in the list of sub-versions of the backup set to determine the sub-version number check result). If the data version number of the backup set is greater than or equal to the maximum value in the list of data versions of the executable code, it is considered incompatible; otherwise, it is compatible (i.e., the target data version number of the current backup set is checked against the maximum value in the list of data versions of the backup set to determine the data version number check result). Different backup set operations (i.e., operation types) have different compatibility requirements (i.e. target check results) between the executable code and the backup set. For example, operations such as displaying backup set information (SHOW BACKUPSET) require the executable code to be compatible with the main version number and sub-version number of the backup set. Operations involving data parsing, such as data restoration (RESTORE), require the executable code to be compatible with the main version number, sub-version number, and data version number of the backup set.

[0092] Example 3 Figure 5 This is a schematic diagram of a backup set version determination device in a database provided in Embodiment 3 of the present invention. Figure 5 As shown, the device includes: The acquisition module 510 is used to acquire a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated. The first determining module 520 is used to determine the default backup set sub-version number of the current backup set based on the backup set sub-version number in the backup set sub-version list, and to determine the default backup set data version number of the current backup set based on the backup set data version number in the backup set data version list. The second determining module 530 is used to sequentially check the backup set sub-version list. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it does not include an attribute, then the default backup set version number is determined as the target sub-version number. The third determining module 540 is used to sequentially check the backup set data version list. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it does not include an attribute, then the default backup set data version number is determined as the target data version number. Storage module 550 is used to determine the target sub-version number and the target data version number as the version information of the current backup set, and store the version information in a metadata file.

[0093] The technical solution of this invention involves an acquisition module obtaining a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number added when an attribute causing a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number added when an attribute affecting data parsing is updated. A first determining module determines the default backup set sub-version number of the current backup set based on the backup set version numbers in the backup set sub-version list, and determines the default backup set data version number of the current backup set based on the backup set data version numbers in the backup set data version list. A second determining module sequentially checks the backup set version list. If the attribute corresponding to the backup set version number includes... If an attribute causes a change in the storage format of the current backup set, the backup set sub-version number is determined as the target sub-version number of the current backup set. If the attribute does not include the attribute, the default backup set sub-version number is determined as the target sub-version number. The third determining module sequentially checks the backup set data version list. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, the backup set data version number is determined as the target data version number of the current backup set. If the attribute does not include the attribute, the default backup set data version number is determined as the target data version number. The storage module determines the target sub-version number and the target data version number as the version information of the current backup set and stores the version information in the metadata file. The technical solution of this embodiment of the invention, through the backup set sub-version list, can maintain the backup set sub-version number when the storage format of the backup set changes due to the addition of attributes. The storage format can be independently iterated and upgraded without affecting the data parsing version. Through the backup set data version list, the backup set data version number corresponding to the parsing of data in the backup set when a new attribute is added can also be maintained. By setting the default backup set sub-version number and the default backup set data version number, it is possible to ensure that all backup sets have available version information, thus avoiding meaningless version number inflation.

[0094] In one embodiment, the version update process of the backup set includes: The attribute retrieval module is used to retrieve newly added attributes in the backup set; The self-describing attribute determination module is used to determine the attribute as a self-describing attribute if the attribute includes attributes that do not affect data parsing, register the self-describing attribute, and store the information of the self-describing attribute in a metadata file; The first adding module is used to add the backup set data version number corresponding to the attribute to the backup set data version list if the attribute includes an attribute that affects data parsing. The second adding module is used to add the backup set sub-version number corresponding to the attribute to the backup set version list if the attribute includes an attribute that causes a change in the backup set storage format.

[0095] In one embodiment, the self-describing attribute determination module is specifically used for: The first attribute information of the self-describing attribute is registered in the self-describing attribute identifier list, wherein the first attribute information includes the identifier of the self-describing attribute; The second attribute information of the self-describing attribute is registered in the self-describing attribute list. The second attribute information includes the first attribute information, the data type of the self-describing attribute, and the visibility information of the self-describing attribute.

[0096] In one embodiment, the self-describing attribute determination module is specifically used for: The number of self-describing attributes is recorded in the fixed-length attribute of the metadata file, and the information of the self-describing attributes is registered in a serialized manner at the end of the variable-length attribute.

[0097] In one embodiment, the compatibility check method for the current backup set includes: The first checking module is used to check whether the main version number of the current backup set is consistent with the main version number of the executable code, and to determine the main version number check result. The second checking module is used to check whether the target sub-version number of the current backup set is less than the maximum value in the sub-version list of the backup set, and to determine the sub-version number check result. The third checking module is used to check whether the target data version number of the current backup set is less than the maximum value of the backup set data version list, and to determine the data version number check result. The compatibility result determination module is used to determine the compatibility result based on the main version number check result, the sub-version number check result, and the data version number check result. The compatibility result includes whether the version of the current backup set is compatible with the version of the executable code.

[0098] In one embodiment, the compatibility result determination module is specifically used for: Based on the type of operation performed on the current backup set, a target check result is determined, the target check result including one or more of the major version number check result, the sub-version number check result, and the data version number check result; If all the target check results meet the preset conditions, the compatibility result indicates that the version of the current backup set is compatible with the version of the executable code.

[0099] The backup set version determination device provided in this embodiment of the invention can execute the backup set version determination method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0100] Example 4 Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0101] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0102] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0103] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the methods proposed in this invention.

[0104] In some embodiments, the method proposed in this invention can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the method proposed in this invention by any other suitable means (e.g., by means of firmware).

[0105] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0106] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this invention, a computer-readable storage medium stores computer instructions that are used to cause a processor to execute and implement the method provided by this invention.

[0108] The present invention also provides a computer program product comprising a computer program that, when executed by a processor, implements the method provided according to embodiments of the present invention.

[0109] Computer-readable storage media can be tangible media that may contain or store computer programs for use by or in conjunction with an instruction execution system, apparatus, or device. Computer-readable storage media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0110] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user, such as a cathode ray tube (CRT) or a liquid crystal display (LCD); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0111] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0112] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0113] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0114] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for determining the version of a backup set in a database, characterized in that, include: Obtain a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated. Based on the backup set sub-version number in the backup set sub-version list, determine the default backup set sub-version number of the current backup set; based on the backup set data version number in the backup set data version list, determine the default backup set data version number of the current backup set. The backup set sub-version list is checked sequentially. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it does not include an attribute, then the default backup set version number is determined as the target sub-version number. The backup set data version list is checked sequentially. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it does not include an attribute, then the default backup set data version number is determined as the target data version number. The target sub-version number and the target data version number are determined as the version information of the current backup set, and the version information is stored in the metadata file.

2. The method according to claim 1, characterized in that, The version update process of the backup set includes: Retrieve newly added attributes from the backup set; If the attribute includes an attribute that does not affect data parsing, then the attribute is identified as a self-describing attribute, the self-describing attribute is registered, and the information of the self-describing attribute is stored in the metadata file; If the attribute includes an attribute that affects data parsing, then add the backup set data version number corresponding to the attribute to the backup set data version list; If the attribute includes an attribute that causes a change in the backup set storage format, then the backup set sub-version number corresponding to the attribute is added to the backup set version list.

3. The method according to claim 2, characterized in that, The registration of the self-descriptive attributes includes: The first attribute information of the self-describing attribute is registered in the self-describing attribute identifier list, wherein the first attribute information includes the identifier of the self-describing attribute; The second attribute information of the self-describing attribute is registered in the self-describing attribute list. The second attribute information includes the first attribute information, the data type of the self-describing attribute, and the visibility information of the self-describing attribute.

4. The method according to claim 2, characterized in that, The step of storing the information of the self-describing attribute in a metadata file includes: The number of self-describing attributes is recorded in the fixed-length attribute of the metadata file, and the information of the self-describing attributes is registered in a serialized manner at the end of the variable-length attribute.

5. The method according to any one of claims 1-4, characterized in that, The compatibility check method for the current backup set includes: Check whether the major version number of the current backup set is consistent with the major version number of the executable code, and determine the major version number check result; Check whether the target sub-version number of the current backup set is less than the maximum value in the sub-version list of the backup set, and determine the sub-version number check result; Check whether the target data version number of the current backup set is less than the maximum value of the backup set data version list, and determine the data version number check result; The compatibility result is determined based on the main version number check result, the sub-version number check result, and the data version number check result. The compatibility result includes whether the version of the current backup set is compatible with the version of the executable code.

6. The method according to claim 5, characterized in that, The step of determining the compatibility result based on the major version number check result, the sub-version number check result, and the data version number check result includes: Based on the type of operation performed on the current backup set, a target check result is determined, the target check result including one or more of the major version number check result, the sub-version number check result, and the data version number check result; If all the target check results meet the preset conditions, the compatibility result indicates that the version of the current backup set is compatible with the version of the executable code.

7. A device for determining the version of a backup set in a database, characterized in that, include: The acquisition module is used to acquire a backup set sub-version list and a backup set data version list. The backup set sub-version list includes the backup set sub-version number that is added when an attribute that causes a change in the backup set storage format is updated. The backup set data version list includes the backup set data version number that is added when an attribute that affects data parsing is updated. The first determining module is used to determine the default backup set sub-version number of the current backup set based on the backup set sub-version number in the backup set sub-version list, and to determine the default backup set data version number of the current backup set based on the backup set data version number in the backup set data version list. The second determining module is used to sequentially check the backup set sub-version list. If the attribute corresponding to the backup set sub-version number includes an attribute that causes the storage format of the current backup set to change, then the backup set sub-version number is determined as the target sub-version number of the current backup set. If it does not include an attribute, then the default backup set version number is determined as the target sub-version number. The third determining module is used to sequentially check the backup set data version list. If the attribute corresponding to the backup set data version number includes an attribute that affects the data parsing of the current backup set, then the backup set data version number is determined as the target data version number of the current backup set. If it does not include an attribute, then the default backup set data version number is determined as the target data version number. The storage module is used to determine the target sub-version number and the target data version number as the version information of the current backup set, and store the version information in a metadata file.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the method of any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images