A MySQL data backup method and device based on a blockchain and a readable medium

Abstract

The application discloses a MySQL data backup method and device based on a block chain and readable medium, and comprises the following steps: dividing the size of a MYD file corresponding to each data table in a MySQL database according to a fixed division unit to obtain a plurality of storage unit files, and sequentially numbering the file names of the storage unit files to obtain a storage unit file set of each data table; storing the storage unit file set of all data tables on each node of the block chain; acquiring all related storage unit files in the storage unit file set according to the name of a to-be-written file; when all the related storage unit files exist and constitute a first file list, determining the 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. The application can reduce the probability of erroneous operation caused by human factors and increase the security of data.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data backup, in particular to a MySQL data backup method and device based on a block chain and a readable medium. BACKGROUND

[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 a physical medium, there is a risk of data anomalies caused by physical hard disk damage, power supply problems or external forces such as natural disasters, which poses a challenge to the persistent storage of data. Therefore, MySQL data backup is an important measure to ensure data security, meet business needs and regulatory requirements. Regular backups 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 is to guide the logical structure and data of the database, usually represented as a set of SQL files. These files contain SQL statements needed to rebuild the database structure (such as tables, indexes, views, stored procedures, etc.) and INSERT statements to populate table data. The advantage of logical backup is that it provides flexibility for cross-platform migration, and the official provides corresponding tools, and the SQL file after backup is human-readable, making it easy to review and adjust data. Logical backup has the following problems:

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

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

[0007] Physical backup refers to copying database files directly to perform backup, which can maximize the restoration of the original state of the database, including table structure, index, trigger, etc. Physical backup is usually used in scenarios with large data volumes and high data consistency requirements, such as production environments. The advantage of physical backup is its high execution efficiency and strong restoration ability, while reducing database downtime. Physical backup has the following problems:

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

[0009] 2. Most importantly, it requires a lot of human intervention, which requires high personnel requirements and creates a lot of uncertainty.

[0010] 3. The backup storage hard disk needs to be maintained regularly by human, and needs to be shut down when replacing the backup hardware, which greatly affects the backup efficiency.

[0011] According to industry practice, in the actual production environment, when the data volume of the database reaches 50GB or more, the probability of selecting logical backup failure is high, and the purpose of backup cannot be achieved. The operation and maintenance personnel still prefer to use physical backup, but the above-mentioned problems exist in the physical backup, which leads to the operation also has not small risk. SUMMARY

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

[0013] In a first aspect, the present application provides a MySQL data backup method based on blockchain, comprising the following steps:

[0014] The size of the MYD file corresponding to each data table in the MySQL database is divided into a fixed division unit to obtain a plurality of storage unit files, and the storage unit file set of each data table is obtained by sequentially numbering the file name of the storage unit file, and the storage unit file set of all data tables is stored on each node of the blockchain;

[0015] Obtain the to-be-written file, 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 related storage unit files in the storage unit file set according to the name of the to-be-written file, in response to determining that all related storage unit files exist and constitute a first file list, determine the file name of the 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, write the to-be-written file based on the target storage unit file, and obtain the adjusted offset pointer of the to-be-written file;

[0016] In response to determining that there is a changed file in the storage unit file set, record the physical storage path and the change type of the changed file, in response to the change type being modification, set the change type of the modified file to new addition and the change type of the previous file to deletion, in response to the change type being new 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 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 previous file is unbound and recycled.

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

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

[0019] The fixed partition 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 N1;

[0020] The number of the storage unit file corresponding to the to-be-written file is calculated by using the following formula:

[0021] ;

[0022] wherein, represents the original offset pointer of the to-be-written file, represents the number of the storage unit file corresponding to the to-be-written file, represents the floor function;

[0023] In response to the determination that the storage unit file with the number of N1 exists in the first file list, if the size of the to-be-written file does not exceed the reserved space in the storage unit file with the number of N1, the storage unit file with the number of N1 is taken as the target storage unit file corresponding to the to-be-written file, the file name of the target storage unit file corresponding to the to-be-written file is determined, and the offset pointer of the to-be-written file is adjusted by using the following formula:

[0024] ;

[0025] wherein, represents the adjusted offset pointer of the to-be-written file;

[0026] If the size of the to-be-written file exceeds the reserved space in the storage unit file with the number of N1, the storage unit file with the number of N1 is taken as the target storage unit file corresponding to the to-be-written file, the file name of the target storage unit file corresponding to the to-be-written file is determined, and the adjusted offset pointer is the next position of the last stored file in the storage unit file with the number of N1;

[0027] When the size of the to-be-written file exceeds the boundary of the storage unit file with the number of N1, the newly added storage unit files are sequentially extended in sequence; ​​​​

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

[0029] in response to determining that there is no storage unit file numbered in the first file list, sequentially extend the newly added storage unit files in the first file list until a storage unit file numbered is created, and repeat the above process;

[0030] in response to determining that there is no all related storage unit files, create a storage unit file numbered 0 and empty as the target storage unit file corresponding to the to-be-written file.

[0031] As preferred, it further comprises:

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

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

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

[0035] determining that the fixed partition unit of the MYD file is M bytes, and the numbers of the storage unit files in the second file list are consecutive natural numbers from 0 to N2;

[0036] the number of the storage unit file corresponding to the to-be-read file is calculated by the following formula:

[0037] ;

[0038] wherein, represents the original offset pointer of the to-be-read file, represents the number of the storage unit file corresponding to the to-be-read file, represents the floor function;

[0039] the storage unit file numbered is taken as the target storage unit file corresponding to the to-be-read file, and the offset pointer of the to-be-read file is adjusted by the following formula:

[0040] ;

[0041] wherein, the adjusted offset pointer of the file to be read indicates an adjusted offset pointer of the file to be read;

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

[0043] Preferably, if the adjusted offset pointer of the file to be read is located at the last position of the storage unit file numbered , the storage unit file numbered is taken 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 from the beginning of the target storage unit file at the position of the adjusted offset pointer to obtain the file to be read.

[0044] In a second aspect, the present application provides a MySQL data backup device based on a block chain, comprising:

[0045] A 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 the file names of the storage unit files to obtain a storage unit file set of each data table, and store the storage unit file sets of all data tables on each node of the block chain.

[0046] A writing module is configured to obtain a file to be written, the name and offset pointer thereof, the offset pointer being the number of bytes between the current operation position and the beginning of the MYD file, obtain all related storage unit files in the storage unit file set according to the name of the file to be written, 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 in response to all related storage unit files being able to constitute a first file list, 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] An on-chain updating module is configured to record the physical storage path and the change type of the changed file in response to determining that there is a changed file in the storage unit file set, set the change type of the modified file to be added and the change type of the previous file to be deleted in response to the change type being modification, upload the changed file or the modified file to the block chain through the block chain protocol in response to the change type being added, generate a unique identifier of the changed file on the block chain and map the unique identifier with the physical storage path of the changed file to obtain a mapping relationship, and unbind and recycle the changed file or the previous file in response to the change type being deletion.

