MySQL data backup method and device based on block chain and readable medium

Abstract

The invention discloses a MySQL data backup method and device based on a block chain and a readable medium, and the method comprises the steps: segmenting the size of an MYD file corresponding to each data table in a MySQL database according to a fixed segmentation unit to obtain a plurality of storage unit files, and sequentially numbering file names of the storage unit files, obtaining a storage unit file set of each data table, and storing the storage unit file sets of all the data tables on each node of the block chain; obtaining all related storage unit files from the storage unit file set according to the name of the file to be written, and when all related storage unit files exist and form a first file list, writing the file to be written into the first file list, and determining a file name of a target storage unit file corresponding to the to-be-written file in the first file list according to the original offset pointer of the to-be-written file, and writing the to-be-written file based on the target storage unit file. According to the invention, the probability of misoperation caused by human factors can be reduced, and the security of data is improved.

Description

Technical Field

[0001] The present invention relates to the field of data backup, and particularly to a MySQL data backup method, device and readable medium based on blockchain. Background Art

[0002] With the development of computer technology and Internet technology, MySQL, as one of the most popular database products, occupies a considerable market share. One of the most core capabilities of a database is the robustness and security of data storage. As long as data is stored on physical media, there is a risk of data anomalies caused by external force majeure such as physical hard disk damage, power problems or natural disasters, which poses a challenge to the persistent preservation of data. Therefore, MySQL data backup is an important measure to ensure data security, meet business requirements and regulatory requirements. Regular backup and testing of backup recovery capabilities are key practices in database management and maintenance.

[0003] Conventional backups are mainly divided into logical backups and physical backups.

[0004] Logical backup refers to exporting the logical structure and data of a database, usually manifested as a set of SQL files. These files contain the SQL statements required to reconstruct the database structure (such as tables, indexes, views, stored procedures, etc.) and the INSERT statements to populate the table data. The advantage of logical backup is that it provides flexibility for cross-platform migration, official tools are provided, and the backup SQL files are human-readable, facilitating data review and adjustment. Logical backup has the following problems:

[0005] 1. In an actual production environment, the data volume of a database is usually not too low, and the time cost of using logical backup is relatively large.

[0006] 2. For some machines with relatively poor hardware performance, logical backup often fails to run due to hardware resource problems, and ultimately fails to achieve the purpose of backup.

[0007] Physical backup refers to directly copying database files for backup, which can restore the original state of the database to the greatest extent, including table structure, indexes, triggers, etc. Physical backup is usually used in scenarios with large data volumes and high requirements for data consistency, such as production environments. The advantages of physical backup are its high execution efficiency, strong restoration ability, and the ability to reduce database downtime. Physical backup has the following problems:

[0008] 1. Physical backup is not the native recommended practice of MySQL, and the official does not provide automated tools.

[0009] 2. The most crucial point is that a large amount of manual intervention is required, which has high requirements for personnel and also generates a lot of uncertainties.

[0010] 3. The backup storage hard disk requires manual maintenance at regular intervals, and the system needs to be shut down when replacing backup hardware, which greatly affects the backup efficiency.

[0011] According to industry practices, in an actual production environment, when the data volume of the database reaches more than 50 GB, the probability of logical backup failure is relatively high, and the backup purpose cannot be achieved. The preferred choice for operation and maintenance personnel is still physical backup, but the above problems with physical backup lead to significant risks in operation. Summary of the Invention

[0012] The purpose of this application is to propose a blockchain-based MySQL data backup method, device, and readable medium for the above-mentioned technical problems.

[0013] In the first aspect, the present invention provides a blockchain-based MySQL data backup method, including the following steps:

[0014] Divide the size of the MYD file corresponding to each data table in the MySQL database according to a fixed segmentation unit to obtain a number of storage unit files, and sequentially number them in the file name of the storage unit file to obtain the storage unit file set of each data table, and store the storage unit file sets of all data tables on each node of the blockchain;

[0015] Obtain the file to be written, its name, and the original offset pointer. The offset pointer is the number of bytes between the current operation position and the beginning of the file. Obtain all relevant storage unit files from the storage unit file set according to the name of the file to be written. In response to determining that all relevant storage unit files exist and form a first file list, determine the file name of the target storage unit file corresponding to the file to be written in the first file list according to the original offset pointer of the file to be written, write the file to be written based on the target storage unit file, and obtain the adjusted offset pointer of the file to be written;

[0016] In response to determining that there is a changed file in the storage unit file set, record the physical storage path and change type of the changed file. In response to the change type being modification, set the change type of the modified file to addition and the change type of the file before modification to deletion. In response to the change type being addition, upload the changed file or the modified file to the blockchain through the blockchain protocol, generate the unique identifier of the changed file on the blockchain, and map it to the physical storage path of the changed file to obtain the mapping relationship. In response to the change type being deletion, unbind and recycle the changed file or the file before modification.