[0048] In a third aspect, the present application provides 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 as described in any implementation manner of the first aspect.

[0049] In a fourth aspect, the present application provides a computer readable storage medium, having stored thereon a computer program, when the computer program is executed by a processor, the method as described in any implementation manner of the first aspect is implemented.

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

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

[0052] (1) The MySQL data backup method based on the blockchain of the present application makes the incremental backup in the physical backup possible by segmenting the MYD file, improves the backup efficiency, reduces the hard disk space overhead of the backup and the bandwidth consumption in the network transmission, and helps to improve the transmission efficiency.

[0053] (2) The MySQL data backup method based on the blockchain of the present application synchronizes the storage unit files automatically according to the blockchain protocol, eliminates the error operation caused by manual intervention, ensures the correct execution of the process, and can only select the storage unit file in which the data has changed when backing up after cutting the storage unit file, without global backup. For a system, continuous backup can effectively reduce the probability of data rollback or data loss, but more frequent backup will cause additional burden to the system. The present application can only synchronize the smallest storage unit file, thereby greatly reducing the backup cost of the system on the premise of ensuring the backup frequency.

[0054] (3) The MySQL data backup method based on the blockchain of the present application uses the distributed storage of the blockchain, the characteristics of not being easy to tamper, increases the security of the database file, improves the disaster recovery capability, more effectively protects the data, and solves the heavy physical backup problem of the operation and maintenance personnel. It can be effectively applied in some production environments that are zero tolerant to data loss, and based on the characteristics of the blockchain, the backup storage machine can be easily shut down for maintenance and hardware replacement. BRIEF DESCRIPTION OF DRAWINGS

[0055] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0056] Figure 1 A flowchart of a MySQL data backup method based on a blockchain according to an embodiment of the present application is shown.

[0057] Figure 2 A schematic diagram of a MySQL data backup device based on a blockchain according to an embodiment of the present application is shown.

[0058] Figure 3 A hardware structure schematic diagram of an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0059] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings. Obviously, the described embodiments are only some embodiments of the present application, but not all embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort fall within the scope of protection of the present application.

[0060] Figure 1 A MySQL data backup method based on a blockchain according to an embodiment of the present application is shown, including the following steps:

[0061] S1, the size of the MYD file corresponding to each data table in the MySQL database is divided according to a fixed division unit, a plurality of storage unit files are obtained, and the storage unit file set of each data table is obtained by sequentially numbering the file name of the storage unit file, and the storage unit file set of all data tables is stored on each node of the blockchain.

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

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

[0064] Therefore, the embodiment of the present application processes the MYD file as follows:

[0065] 1. The file size of the MYD file is divided into M as a fixed division unit.

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

[0067] S2, obtain a file to be written and its name and an original offset pointer, the offset pointer is the number of bytes between the current operation position and the beginning of the file, obtain all related 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 related storage unit files exist and constitute 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, 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:

[0069] 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 0 to N1 continuous natural numbers;

[0070] The number of the storage unit file corresponding to the file to be written is calculated by the following formula:

[0071] ;

[0072] Wherein, represents the original offset pointer of the file to be written, denotes the number of the storage unit file corresponding to the file to be written, denotes the floor function;

[0073] in response to determining that the storage unit file numbered exists 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 , the storage unit file numbered is taken 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:

[0074] ;

[0075] wherein, denotes 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 numbered , the storage unit file numbered N1 is taken 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 adjusted offset pointer is the next position of the position of the last stored file in the storage unit file numbered N1;

[0077] when the size of the file to be written exceeds the boundary of the storage unit file numbered N1, the newly added storage unit files are sequentially extended in order;

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

[0079] in response to determining that the storage unit file numbered does not exist in the first file list, the newly added storage unit files are sequentially extended in order in the first file list until the storage unit file numbered is created, and the above process is repeated;

[0080] in response to determining that all the related storage unit files do not exist, 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, the name of the database is Database, and the name of the data table is Table. The following describes 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, find the MYD file with the corresponding file name under the database storage directory. Assuming that the database installation directory is D:\MySQL, if not specially modified, the data table with the name Table is usually placed in the physical storage path D:\MySQL\data\Database. Find the storage unit file with the file name Table.n1.MYD under the database storage directory through the MySQL API to form a first file list, where n1 is a continuous natural number from 0 to N1.

[0085] S23, determine whether the storage unit file with the file name from Table.0.MYD to Table.N1.MYD exists in the first file list. It must be ensured that the numbers from 0 to N1 are continuous natural numbers.

[0086] S24, when the first file list of step S23 does not exist, at this time, a storage unit numbered 0 and empty needs to be created as the first data landing file carrier medium to create sufficient conditions for subsequent data writing MYD files.

[0087] S25, when the first file list of step S23 exists, the split interval M of the MYD file is 10485760 KB. If the original offset pointer of the file to be written is , the original offset pointer used before the MYD file is split, substitute the following formula: , for example: The calculation result of 5.567 is 5.567, and the integer part is rounded down, so the file to be written is 5, so the file name of the storage unit file corresponding to the file to be written is Table.5.MYD.

[0088] S26, when the storage unit file with the file name Table.5.MYD does not exist in the first file list, since the storage unit file with the file name Table.5.MYD does not exist, the storage unit file with the file name Table.5.MYD cannot be modified. At this time, the number is calculated according to the formula of step S25, and the corresponding numbered storage unit file is created for data landing. After creation, follow the process to step S27.