[0017] Preferably, the file name of the storage unit file is X.n.MYD, where X represents the name, n represents the number, and the numbers of the storage unit files in the storage unit file set are consecutive natural numbers from 0 to N.

[0018] Preferably, the file name of the target storage unit file corresponding to the file to be written is determined in the first file list according to the offset pointer of the file to be written, the file to be written is written based on the target storage unit file, and the offset pointer of the file to be written is adjusted, specifically including:

[0019] Determine that the fixed segmentation unit of the MYD file is M bytes, and the numbers of the storage unit files in the first file list are consecutive natural numbers from 0 to N 1 ;

[0020] Calculate the number of the storage unit file corresponding to the file to be written by using the following formula:

[0021]

[0022] where x 1 represents the original offset pointer of the file to be written, y 1 represents the number of the storage unit file corresponding to the file to be written, represents rounding down;

[0023] In response to determining that there is a storage unit file with the number y 1 in the first file list, if the size of the file to be written does not exceed the reserved space in the storage unit file with the number y 1 , then use the storage unit file with the number y 1 as the target storage unit file corresponding to the file to be written, determine the file name of the target storage unit file corresponding to the file to be written, and adjust the offset pointer of the file to be written by the following formula:

[0024] x 1 ′ = x 1 - y 1 * M;

[0025] where x 1 ′ represents the adjusted offset pointer of the file to be written;

[0026] If the size of the file to be written exceeds the reserved space in the storage unit file with the number y 1 , then use the storage unit file with the number N 1 as the target storage unit file corresponding to the file to be written, determine the file name of the target storage unit file corresponding to the file to be written, and the adjusted offset pointer is the number N 1The next position after the position of the last stored file in the storage unit file;

[0027] When the size of the file to be written exceeds the boundary of the storage unit file numbered N 1 New storage unit files are added sequentially;

[0028] Start writing the file to be written from the position of the offset pointer adjusted from the beginning of the target storage unit file;

[0029] In response to determining that there is no storage unit file numbered y in the first file list 1 New storage unit files are added sequentially in the first file list until a storage unit file numbered y 1 is created, and the above process is repeated;

[0030] In response to determining that there are no all relevant storage unit files to form the first file list, create a storage unit file numbered 0 and empty as the target storage unit file corresponding to the file to be written.

[0031] Preferably, it further includes:

[0032] Obtain the name and offset pointer of the file to be read, obtain all relevant storage unit files in the storage unit file set according to the name of the file to be read, and form a second file list;

[0033] Determine the file name of the target storage unit file corresponding to the file to be read according to the offset pointer of the file to be read in the second file list, and perform reading based on the file name of the target storage unit file to obtain the file to be read.

[0034] Preferably, determining the file name of the target storage unit file corresponding to the file to be read according to the offset pointer of the file to be read in the second file list, and performing reading based on the file name of the target storage unit file to obtain the file to be read, specifically includes:

[0035] Determine that the fixed segmentation unit of the MYD file is M bytes, and the numbers of the storage unit files in the first file list are consecutive natural numbers from 0 to N 2 ;

[0036] Calculate the number of the storage unit file corresponding to the file to be read by using the following formula:

[0037]

[0038] where x 2 represents the original offset pointer of the file to be read, y 2 represents the number of the storage unit file corresponding to the file to be read, Denote floor division;

[0039] Take the storage unit file numbered y 2 as the target storage unit file corresponding to the file to be read, and adjust the offset pointer of the file to be read through the following formula:

[0040] x ′ 2 = x 2 - y 2 * M;

[0041] where, x ′ 2 represents the adjusted offset pointer of the file to be read;

[0042] Start reading from the position offset by the adjusted offset pointer from the beginning of the target storage unit file to obtain the file to be read.

[0043] Preferably, it further includes: if the adjusted offset pointer of the file to be read is located at the last position of the storage unit file numbered y 2 then take the storage unit file numbered y 2 + 1 as the target storage unit file corresponding to the file to be read, and the adjusted offset pointer of the file to be read is 0, start reading from the position offset by the adjusted offset pointer from the beginning of the target storage unit file to obtain the file to be read.

[0044] In a second aspect, the present invention provides a MySQL data backup device based on a blockchain, including:

[0045] A data splitting module, configured to split the size of each MYD file corresponding to each data table in the MySQL database according to a fixed splitting unit to obtain a number of storage unit files, and sequentially number them in the file names of the storage unit files to obtain a set of storage unit files for each data table, and store the set of storage unit files for all data tables on each node of the blockchain;

[0046] A writing module, configured to obtain the file to be written, its name and offset pointer, where the offset pointer is the number of bytes between the current operation position and the beginning of the MYD file, obtain all relevant storage unit files from the set of storage unit files according to the name of the file to be written, in response to all relevant storage unit files being able to form a first file list, determine the file name of the target storage unit file corresponding to the file to be written in the first file list according to the offset pointer of the file to be written, write the file to be written based on the target storage unit file, and adjust the offset pointer of the file to be written;