[0089] S27, when the first file list exists a storage unit file with the file name Table.5.MYD, or the subsequent step of step S24 and step S26, at this time, the storage unit file with the file name Table.5.MYD is opened by using the API of MySQL, the file to be written is handed over to the storage unit file with the file name Table.5.MYD, and the position of the offset pointer is adjusted. The formula of adjusting the offset pointer is as follows: . The adjusted offset pointer of the file to be written is the byte number between the current operation position and the beginning of the storage unit file with the file name Table.5.MYD. The adjusted offset pointer can be directly written into the binary file, and the on-disk operation of the file to be written is completed. 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 with the file name Table.5.MYD, the adjusted offset pointer of the file to be written is offset to the tail of all the files stored in the first file list, so that the operation of sequentially extending the data of the subsequent files is not necessary. The writing is directly jumped to the last storage unit file stored in the first file list. When the file size of the file to be written exceeds the boundary of the last storage unit file, a sequentially extended number is added to receive the remaining data writing, such as the storage unit files with the numbers N1+1, N1+2, N1+3, etc.

[0090] As shown in Table 1, the data stored in the storage unit file with the file name Table.5.MYD is shown in the first row, wherein the columns E and F are the reserved space. When the files to be written are 15 and 16, because 15 and 16 are less than or equal to the reserved space of Table.5.MYD, the positions of columns E and F are filled, and the storage contents of the filled files are shown in the second row. If the length of the file to be written is greater than the reserved space, the file to be written is appended to the tail of the first file list, as shown in the third row. The columns I, J and K are appended to the tail of the last storage unit file of the first file list after column H, and 15, 16 and 17 are written into columns I, J and K, respectively.

[0091] Table 1

[0092]

[0093] In specific embodiments, further comprising:

[0094] obtaining the name and offset pointer of the file to be read, obtaining all the related 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;

[0095] The file name of the target storage unit file corresponding to the to-be-read file is determined according to the offset pointer of the to-be-read file in the second file list, and reading is performed based on the file name of the target storage unit file, so that the to-be-read file is obtained.

[0096] In specific embodiments, the file name of the target storage unit file corresponding to the to-be-read file is determined according to the offset pointer of the to-be-read file in the second file list, and reading is performed based on the file name of the target storage unit file, so that the to-be-read file is obtained, specifically including:

[0097] The fixed partition unit of the MYD file is determined to be M bytes, and the numbers of the storage unit files in the second file list are continuous natural numbers from 0 to N2;

[0098] The number of the storage unit file corresponding to the to-be-read file is calculated by using the following formula:

[0099] ;

[0100] wherein, represents the original offset pointer of the to-be-read file, represents the number of the storage unit file corresponding to the to-be-read file, represents the floor function;

[0101] the storage unit file numbered is taken as the target storage unit file corresponding to the to-be-read file, and the offset pointer of the to-be-read file is adjusted by using the following formula:

[0102] ;

[0103] wherein, represents the adjusted offset pointer of the to-be-read file;

[0104] The to-be-read file is obtained by reading from the beginning of the target storage unit file at the position of the adjusted offset pointer.

[0105] In specific embodiments, it further includes: if the adjusted offset pointer of the to-be-read file is located at the last position of the storage unit file numbered , the storage unit file numbered is taken as the target storage unit file corresponding to the to-be-read file, and the adjusted offset pointer of the to-be-read file is 0, and the to-be-read file is obtained by reading from the beginning of the target storage unit file at the position of the adjusted offset pointer.

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

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

[0108] S32, taking Table as an example, querying all the filenames under the folder of the database storage by MySQL with the name Table, wherein n2 is a continuous natural number from 0 to N2.

[0109] S33, when reading the file to be read, assuming that the original offset pointer of the file to be read is x2, the following formula is substituted: The number of the target storage unit file corresponding to the file to be read is , for example, the calculation result of the formula is 5.567, and the integer part is 5 after rounding down, so the filename of the target storage unit file corresponding to the file to be read is Table.5.MYD.

[0110] S34, after finding the target storage unit file corresponding to the file to be read, the position of the offset pointer is adjusted, that is, the file can be read. The formula for adjustment is as follows: , wherein 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 can be directly read according to the filename of the target storage unit file corresponding to the file to be read and the adjusted offset pointer. It should be noted that during the reading process, when the offset pointer reaches the end of the target storage unit, 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 on .