[0047] The on-chain update module is configured to record the physical storage path and change type of a changed file in response to determining that there is a changed file in the set of storage unit files. In response to the change type being modification, the change type of the modified file is set to addition, and the change type of the file before modification is set to deletion. In response to the change type being addition, the changed file or the modified file is uploaded to the blockchain through the blockchain protocol, and a unique identifier of the changed file on the blockchain is generated and mapped to the physical storage path of the changed file to obtain a mapping relationship. In response to the change type being deletion, the changed file or the file before modification is unbound and recycled.

[0048] In a third aspect, the present invention provides an electronic device, including one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method described in any implementation manner of the first aspect.

[0049] In a fourth aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method described in any implementation manner of the first aspect is implemented.

[0050] In a fifth aspect, the present invention provides a computer program product, including a computer program, and when the computer program is executed by a processor, the method described in any implementation manner of the first aspect is implemented.

[0051] Compared with the prior art, the present invention has the following beneficial effects:

[0052] (1) The blockchain-based MySQL data backup method of the present invention enables incremental backup in physical backup by splitting MYD files, while improving backup efficiency, reducing the hard disk space overhead in backup and the bandwidth consumption in network transmission, and helping to improve transmission efficiency.

[0053] (2) The blockchain-based MySQL data backup method of the present invention automatically synchronizes storage unit files according to the blockchain protocol, eliminating incorrect operations caused by manual intervention and ensuring the correct execution of the process. After cutting the storage unit files, only the storage unit files with changed data can be selected for backup during backup, without the need for global backup. For a system, continuous backup can effectively reduce the probability of data rollback or data loss, but more frequent backups will impose an additional burden on the system. The present invention can synchronize only the smallest storage unit files, thereby greatly reducing the backup cost of the system on the premise of ensuring the backup frequency.

[0054] (3) The blockchain-based MySQL data backup method of the present invention utilizes the characteristics of blockchain distributed storage, which is not easily tampered with, to increase the security of database files, enhance its disaster tolerance ability, and more effectively protect data, solving the difficult problem of heavy physical backup for operation and maintenance personnel. It can be effectively applied in some production environments where zero tolerance for data loss is required. Based on the characteristics of the blockchain, it is also easy to perform shutdown maintenance and hardware replacement on the backup storage machine. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0056] Figure 1 It is a flowchart of the blockchain-based MySQL data backup method according to the embodiment of the present application;

[0057] Figure 2 It is a schematic diagram of the blockchain-based MySQL data backup device according to the embodiment of the present application;

[0058] Figure 3 It is a schematic diagram of the hardware structure of the electronic device provided by the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] In order to make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art without creative efforts based on the embodiments of the present invention belong to the scope of protection of the present invention.

[0060] Figure 1 There is shown a blockchain-based MySQL data backup method provided by the embodiment of the present application, including the following steps:

[0061] S1, divide the size of each MYD file corresponding to each data table in the MySQL database according to a fixed segmentation unit to obtain a number of storage unit files, and sequentially number them in the file names of the storage unit files to obtain a set of storage unit files for each data table, and store the set of storage unit files for all data tables on each node of the blockchain.

[0062] In a specific embodiment, the file name of the storage unit file is X.n.MYD, where X represents the name, n represents the number, and the numbers of the storage unit files in the storage unit file set are consecutive natural numbers from 0 to N.

[0063] Specifically, the files under the MyISAM engine of an original MySQL database are divided into three parts: frm files, MYD files, and MYI files. The frm file describes the static table structure, indexes, and other metadata of the data table. The MYI file stores real-time index information, and the MYD file stores the specific data table. Among them, the frm file and the MYI file are both very small and do not need to be split. After a normal data table is generated, unless the business changes, the file content will not change. Even when there are changes, the overhead of a full backup is negligible. However, as the basic unit of data storage, the size of the MYD file depends on the size of the data table. If the entire MYD file is directly backed up, for large data tables, it not only causes waste of time cost and network transmission cost, but also reduces the efficiency of the entire backup.

[0064] Therefore, the embodiments of the present application perform the following processing on the MYD file:

[0065] 1. Divide the file size of the MYD file with M as the fixed division unit.

[0066] 2. After division, add a number to the file name to locate the file pointer offset addressing.

[0067] S2. Obtain the file to be written, its name, and the original offset pointer. The offset pointer is the number of bytes between the current operation position and the beginning of the file. Obtain all relevant storage unit files in the storage unit file set according to the name of the file to be written. In response to determining that all relevant storage unit files exist and form a first file list, determine the file name of the target storage unit file corresponding to the file to be written in the first file list according to the original offset pointer of the file to be written. Write the file to be written based on the target storage unit file, and obtain the adjusted offset pointer of the file to be written.

[0068] In a specific embodiment, determining the file name of the target storage unit file corresponding to the file to be written in the first file list according to the offset pointer of the file to be written, writing the file to be written based on the target storage unit file, and adjusting the offset pointer of the file to be written specifically includes:

[0069] Determine that the fixed division unit of the MYD file is M bytes, and the numbers of the storage unit files in the first file list are consecutive natural numbers from 0 to N 1 ;

[0070] Calculate the number of the storage unit file corresponding to the file to be written using the following formula:

[0071]

[0072] where x 1 represents the original offset pointer of the file to be written, and y 1 represents the number of the storage unit file corresponding to the file to be written, represents rounding down;

[0073] In response to determining that there is a storage unit file with the number y 1 in the first file list, if the size of the file to be written does not exceed the reserved space in the storage unit file with the number y 1 , then use the storage unit file with the number y 1 as the target storage unit file corresponding to the file to be written, determine the file name of the target storage unit file corresponding to the file to be written, and adjust the offset pointer of the file to be written using the following formula:

[0074] x 1 ′ = x 1 - y 1 * M;

[0075] where x 1 ′ represents the adjusted offset pointer of the file to be written;

[0076] If the size of the file to be written exceeds the reserved space in the storage unit file with the number y 1 , then use the storage unit file with the number N 1 as the target storage unit file corresponding to the file to be written, determine the file name of the target storage unit file corresponding to the file to be written, and the adjusted offset pointer is the next position after the position of the last stored file in the storage unit file with the number N 1 ;

[0077] When the size of the file to be written exceeds the boundary of the storage unit file with the number N 1 , sequentially add new storage unit files;

[0078] Start writing the file to be written from the position offset by the adjusted offset pointer from the beginning of the target storage unit file;

[0079] In response to determining that there is no storage unit file with the number y 1 in the first file list, then sequentially add new storage unit files in the first file list until a storage unit file with the number y 1 is created, and repeat the above process;

[0080] In response to determining that all relevant storage unit files do not exist and forming a first file list, a storage unit file numbered 0 and empty is created as the target storage unit file corresponding to the file to be written.

[0081] In one embodiment, taking the database name as Database and the data table name as Table as an example, describe how to perform data reading and writing.

[0082] When there is a writing requirement, the process is as follows:

[0083] S21, the storage engine prepares to write data;

[0084] S22, look for the MYD file with the corresponding file name under the database storage directory. Assume the database installation directory is

[0085] D:\MySQL. If there is no special modification, the data table named Table is usually placed at the physical storage path D:\MySQL\data\Database. Use the MySQL API to find the storage unit file named Table.n 1 .MYD in the database storage directory to form a first file list, where n 1 is a consecutive natural number from 0 to N 1 .

[0086] S23, determine whether there are storage unit files with file names from Table.0.MYD to Table.N 1 .MYD in the first file list. It must be ensured that the numbers from 0 to N 1 are consecutive natural numbers.

[0087] S24, when the first file list in step S23 does not exist, at this time, a storage unit numbered 0 and empty needs to be created as the file carrier medium for the first data landing, creating sufficient conditions for subsequent data to be written into the MYD file.

[0088] S25, when the first file list in step S23 exists, with the split interval M = 10485760KB of the MYD file, if the original offset pointer of the file to be written is x 1 , the original offset pointer is the offset pointer used before the MYD file is split. Substitute it into the following formula: For example: If the calculation result of... is 5.567, take the integer part downwards, then the file to be written y 1 is 5. So the file name of the storage unit file corresponding to the file to be written is Table.5.MYD.

[0089] S26, when the storage unit file named Table.5.MYD does not exist in the first file list, the storage unit file named Table.5.MYD cannot be modified because the storage unit file named Table.5.MYD does not exist. At this time, it is necessary to refer to the formula of step S25 to calculate the number, create a storage unit file with the corresponding number for data to be stored on the disk, and follow the process to step S27 after the creation is completed.

[0090] S27, when there is a storage unit file named Table.5.MYD in the first file list, or in the subsequent steps of step S24 and step S26, the storage unit file named Table.5.MYD can be opened using the MySQL API, the file to be written is handed over to the storage unit file named Table.5.MYD, and the position of the offset pointer is adjusted. The formula for adjusting the offset pointer is as follows: 1 ′ =x 1 -y 1 *M.x 1 ′ is the adjusted offset pointer of the file to be written, and the adjusted offset pointer is the number of bytes between the current operation position and the beginning of the storage unit file named Table.5.MYD. The adjusted offset pointer can be directly written into the binary file to complete the disk write operation of the file to be written. The embodiment of the present application is optimized for high-speed writing. When writing in the middle, once the file size of the file to be written exceeds the reserved space of the storage unit file of Table.5.MYD, the adjusted offset pointer of the file to be written will be offset to the end of all files stored in the first file list, and there is no need to process the overall data extension operation for subsequent files. It will jump directly to the last storage unit file stored in the first file list for writing. When the file size of the file to be written exceeds the boundary of the last storage unit file, it is necessary to append a sequentially extended number to receive the remaining data write, such as a newly added number N. 1 +1, N 1 +2, N 1 +3 etc. storage unit files.