[0111] S3, in response to determining that there is a changed file in the storage unit file set, recording the physical storage path of the changed file and the change type, in response to the change type being modification, setting the change type of the modified file to new and the change type of the modified file to delete, in response to the change type being new, uploading the changed file or the modified file to the blockchain through the blockchain protocol, generating a unique identifier of the changed file on the blockchain and mapping the physical storage path of the changed file, to obtain a mapping relationship; in response to the change type being delete, the changed file or the modified file is unbound and recycled.

[0112] Specifically, all storage unit files in the MySQL database are stored on the blockchain, and the changed files can be synchronized to the blockchain, that is, one or more storage unit files stored on each node of the blockchain can be deleted, and the local storage unit file can be uploaded to the blockchain. The specific steps are as follows:

[0113] S41, when the data in the data table changes, the final data change in the MYD file will be reflected, at which time the complete path of the record change file, the change type, and the message are generated. After completing the data synchronization within the data, a set of messages is generated.

[0114] S42, when the MYD file changes, a subscription message is received. The content of the message is the changed file path, and the change type is new, modified, or deleted.

[0115] S43, determine whether the change type of the changed file is new. The newly added file does not exist in the private blockchain, so special processing is required. In order to make the process simpler, only a binary judgment of the change type is performed, which is divided into two cases: new file and other two cases.

[0116] S44, the changed file is only left with two types of modification or deletion, at which time a binary judgment is also performed, which will affect whether the file is synchronized to the blockchain.

[0117] S45, whether it is a new file or a modified file, the same operation is essentially performed, which comes to this step. This step stores the storage unit file through the blockchain protocol. The blockchain protocol used by the embodiment of the application is IPFS (InterPlanetary File System, InterPlanetary File System), which is a network transmission protocol designed to create persistent and distributed storage and sharing of files. It is a content addressable, versioned, peer-to-peer hypermedia distributed storage, transmission protocol. IPFS allows participants in the network to store and transmit files to each other. The embodiment of the application utilizes the distributed storage feature of IPFS to automatically store the storage unit file in multiple nodes. As long as more than half of the storage nodes are working properly, the data integrity can be guaranteed, achieving a safe and disaster recovery storage mechanism. The command for adding a new 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>The physical storage path of the storage unit file to be uploaded is referred to. When the previous command is executed, a cid corresponding to the storage unit file is returned, which describes a unique identifier of the storage unit file on the entire chain. At this time, the cid and the physical storage path need to be mapped and stored in a trusted place. In the embodiment of the present application, the mapping relationship is also put into MySQL. If it is a file modification operation, a binding operation needs to be performed on the original storage unit file, which is specifically described in step S46.

[0118] In step S46, if the storage unit file belongs to a deleted file, the storage unit file is first unbonded through a self-defined protocol according to the judgment in step S44. The unbonding command is ipfs pin rm <cid>Wherein cid is the unique identifier of the file 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.

[0119] Further referring to Figure 2 As an implementation of the method shown in the above figures, the application provides an embodiment of a MySQL data backup device based on a block chain. The device embodiment corresponds to the method embodiment shown in Figure 1 , and the device can be applied to various electronic devices.

[0120] The application embodiment provides a MySQL data backup device based on a block chain, which comprises:

[0121] The 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 a fixed segmentation unit, obtain a plurality of storage unit files, and sequentially number the file names of the storage unit files to obtain a storage unit file set of each data table, and store the storage unit file set of all data tables on each node of the block chain.

[0122] The writing module 2 is configured to obtain a to-be-written file, the name and offset pointer of the to-be-written file, the offset pointer being the number of bytes between the current operation position and the beginning of the MYD file, obtain all related storage unit files in the storage unit file set according to the name of the to-be-written file, determine the file name of the target storage unit file corresponding to the to-be-written file in the first file list in response to all related storage unit files being able to constitute a first file list, write the to-be-written file based on the target storage unit file, and adjust the offset pointer of the to-be-written file.

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