[0091] As shown in Table 1, the data stored in the storage unit file of Table 5.MYD is as shown in the first row, where columns E and F are reserved spaces. When the files to be written are 15 and 16, since 15 and 16 are less than or equal to the reserved space of Table 5.MYD, they will be filled in the positions of columns E and F, and the stored content of the file after filling is as shown in the second row. If the length of the file to be written is greater than the reserved space, it will be appended to the end of the first file list. As shown in the third row, three columns, namely column I, column J, and column K, are appended after column H at the end of the last storage unit file in the first file list, and 15, 16, and 17 are written respectively.

[0092] Table 1

[0093] Serial number A B C D E G H I J K 1 11 12 13 14 - 20 21 - - - 2 11 12 13 14 15 20 21 - - - 3 11 12 13 14 - 20 21 15 16 17

[0094] In a specific embodiment, it further includes:

[0095] Obtain the name and offset pointer of the file to be read, and obtain all relevant storage unit files from the set of storage unit files according to the name of the file to be read, and form a second file list;

[0096] Determine the file name of the target storage unit file corresponding to the file to be read in the second file list according to the offset pointer of the file to be read, and perform reading based on the file name of the target storage unit file to obtain the file to be read.

[0097] In a specific embodiment, determining the file name of the target storage unit file corresponding to the file to be read in the second file list according to the offset pointer of the file to be read, and performing reading based on the file name of the target storage unit file to obtain the file to be read specifically includes:

[0098] Determine that the fixed segmentation unit of the MYD file is M bytes, and the numbers of the storage unit files in the first file list are consecutive natural numbers from 0 to N 2 ;

[0099] Use the following formula to calculate the number of the storage unit file corresponding to the file to be read:

[0100]

[0101] where x 2 represents the original offset pointer of the file to be read, y 2 represents the number of the storage unit file corresponding to the file to be read, represents rounding down;

[0102] Take the storage unit file numbered y 2 as the target storage unit file corresponding to the file to be read, and adjust the offset pointer of the file to be read through the following formula:

[0103] x ′ 2 = x 2 - y 2 * M;

[0104] Wherein, x ′ 2 represents the adjusted offset pointer of the file to be read;

[0105] Start reading from the position of the adjusted offset pointer offset from the beginning of the target storage unit file to obtain the file to be read.

[0106] In a specific embodiment, it further includes: if the adjusted offset pointer of the file to be read is located at the last position of the storage unit file numbered y 2 then use the storage unit file numbered y 2 + 1 as the target storage unit file corresponding to the file to be read, and the adjusted offset pointer of the file to be read is 0. Start reading from the position of the adjusted offset pointer offset from the beginning of the target storage unit file to obtain the file to be read.

[0107] Specifically, when there is a reading requirement, the process is as follows:

[0108] S31, the storage engine prepares to read data.

[0109] S32, taking the name of the data table as Table as an example, query all file names Table.n 2 .MYD files under the folder stored in the database through the MySQL system, where n 2 is a consecutive natural number from 0 to N 2 .

[0110] S33, when reading the file to be read, assume that the original offset pointer of the file to be read is x 2 , substitute it into the following formula: The number of the target storage unit file corresponding to the file to be read is y 2 , for example, the calculation result of the formula is 5.567, and the integer part taken downward is 5. So the file name of the target storage unit file corresponding to the file to be read is Table.5.MYD.

[0111] S34, after finding the target storage unit file corresponding to the file to be read, adjust the position of the offset pointer, and then you can start reading the file. The adjustment formula is as follows: x ′ 2 = x 2 - y 2 * M. Where x′ 2 is the adjusted offset pointer of the file to be read. At this point, the adjustment of the offset pointer is completed, and the file to be read can be directly read according to the file name of the target storage unit file corresponding to the file to be read and the adjusted offset pointer. It should be noted in this step that when the offset pointer reaches the end of the target storage unit during the reading process, the target storage unit needs to be repositioned, and the positioning method is similar to step S33. At this time, the adjusted offset pointer of the file to be read is set to 0, but the file is positioned to y 2 +1 on that.

[0112] S3, in response to determining that there are changed files in the storage unit file set, the physical storage path and change type of the changed file are recorded; in response to the change type being modification, the change type of the modified file is set to addition, and the change type of the file before modification is set to deletion; in response to the change type being addition, the changed file or the modified file is uploaded to the blockchain through the blockchain protocol, a unique identifier of the changed file on the blockchain is generated and mapped with the physical storage path of the changed file to obtain a mapping relationship; in response to the change type being deletion, the changed file or the file before modification is unbound and recovered.