[0124] Figure 3 The hardware structure schematic diagram of the electronic device provided by the application embodiment is shown in Figure 3 As shown, the electronic device of the embodiment includes a processor 301 and a memory 302; the memory 302 is configured to store computer execution instructions; the processor 301 is configured to execute the computer execution instructions stored in the memory, so as to realize each step performed by the electronic device in the above embodiment. For details, refer to the related description in the foregoing method embodiment.

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

[0126] When the memory 302 is independently arranged, the electronic device further includes a bus 303, configured to connect the memory 302 and the processor 301.

[0127] The embodiment of the application further provides a computer storage medium, and the computer storage medium stores computer execution instructions; when the processor 301 executes the computer execution instructions, the method described above is realized.

[0128] The embodiment of the application further provides a computer program product, and the computer program product includes a computer program; when the computer program is executed by the processor 301, the method described above is realized.

[0129] In the embodiments of the application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. In actual implementation, another division mode can be used. For example, a plurality of modules can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the modules shown or discussed can be indirect coupling or communication connection through some interfaces, devices or modules, and can be electrical, mechanical or other forms.

[0130] The modules illustrated as separate components can or can not be physically separate, and the components illustrated as modules can or can not be physical units, i.e. can be located in one place, or can be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to implement the embodiment scheme.

[0131] In addition, each functional module in each embodiment of the application can be integrated in one processing unit, or each module can be physically present independently, or two or more modules can be integrated in one unit. The unit formed by the above modules can be realized in the form of hardware, or in the form of hardware plus software function unit.

[0132] The integrated modules realized in the form of software function modules can be stored in a computer readable storage medium. The software function modules are stored in a storage medium and include a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or the processor 301 to execute part of the steps of the various embodiments of the method.

[0133] It should be understood that the processor 301 described above can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), 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 application can be directly embodied as the execution of the processor 301 in hardware, or be executed by a combination of hardware and software modules in the processor 301.

[0134] The memory 302 can include a high-speed RAM memory, and can also include a non-volatile storage NVM, for example at least one disk memory, and can also be a U disk, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.

[0135] The bus 303 can be an industry standard architecture (ISA), a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) 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 does not limit only one bus 303 or one type of bus 303.

[0136] The storage medium described above can be realized 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 storage, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0137] An example storage medium is coupled to the processor 301 such that the processor 301 can read information from, and can write information to, the storage medium. Of course, the storage medium can be a part of the processor 301. Consistent with the teachings provided herein, the processor 301 can execute instructions stored in the storage medium or it can be dedicated in hardware to perform its functions. The storage medium can include one or more machine-readable storage media involving any type of storage hardware. For example, the storage medium can include any type of tangible memory, such as volatile or non-volatile memory including dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, or a combination of such memories. The storage medium can also include non-tangible machine-readable storage media, such as a communication network.

[0138] Those skilled in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction related hardware. The foregoing program can be stored in a computer readable storage medium. The program executes the steps of the above-mentioned method embodiments when executed; and the foregoing storage medium includes ROM, RAM, magnetic disc or optical disc and various storage media that can store program codes.

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the above embodiments, or make equivalent replacement for part 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 application.< / cid> < / path> < / path>

Claims

1. A blockchain-based MySQL data backup method, characterized in that, Includes the following steps: The size of the MYD file corresponding to each data table in the MySQL database is divided according to a fixed partitioning unit to obtain several storage unit files. The storage unit files are numbered sequentially in the file name to obtain a set of storage unit files for each data table. The set of storage unit files for all data tables is stored on each node of the blockchain. Obtain the file to be written, its name, and the original offset pointer, where the offset pointer is the number of bytes between the current operation position and the beginning of the file. Based on the name of the file to be written, obtain all relevant storage unit files in the storage unit file set. In response to determining that all the relevant storage unit files exist and form a first file list, determine the filename of the target storage unit file corresponding to the file to be written in the first file list based on 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. In response to determining that a modified file exists in the storage unit file set, the physical storage path and modification type of the modified file are recorded. In response to the modification type being "modified", the modification type of the modified file is set to "added", and the modification type of the file before modification is set to "deleted". In response to the modification type being "added", the modified file or the modified file is uploaded to the blockchain via the blockchain protocol, a unique identifier for the modified file on the blockchain is generated, and it is mapped to the physical storage path of the modified file to obtain a mapping relationship. In response to the modification type being "deleted", the modified file or the file before modification is unbound and reclaimed.

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