[0113] Specifically, the embodiment of the present application stores all storage unit files in the MySQL database on the blockchain, and can synchronize changed files to the blockchain, that is, delete one or more storage unit files stored in each node on the blockchain, and upload local storage unit files to the blockchain. The specific steps are as follows:

[0114] S41, when the data in the data table changes, it will eventually be reflected in the data changes of the MYD file. At this time, the complete path of the changed file and the change type are recorded, and a message is generated uniformly. After the data synchronization within the data is completed, a group of messages is generated.

[0115] S42, when the MYD file changes, a subscription message will be received. The content of the message is the changed file path, and the change type is addition, modification or deletion.

[0116] S43, determine whether the change type of the changed file is newly added. Since the newly added file must not exist in the private blockchain, it needs special processing. In order to make the process processing simpler, only a binary judgment is made on the change type here, which is divided into two cases: newly added file and other cases.

[0117] S44, the changed files are only of two types: modification or deletion. At this time, a binary judgment is also performed, which will affect whether the file should be synchronized to the blockchain.

[0118] S45. Whether it is a newly added file or a modified file, essentially the same operation will reach this step. This step submits and uploads the storage unit file through the blockchain protocol. The blockchain protocol used in the embodiments of this application is IPFS (InterPlanetary File System), which is a network transmission protocol designed to create persistent and distributed storage and sharing of files. It is a distributed storage and transmission protocol for content-addressable, versioned, peer-to-peer hypermedia. IPFS allows participants in the network to store and transmit files to each other. The embodiments of this application utilize the distributed storage characteristics of IPFS to automatically store the storage unit file in multiple nodes. As long as more than half of the storage nodes can work properly, the integrity of the data can be guaranteed, achieving a secure and disaster-tolerant storage mechanism. The command for the newly added storage unit file is divided into two parts. The first part is to upload the storage unit file, and the command is ipfs add <path>, here <path>It refers to the physical storage path of the storage unit file to be uploaded. After the execution of the previous command is completed, a cid corresponding to the storage unit file will be returned, and this cid describes the unique identifier of this storage unit file on the entire chain. At this time, it is necessary to map this cid and the physical storage path and store them in a trusted place. In the embodiment of the present application, the mapping relationship is also put into MySQL. If it is an operation to modify a file, it is also necessary to perform an unbinding operation on the original storage unit file, and the unbinding operation is specifically described in step S46.

[0119] S46. After judgment in step S44, if the storage unit file belongs to a deleted file, it can be unbound from the storage unit file first through a custom protocol. The unbinding command is ipfs pin rm <cid>, where cid is the unique file identifier of the storage unit file on the IPFS network. After the unbinding is completed, a recovery command is sent to all nodes, and the recovery command is ipfs repo gc. At this time, the storage unit file will not be on the chain, and the full chain removal of the deleted file is completed.

[0120] Further references Figure 2 As an implementation of the methods shown in the above figures, the present application provides an embodiment of a MySQL data backup device based on blockchain. Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0121] The embodiment of the present application provides a MySQL data backup device based on blockchain, including:

[0122] Data segmentation module 1 is configured to segment the size of the MYD file corresponding to each data table in the MySQL database according to fixed segmentation units to obtain a number of storage unit files, and number them in sequence in the file names of the storage unit files to obtain a storage unit file set for each data table, and store the storage unit file set of all data tables on each node of the blockchain;

[0123] Writing module 2 is configured to obtain a file to be written and its name and offset pointer, where the offset pointer is the number of bytes between the current operation position and the beginning of the MYD file, obtain all relevant storage unit files in the storage unit file set according to the name of the file to be written, and in response to all relevant storage unit files being able to form a first file list, determine the file name of the target storage unit file corresponding to the file to be written in the first file list according to the offset pointer of the file to be written, write the file to be written based on the target storage unit file, and adjust the offset pointer of the file to be written;

[0124] The on-chain update module 3 is configured to record the physical storage path and change type of the changed file in response to determining that there is a changed file in the storage unit file set; in response to the change type being modification, set the change type of the modified file to addition, and set the change type of the file before modification to deletion; in response to the change type being addition, upload the changed file or the modified file to the blockchain through the blockchain protocol, generate a unique identifier for the changed file on the blockchain and map it with the physical storage path of the changed file to obtain a mapping relationship; in response to the change type being deletion, unbind and recycle the changed file or the file before modification.

[0125] Figure 3 Schematic diagram of the hardware structure of the electronic device provided by the embodiment of the present invention. Figure 3 As shown in the figure, the electronic device of this embodiment includes: a processor 301 and a memory 302; where the memory 302 is used to store computer-executable instructions; the processor 301 is used to execute the computer-executable instructions stored in the memory to implement each step performed by the electronic device in the above embodiment. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0126] Optionally, the memory 302 can be either independent or integrated with the processor 301.

[0127] When the memory 302 is independently provided, the electronic device further includes a bus 303 for connecting the memory 302 and the processor 301.

[0128] This embodiment of the present invention also provides a computer storage medium, in which computer-executable instructions are stored. When the processor 301 executes the computer-executable instructions, the above method is implemented.

[0129] This embodiment of the present invention also provides a computer program product, including a computer program. When the computer program is executed by the processor 301, the above method is implemented.

[0130] In the embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, and the indirect coupling or communication connection of devices or modules may be in electrical, mechanical or other forms.

[0131] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to implement the solution of this embodiment.

[0132] In addition, in each embodiment of the present invention, the functional modules can be integrated in a processing unit, or each module can exist physically alone, or two or more modules can be integrated in one unit. The units formed by the above modules can be implemented in the form of hardware, or in the form of a combination of hardware and software functional units.

[0133] The integrated modules implemented in the form of software functional modules can be stored in a computer-readable storage medium. The above-mentioned software functional modules are stored in a storage medium and include several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor 301 to execute some steps of the methods according to the various embodiments of the present application.

[0134] It should be understood that the above-mentioned processor 301 can be a central processing unit (CPU for short), and can also be other general-purpose processors, digital signal processors (DSP for short), application specific integrated circuits (ASIC for short), etc. The general-purpose processor can be a microprocessor or the processor 301 can also be any conventional processor 301, etc. The steps of the method disclosed in combination with the invention can be directly embodied as being executed and completed by the hardware processor 301, or can be executed and completed by the combination of hardware and software modules in the processor 301.

[0135] The memory 302 may include a high-speed RAM memory, and may also include non-volatile storage NVM, such as at least one disk memory, and may also be a USB flash drive, a mobile hard disk, a read-only memory, a magnetic disk, or an optical disc, etc.

[0136] The bus 303 can be an Industry Standard Architecture (ISA for short), a Peripheral Component Interconnect (PCI for short) bus, or an Extended Industry Standard Architecture (EISA for short) bus, etc. The bus 303 can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, the bus 303 in the drawings of the present application is not limited to only one bus 303 or one type of bus 303.

[0137] The above-mentioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disc. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0138] An exemplary storage medium is coupled to the processor 301, enabling the processor 301 to read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor 301. The processor 301 and the storage medium can be located in an Application Specific Integrated Circuits (ASIC). Of course, the processor 301 and the storage medium can also exist as discrete components in an electronic device or a master device.

[0139] Those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including the above method embodiments; and the foregoing storage medium includes: various media such as ROM, RAM, magnetic disks, or optical discs that can store program codes.

[0140] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention.< / cid> < / path> < / path>

Claims

1. A MySQL data backup method based on blockchain, characterized in that: The following steps are involved: The size of the MYD file corresponding to each data table in the MySQL database is divided according to fixed division units to obtain a number of storage unit files, and the files are numbered in sequence in the file names of the storage unit files to obtain a storage unit file set for each data table. The storage unit file set of all data tables is stored on each node of the blockchain; Obtaining a file to be written and its name and original offset pointer, wherein the offset pointer is the number of bytes between the current operation position and the beginning of the file, obtaining all relevant storage unit files in the storage unit file set according to the name of the file to be written, in response to determining that all the relevant storage unit files exist and form a first file list, determining the file name of the target storage unit file corresponding to the file to be written in the first file list according to the original offset pointer of the file to be written, writing the file to be written based on the target storage unit file, and obtaining an adjusted offset pointer of the file to be written; In response to determining that there is a changed file in the storage unit file set, the physical storage path and change type of the changed file are recorded; in response to the change type being modification, the change type of the modified file is set to addition, and the change type of the file before modification is set to deletion; in response to the change type being addition, the changed file or the modified file is uploaded to the blockchain through the blockchain protocol, a unique identifier of the changed file on the blockchain is generated and mapped with the physical storage path of the changed file to obtain a mapping relationship; in response to the change type being deletion, the changed file or the file before modification is unbound and recovered.

2. The MySQL data backup method based on blockchain according to claim 1, characterized in that: The file name of the storage unit file is XnMYD, wherein X represents a name, n represents a number, and the numbers of the storage unit files in the storage unit file set are continuous natural numbers from 0 to N.