3. The blockchain-based MySQL data backup method according to claim 1, characterized in that, Based on the offset pointer of the file to be written, determine the filename of the target storage unit file corresponding to the file to be written in the first file list, write the file to be written based on the target storage unit file, and adjust the offset pointer of the file to be written, specifically including: The fixed segmentation unit of the MYD file is determined to be M bytes, and the storage unit file numbers in the first file list are consecutive natural numbers from 0 to N1; The storage unit file number corresponding to the file to be written is calculated using the following formula: ； in, This represents the original offset pointer to the file to be written. This indicates the file number of the storage unit corresponding to the file to be written. Indicates rounding down; In response to determining that the first file list contains a file with the number 1 The storage unit file, if the size of the file to be written does not exceed the number of the storage unit file, The reserved space in the storage unit file will be numbered as follows: The storage unit file is used as the target storage unit file corresponding to the file to be written. The filename 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: ； in, This represents the adjusted offset pointer of the file to be written; If the size of the file to be written exceeds the number... If the reserved space in the storage unit file is used, then 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. The adjusted offset pointer is the position after 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. The writing of the file to be written begins at a position offset from the beginning of the target storage unit file by the adjusted offset pointer. In response to determining that the first file list does not contain the number 1 If a storage unit file is created, then new storage unit files are added sequentially in the first file list until a file with the number [number] is created. The storage unit file, and repeat the above process; In response to the determination that none of the relevant storage unit files exist, an empty storage unit file with the number 0 is created as the target storage unit file corresponding to the file to be written.

4. The blockchain-based MySQL data backup method according to claim 1, characterized in that, Also includes: Obtain the name and offset pointer of the file to be read, retrieve all relevant storage unit files from the storage unit file set according to the name of the file to be read, and form a second file list; Based on the offset pointer of the file to be read, determine the filename of the target storage unit file corresponding to the file to be read in the second file list, and read the file based on the filename of the target storage unit file to obtain the file to be read.

5. The blockchain-based MySQL data backup method according to claim 4, characterized in that, Based on the offset pointer of the file to be read, the filename of the target storage unit file corresponding to the file to be read is determined in the second file list. The file is then read based on the filename of the target storage unit file to obtain the file to be read. Specifically, this includes: The fixed segmentation unit of the MYD file is determined to be M bytes, and the storage unit file numbers in the second file list are consecutive natural numbers from 0 to N2; The storage unit file number corresponding to the file to be read is calculated using the following formula: ； in, This represents the original offset pointer of the file to be read. This indicates the file number of the storage unit corresponding to the file to be read. Indicates rounding down; Number The storage unit file 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: ； in, This represents the adjusted offset pointer of the file to be read; The file to be read is obtained by starting from the beginning of the target storage unit file at a position offset from the adjusted offset pointer.

6. The blockchain-based MySQL data backup method according to claim 5, characterized in that, Also includes: If the adjusted offset pointer of the file to be read is located at the number... The last location of the storage unit file will be numbered as follows. The storage unit file 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. Reading starts from the position of the adjusted offset pointer at the beginning of the target storage unit file to obtain the file to be read.

7. A blockchain-based MySQL data backup device, characterized in that, include: The data segmentation module is configured to divide the size of the MYD file corresponding to each data table in the MySQL database according to a fixed segmentation unit to obtain several storage unit files, and to sequentially number the storage unit files in the file name of the storage unit files to obtain a set of storage unit files for each data table. The set of storage unit files for all data tables is stored on each node of the blockchain. The write module is configured to obtain the file to be written, its name, and an offset pointer, wherein 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; in response to the fact that all relevant storage unit files can form a first file list; determine the filename 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. The on-chain update module is configured to, in response to determining that there are modified files in the storage unit file set, record the physical storage path and change type of the modified 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 modified file or the modified file to the blockchain via the blockchain protocol, generate a unique identifier for the modified file on the blockchain and map it to the physical storage path of the modified file to obtain a mapping relationship; in response to the change type being deletion, unbind and reclaim the modified file or the file before modification.

8. An electronic device, comprising: One or more processors; 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 as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images