3. The MySQL data backup method based on blockchain according to claim 1, characterized in that: Determining the file name of the target storage unit file corresponding to the file to be written in the first file list according to the offset pointer of the file to be written, writing the file to be written based on the target storage unit file, and adjusting the offset pointer of the file to be written, specifically includes: Determine that the fixed division unit of the MYD file is M bytes, and the storage unit files in the first file list are numbered as consecutive natural numbers from 0 to N1; The number of the storage unit file corresponding to the file to be written is calculated using the following formula: Wherein, x1 represents the original offset pointer of the file to be written, y1 represents the number of the storage unit file corresponding to the file to be written, Indicates rounding down; In response to determining that there is a storage unit file numbered y1 in the first file list, if the size of the file to be written does not exceed the reserved space in the storage unit file numbered y1, the storage unit file numbered y1 is used as the target storage unit file corresponding to the file to be written, the file name of the target storage unit file corresponding to the file to be written is determined, and the offset pointer of the file to be written is adjusted by the following formula: x′1=x1-y1*M; Wherein, x′1 represents the adjusted offset pointer of the file to be written; If the size of the file to be written exceeds the reserved space in the storage unit file numbered y1, the storage unit file numbered N1 is used as the target storage unit file corresponding to the file to be written, and the file name of the target storage unit file corresponding to the file to be written is determined, and the adjusted offset pointer is the next position of the position of the last stored file in the storage unit file numbered N1; When the size of the file to be written exceeds the boundary of the storage unit file numbered N1, new storage unit files are added sequentially; Writing the to-be-written file starts from the position of the adjusted offset pointer offset from the beginning of the target storage unit file; In response to determining that the storage unit file numbered y1 does not exist in the first file list, adding storage unit files in the first file list in sequence until a storage unit file numbered y1 is created, and repeating the above process; In response to determining that all the related storage unit files do not exist and form a first file list, a storage unit file numbered 0 and empty is created as a target storage unit file corresponding to the file to be written.

4. The MySQL data backup method based on blockchain according to claim 1, characterized in that: Also includes: Obtaining the name and offset pointer of the file to be read, obtaining all relevant storage unit files in the storage unit file set according to the name of the file to be read, and forming a second file list; The file name of the target storage unit file corresponding to the file to be read is determined in the second file list according to the offset pointer of the file to be read, and the file to be read is read based on the file name of the target storage unit file to obtain the file to be read.

5. The MySQL data backup method based on blockchain according to claim 3 is characterized in that: Determining the file name of the target storage unit file corresponding to the file to be read in the second file list according to the offset pointer of the file to be read, and reading based on the file name of the target storage unit file to obtain the file to be read specifically includes: Determine that the fixed division unit of the MYD file is M bytes, and the storage unit files in the first file list are numbered as consecutive natural numbers from 0 to N2; The number of the storage unit file corresponding to the file to be read is calculated using the following formula: Wherein, x2 represents the original offset pointer of the file to be read, and y2 represents the number of the storage unit file corresponding to the file to be read. Indicates rounding down; The storage unit file numbered y2 is used as the target storage unit file corresponding to the file to be read, and the offset pointer of the file to be read is adjusted by the following formula: x′2=x2-y2*M; Wherein, x′2 represents the adjusted offset pointer of the file to be read; Reading starts from the position of the adjusted offset pointer offset from the beginning of the target storage unit file to obtain the file to be read.

6. The MySQL data backup method based on blockchain according to claim 5, characterized in that: Also includes: If the adjusted offset pointer of the file to be read is located at the last position of the storage unit file numbered y2, the storage unit file numbered y2+1 is used as the target storage unit file corresponding to the file to be read, and the adjusted offset pointer of the file to be read is 0, and reading is started from the position of the adjusted offset pointer offset from the beginning of the target storage unit file to obtain the file to be read.

7. A MySQL data backup device based on blockchain, characterized in that: include: The data segmentation module is configured to segment the size of the MYD file corresponding to each data table in the MySQL database according to a fixed segmentation unit to obtain a plurality of storage unit files, and sequentially number them in the file names of the storage unit files to obtain a storage unit file set for each data table, and store the storage unit file set of all data tables on each node of the blockchain; A writing module is configured to obtain a file to be written and its name and offset pointer, wherein the offset pointer is the number of bytes between a current operation position and the beginning of a MYD file, obtain all relevant storage unit files in the storage unit file set according to the name of the file to be written, and in response to the fact that all relevant storage unit files can constitute a first file list, determine a file name of a target storage unit file corresponding to the file to be written in the first file list according to the offset pointer of the file to be written, write the file to be written based on the target storage unit file, and adjust the offset pointer of the file to be written; The on-chain update module is configured to, in response to determining that there is a changed file in the storage unit file set, record the physical storage path and change type of the changed file; in response to the change type being modification, set the change type of the modified file to addition, and set the change type of the file before modification to deletion; in response to the change type being addition, upload the changed file or the modified file to the blockchain through the blockchain protocol, generate a unique identifier of the changed file on the blockchain and map it with the physical storage path of the changed file to obtain a mapping relationship; in response to the change type being deletion, unbind and recycle the changed file or the file before modification.

8. An electronic device comprising: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images