Database master-slave replication method, device and equipment and storage medium

Abstract

The invention discloses a method, a device and equipment for copying a main database and a standby database and a storage medium, which are applied to the field of databases, and the method comprises the following steps: creating a plurality of sub-threads on a server where a standby database is located through a coordinator, constructing a double-layer hash table for each sub-thread, and synchronizing a transaction from a main database binlog to a relay-log of the standby database; and analyzing the transaction in the relay-log through the coordinator, constructing the line identifier of the changed line, and determining the hash value of the line identifier. Hash values of changed rows in transactions and Hash values stored in a double-layer Hash table are compared to prevent two transactions updating the same row from being distributed to different sub-threads, and the transactions cannot be split, so that multi-thread distribution and operation of the transactions are realized, the synchronization efficiency of a standby database is improved, main and standby delay is reduced, and the service life of the database is prolonged. And the efficiency of distributing the sub-threads after the coordinator analyzes the transaction is ensured through the double-layer hash table, and meanwhile, the probability of hash collision is reduced.

Description

Technical Field

[0001] The present invention relates to the field of databases, and in particular to a database master-slave replication method, device, equipment and computer-readable storage medium. Background Art

[0002] When the MySQL database is replicated between master and slave, there is a difference in synchronization speed. The storage speed of the MySQL master database is multi-threaded and supports concurrency, but the slave database is single-threaded when replaying the binlog (binary log) after synchronizing to the master data. Therefore, the speed will be slower than the master database, resulting in master-slave replication delay. If the master-slave replication delay is too long, it will seriously affect the business, such as data consistency problems, reduced read-write separation effect, high risk of data loss, extended fault recovery time, reduced data query performance, and increased replication link pressure. Summary of the invention

[0003] The purpose of the present invention is to provide a database master-slave replication method, device, equipment and computer-readable storage medium, which are applied to the database field. The method realizes multi-threaded allocation and operation of transactions, avoids improving the synchronization efficiency of the standby database, reduces the master-slave delay, and ensures the efficiency of allocating sub-threads after the coordinator parses the transaction through a double-layer hash table. At the same time, the probability of hash collision is reduced through the double layer.

[0004] In order to solve the above technical problems, the present invention provides a database master-slave replication method, comprising:

[0005] A coordinator creates multiple child threads on the server where the standby database is located, builds a hash table for each child thread, and synchronizes transactions from the binlog of the primary database to the relay-log of the standby database; the hash table is a double-layer hash table;

[0006] Parsing the transaction in the relay-log through the coordinator, determining the modified row in the transaction and the number of row modifications of the modified row, and constructing the row identifier of the modified row;

[0007] Determine a hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier using a first hash algorithm and a second hash value obtained by calculating the row identifier using a second hash algorithm;

[0008] When the hash value of the row identifier is stored in the hash table, determining the hash table storing the hash value of the row identifier as a target hash table;

[0009] When the hash value of the row identifier is not stored in the hash table, randomly determining a target hash table from the hash table, and storing the hash value of the row identifier in the target hash table;

[0010] Based on the number of row modifications, the corresponding value in the target hash table is updated, and the transaction is assigned to the target sub-thread of the target hash table. When the execution statement of the modified row in the target sub-thread is executed, the hash value and the corresponding value of the row identifier in the target hash table are deleted.

[0011] Optionally, when the hash value of the row identifier is stored in the hash table, determining the hash table storing the hash value of the row identifier as the target hash table includes:

[0012] When the hash values ​​of all the row identifiers are stored in one hash table, determining the hash table storing the hash values ​​of all the row identifiers as the target hash table;

[0013] When the hash values ​​of some of the row identifiers are stored in one of the hash tables, and the hash values ​​of another part of the row identifiers are not stored in the hash table, determining the hash table storing the hash values ​​of some of the row identifiers as the target hash table;

[0014] When the hash values ​​of all the row identifiers are stored in multiple different hash tables, the transaction is placed in the coordinator to wait until the hash values ​​of some of the row identifiers are stored in one of the hash tables and the hash values ​​of another part of the row identifiers are not stored in the hash table.

[0015] Optionally, constructing the row identifier of the modified row includes:

[0016] Constructing a row identifier of the modified row based on the library name, table name, unique key and the value of the unique key of the modified row;

[0017] Or, a row identifier of the changed row is constructed based on the library name, the table name, the unique index and the value of the unique index of the changed row.

[0018] Optionally, updating the corresponding value in the target hash table based on the row modification count includes:

[0019] Add the value of the hash value of the row identifier in the target hash table to the corresponding row modification times.

[0020] Optionally, the step of creating multiple child threads on the server where the standby database is located by the coordinator includes:

[0021] A plurality of the sub-threads are created on the server through the coordinator based on the remaining resources of the server.

[0022] Optionally, parsing the transaction in the relay-log by the coordinator includes:

[0023] The coordinator searches and parses transactions from the relay-log based on the transaction ID in ascending order.

[0024] Optionally, the hash table is a double-layer or higher hash table; accordingly, the hash value of the row identifier includes operation values ​​of two or more hash algorithms.

[0025] In order to solve the above technical problems, the present invention provides a database master-slave replication device, comprising:

[0026] The first module is used to create multiple sub-threads on the server where the standby database is located through the coordinator, build a hash table for each sub-thread, and synchronize transactions from the binlog of the primary database to the relay-log of the standby database; the hash table is a double-layer hash table;

[0027] The second module is used to parse the transaction in the relay-log through the coordinator, determine the modified row in the transaction and the number of row modifications of the modified row, and construct the row identifier of the modified row;

[0028] The third module is used to determine the hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier using a first hash algorithm and a second hash value obtained by calculating the row identifier using a second hash algorithm;

[0029] A fourth module is used for determining the hash table storing the hash value of the row identifier as a target hash table when the hash value of the row identifier is stored in the hash table;

[0030] A fifth module, configured to, when the hash value of the row identifier is not stored in the hash table, randomly determine a target hash table from the hash table, and store the hash value of the row identifier in the target hash table;

[0031] The sixth module is used to update the corresponding value in the target hash table based on the number of row modifications, assign the transaction to the target sub-thread of the target hash table, and delete the hash value and corresponding value of the row identifier in the target hash table after the execution statement of the modified row in the target sub-thread is executed.

[0032] In order to solve the above technical problems, the present invention provides a database master-slave replication device, comprising:

[0033] Memory, for storing computer programs;

[0034] A processor is used to implement the database master-slave replication method when executing the computer program.

[0035] In order to solve the above technical problem, the present invention provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, the database master-slave replication method is implemented.

[0036] It can be seen that the method of the present invention creates multiple sub-threads on the server where the standby database is located through a coordinator, builds a hash table for each sub-thread, and synchronizes transactions from the binlog of the main database to the relay-log of the standby database; the hash table is a double-layer hash table; the coordinator parses the transactions in the relay-log, determines the modified rows in the transaction and the number of row modifications of the modified rows, and builds the row identifier of the modified rows; determines the hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier through a first hash algorithm and a second hash value obtained by calculating the row identifier through a second hash algorithm; when the hash value of the row identifier is stored in the hash table, the hash table storing the hash value of the row identifier is determined as the target hash table; when the hash value of the row identifier is not stored in the hash table, the target hash table is randomly determined from the hash table, and the hash value of the row identifier is stored in the target hash table; based on the number of row modifications, the corresponding value value in the target hash table is updated, and when the execution statement of the modified row in the target sub-thread is executed, the hash value of the row identifier and the corresponding value value in the target hash table are deleted.

[0037] The method of the present invention realizes multi-thread allocation and operation of transactions through a double-layer hash table, improves the synchronization efficiency of the standby database, reduces the master-standby delay, and ensures the efficiency of allocating sub-threads after the coordinator parses the transaction through the double-layer hash table, while reducing the probability of hash collision. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0039] Figure 1 A flowchart of a database master-slave replication method provided by an embodiment of the present invention;

[0040] Figure 2 The present invention provides a structural block diagram of a database master-slave replication device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0041] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0042] When the MySQL database is replicated between master and slave, there is a difference in synchronization speed. The storage speed of the MySQL master database is multi-threaded and supports concurrency, but the slave database is single-threaded when replaying the binlog (binary log) after synchronizing to the master data. Therefore, the speed will be slower than the master database, resulting in master-slave replication delay. If the master-slave replication delay is too long, it will seriously affect the business, such as data consistency problems, reduced read-write separation effect, high risk of data loss, extended fault recovery time, reduced data query performance, and increased replication link pressure.

[0043] After the standby database synchronizes the binlog of the primary database, the coordinator reads the log information in the relay-log, distributes the transactions in the log to different sub-threads according to the rules for processing and parallel replay to the standby database, thereby realizing the master-slave replication in a multi-threaded manner. When the master-slave replication is realized in a multi-threaded manner at the row level, the transactions that can be executed by each thread must comply with certain rules, that is, in the repeatable read transaction mode, certain principles must be followed, otherwise dirty reading may result. The principle is: two transactions that update the same row must be assigned to the same sub-thread; the same transaction cannot be split and must be placed in the same sub-thread. The method of the present invention ensures the execution of the above principles by constructing a hash table.

[0044] The following combination Figure 1 , Figure 1 A flowchart of a database master-slave replication method provided by an embodiment of the present invention, the method may include:

[0045] S101: Create multiple child threads on the server where the standby database is located through the coordinator, build a hash table for each child thread, and synchronize transactions from the binlog of the primary database to the relay-log of the standby database; the hash table is a double-layer hash table.

[0046] This embodiment can establish a replication task between the primary and standby databases, and perform database primary and standby replication through the replication task. First, this embodiment can create a coordinator on the server where the standby database is located, and create multiple sub-threads on the server through the coordinator based on the remaining resources of the server, and build a hash table for each sub-thread. This embodiment does not limit the specific type of hash table, which can generally be a two-layer hash table or a hash table with more than two layers, and can be specifically set based on actual applications.

[0047] Furthermore, this embodiment can synchronize transactions from the binlog of the master database to the relay-log of the standby database. In the MySQL database, a transaction is a collection of a series of operations. The binlog of the MySQL database is a key log file used to record all database change operations. It is stored in binary form and includes detailed information on all modification operations performed on the database, such as insert, update, delete, etc. Binlog is very important for data recovery, master-slave replication, incremental backup, and audit monitoring. Relay-log is a log unique to the server where the standby database is located in the MySQL replication architecture, and it plays a vital role in the master-slave replication process. When the data changes on the server where the master database is located are recorded in the binlog, the I / O (input / output) thread of the server where the standby database is located will read these logs and write them to the local relay log. Subsequently, the server where the standby database is located will read the transactions in the relay log and apply them to the slave server to ensure data consistency between the master and slave servers.

[0048] S102: The coordinator parses the transaction in the relay-log, determines the modified row in the transaction and the number of modification times of the modified row, and constructs the row identifier of the modified row.

[0049] In this embodiment, the coordinator may parse the transactions in the relay-log. Specifically, to ensure that the transactions are parsed in the order in which the primary database executes the transactions, the coordinator may search and parse the transactions from the relay-log based on the transaction ID (Identity Document) in ascending order.

[0050] For any transaction obtained by parsing, this embodiment can parse the transaction to determine the modified row in the transaction and the row modification times of the modified row. The modified row in this embodiment can be a row whose data or structure changes through database statement operation, and the row modification times can be the number of times the modified row is modified.

[0051] In this embodiment, each transaction can make multiple changes to multiple rows, so this embodiment does not limit the number of modified rows parsed in each transaction, nor does it limit the number of row modifications for each modified row.

[0052] In this embodiment, a row identifier of the modified row can be constructed as a unique mark of the modified row. This embodiment does not limit the specific method of constructing the row identifier of the modified row. Generally, the row identifier of the modified row can be constructed based on the library name, table name, unique key and unique key value of the modified row; or, the row identifier of the modified row can be constructed based on the library name, table name, unique index and unique index value of the modified row. The row identifier in this embodiment can be considered as a key in a hash table.

[0053] S103: Determine a hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier using a first hash algorithm and a second hash value obtained by calculating the row identifier using a second hash algorithm.

[0054] This embodiment can determine the hash value of the row identifier. When the hash table is a two-layer hash table, the hash value of the row identifier in this embodiment can include the operation values ​​of two hash algorithms. Specifically, the hash value of the row identifier includes the first hash value obtained by the first hash algorithm for the row identifier and the second hash value obtained by the second hash algorithm for the row identifier. When the hash table is a two-layer or higher hash table, the hash value of the row identifier can include the operation values ​​of two or more hash algorithms. This embodiment does not limit the specific type of hash algorithm, and it can generally be set based on actual applications.

[0055] In this embodiment, the first layer of the double-layer hash table can generally be used to store the first hash value of the row identifier, and the second layer of the double-layer hash table can generally be used to store the second hash value and value of the row identifier. Each hash table can be empty when it is first generated.

[0056] S104: When the hash value of the row identifier is stored in the hash table, the hash table storing the hash value of the row identifier is determined as the target hash table.

[0057] S105: When the hash value of the row identifier is not stored in the hash table, a target hash table is randomly determined from the hash table, and the hash value of the row identifier is stored in the target hash table.

[0058] The hash value in this embodiment can be the mapping value of the row identifier. Based on the hash value stored in the hash table, the modified row that is being or waiting to be updated in the child thread can be determined. Therefore, this embodiment can implement the principle that two transactions that update the same row must be assigned to the same child thread based on the matching result between the hash value of the row identifier and the hash value stored in the hash table; the same transaction cannot be split and must be placed in the same child thread.

[0059] In this embodiment, the transaction thread allocation can be achieved by determining the target hash table from the hash table. Since the same transaction cannot be split and must be placed in the same sub-thread, in this embodiment, each transaction corresponds to a target sub-thread, and the hash table of the target sub-thread can be the target hash table.

[0060] The row identifier referred to in this embodiment is the row identifier of the modified row parsed from the transaction to be allocated. In this example, the sub-threads can be allocated to the transactions in sequence until all transactions are executed.

[0061] In this embodiment, for any transaction, when the hash value of the row identifier of the modified row in the transaction is not stored in the hash table, the target hash table is randomly determined from the hash table, and the hash value of the row identifier is stored in the target hash table, and the execution statement of the modified row in the transaction is placed.

[0062] That is, there is no execution statement in the child thread to update the modified row in the transaction. At this time, the transaction can be assigned to any child thread by randomly determining the target hash table from the hash table.

[0063] In this embodiment, when the hash value of the row identifier is stored in the hash table, the hash table storing the hash value of the row identifier is determined as the target hash table. Since multiple modified rows may be parsed in a transaction, that is, there are multiple row identifiers of modified rows, this embodiment needs to consider multiple situations.

[0064] First, when the hash values ​​of all row identifiers are stored in one hash table, the hash table storing the hash values ​​of all row identifiers is determined as the target hash table. That is, no matter how many row identifiers there are, if the hash values ​​of all row identifiers are stored in the same hash table, the hash table storing the hash values ​​of all row identifiers can be determined as the target hash table.

[0065] Secondly, when the hash values ​​of some row identifiers are stored in one hash table, and the hash values ​​of another part of row identifiers are not stored in the hash table, the hash table storing the hash values ​​of the part of row identifiers is determined as the target hash table. That is, when the number of row identifiers is two or more, if the hash values ​​of some row identifiers are stored in one hash table, and the hash values ​​of the remaining other part of row identifiers are not stored in the hash table, the hash table storing the hash values ​​of the part of row identifiers can be directly determined as the target hash table, and there is no conflict with the principle that two transactions updating the same row are assigned to different sub-threads.

[0066] Finally, when the hash values ​​of all row identifiers are stored in multiple different hash tables, the transaction is placed in the coordinator for waiting until the hash values ​​of some row identifiers are stored in one hash table, and the hash values ​​of the other row identifiers are not stored in the hash table. That is, when the number of row identifiers is two or more, if the hash values ​​of all row identifiers of the row identifier are stored in multiple different hash tables, at this time, no matter which hash table containing the hash value of the row identifier is determined as the target hash table, there will be a principle that does not conform to the two transactions that update the same row are assigned to different child threads. Therefore, this embodiment needs to place the transaction in the coordinator for waiting, waiting for the child thread to process the execution statement, until the hash values ​​of some row identifiers are stored in one hash table, and the hash values ​​of the other row identifiers are not stored in the hash table. At this time, the hash table storing the hash values ​​of some row identifiers can be directly determined as the target hash table, and there is no conflict with the principle that the two transactions that update the same row are assigned to different child threads. At this time, the partial row identifiers stored in a hash table can be one or more.

[0067] S106: Update the corresponding value in the target hash table based on the number of row modification times, assign the transaction to the target sub-thread of the target hash table, and delete the hash value and corresponding value of the row identifier in the target hash table after the execution statement of the modified row in the target sub-thread is executed.

[0068] This embodiment can update the corresponding value in the target hash table based on the number of row modifications. Specifically, this embodiment can add the value of the hash value of the row identifier in the target hash table to the corresponding number of row modifications. By reading the value in the target hash table, the number of modifications to the modified row in the target child thread can be determined.

[0069] This embodiment can assign transactions to the target subthread of the target hash table, and execute the execution statement in the transaction in the subthread. The transaction is assigned to the corresponding target subthread in sequence to achieve multi-thread synchronization between the master and standby databases and reduce the master and standby delay.

[0070] In this embodiment, for any transaction, when the execution statement of the modified row in its corresponding target sub-thread is executed, the hash value of the row identifier and the corresponding value value in the target hash table need to be deleted to indicate that there is no modification statement corresponding to the modified row in the target thread, so as to ensure that the principle of two transactions updating the same row are assigned to the same sub-thread is implemented.

[0071] Specifically, the value in this embodiment can represent the number of times the corresponding modified row needs to be updated in the target child thread, that is, the total number of row modifications. Whenever a transaction is completed, the value must be subtracted from the corresponding number of row modifications in the transaction until all transactions including the update of the corresponding modified row are completed, that is, when the value is 0, it can be considered that the execution statements for the corresponding modified row in the target child thread have been completed, and the hash value of the row identifier of the corresponding modified row in the target hash table and the corresponding value can be deleted.

[0072] Based on the above embodiments, the method of the present invention realizes multi-thread allocation and operation of transactions through a double-layer hash table, improves the synchronization efficiency of the standby database, reduces the master-standby delay, and ensures the efficiency of allocating sub-threads after the coordinator parses the transaction through the double-layer hash table, while reducing the probability of hash collision.

[0073] The following combination Figure 2 , Figure 2 A structural block diagram of a database master-slave replication device provided by an embodiment of the present invention, the device may include:

[0074] The first module 100 is used to create multiple sub-threads on the server where the standby database is located through the coordinator, build a hash table for each of the sub-threads, and synchronize transactions from the binlog of the primary database to the relay-log of the standby database; the hash table is a double-layer hash table;

[0075] The second module 200 is used to parse the transaction in the relay-log through the coordinator, determine the modified row in the transaction and the number of row modifications of the modified row, and construct the row identifier of the modified row;

[0076] The third module 300 is used to determine the hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier using a first hash algorithm and a second hash value obtained by calculating the row identifier using a second hash algorithm;

[0077] A fourth module 400 is configured to, when the hash value of the row identifier is stored in the hash table, determine the hash table storing the hash value of the row identifier as a target hash table;

[0078] A fifth module 500 is used to randomly determine a target hash table from the hash table when the hash value of the row identifier is not stored in the hash table, and store the hash value of the row identifier in the target hash table;

[0079] The sixth module 600 is used to update the corresponding value in the target hash table based on the number of row modifications, assign the transaction to the target sub-thread of the target hash table, and delete the hash value and corresponding value of the row identifier in the target hash table after the execution statement of the modified row in the target sub-thread is executed.

[0080] Based on the above embodiments, the method of the present invention realizes multi-thread allocation and operation of transactions through a double-layer hash table, improves the synchronization efficiency of the standby database, reduces the master-standby delay, and ensures the efficiency of allocating sub-threads after the coordinator parses the transaction through the double-layer hash table, while reducing the probability of hash collision.

[0081] Based on the above embodiment, the fourth module 400 may include:

[0082] A first unit is configured to, when the hash values ​​of all the row identifiers are stored in one hash table, determine the hash table storing the hash values ​​of all the row identifiers as the target hash table;

[0083] A second unit is configured to, when the hash values ​​of some of the row identifiers are stored in one of the hash tables and the hash values ​​of another part of the row identifiers are not stored in the hash table, determine the hash table storing the hash values ​​of some of the row identifiers as the target hash table;

[0084] The third unit is used to put the transaction into the coordinator to wait when the hash values ​​of all the row identifiers are stored in multiple different hash tables, until the hash values ​​of some of the row identifiers are stored in one of the hash tables and the hash values ​​of another part of the row identifiers are not stored in the hash table.

[0085] Based on the above embodiments, the second module 200 may include:

[0086] A fourth unit is used to construct a row identifier of the modified row based on the library name, table name, unique key and the value of the unique key of the modified row;

[0087] The fifth unit is used to construct a row identifier of the modified row based on the library name, the table name, the unique index and the value of the unique key of the modified row.

[0088] Based on the above embodiments, the sixth module 600 may include:

[0089] The sixth unit is used to add the value of the hash value of the row identifier in the target hash table to the corresponding row modification times.

[0090] Based on the above embodiments, the first module 100 may include:

[0091] The seventh unit is used to create a plurality of sub-threads on the server through the coordinator based on the remaining resources of the server.

[0092] Based on the above embodiments, the second module 200 may include:

[0093] The eighth unit is used to search and parse transactions from the relay-log through the coordinator based on the transaction ID in ascending order.

[0094] Based on the above embodiments, the hash table is a double-layer or higher-layer hash table; accordingly, the hash value of the row identifier includes operation values ​​of two or more hash algorithms.

[0095] Based on the above embodiments, the present invention also provides a database master-slave replication device, which may include a memory and a processor, wherein a computer program is stored in the memory, and when the processor calls the computer program in the memory, the steps provided in the above embodiments may be implemented. Of course, the device may also include various necessary network interfaces, power supplies, and other components.

[0096] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by an execution terminal or a processor, the method provided in the embodiment of the present invention can be implemented; the storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0097] In this article, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

Claims

1. A database master-slave replication method, characterized in that: include: Create multiple child threads on the server where the standby database is located through the coordinator, build a hash table for each child thread, and synchronize transactions from the binlog of the primary database to the relay-log of the standby database; The hash table is a double-layer hash table; Parsing the transaction in the relay-log through the coordinator, determining the modified row in the transaction and the number of row modifications of the modified row, and constructing the row identifier of the modified row; Determine a hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier using a first hash algorithm and a second hash value obtained by calculating the row identifier using a second hash algorithm; When the hash value of the row identifier is stored in the hash table, determining the hash table storing the hash value of the row identifier as a target hash table; When the hash value of the row identifier is not stored in the hash table, randomly determining a target hash table from the hash table, and storing the hash value of the row identifier in the target hash table; Based on the number of row modifications, the corresponding value in the target hash table is updated, and the transaction is assigned to the target sub-thread of the target hash table. When the execution statement of the modified row in the target sub-thread is executed, the hash value and the corresponding value of the row identifier in the target hash table are deleted.

2. The database master-slave replication method according to claim 1, characterized in that: When the hash value of the row identifier is stored in the hash table, determining the hash table storing the hash value of the row identifier as the target hash table includes: When the hash values ​​of all the row identifiers are stored in one hash table, determining the hash table storing the hash values ​​of all the row identifiers as the target hash table; When the hash values ​​of some of the row identifiers are stored in one of the hash tables, and the hash values ​​of another part of the row identifiers are not stored in the hash table, determining the hash table storing the hash values ​​of some of the row identifiers as the target hash table; When the hash values ​​of all the row identifiers are stored in multiple different hash tables, the transaction is placed in the coordinator to wait until the hash values ​​of some of the row identifiers are stored in one of the hash tables and the hash values ​​of another part of the row identifiers are not stored in the hash table.

3. The database master-slave replication method according to claim 1, characterized in that: The step of constructing the row identifier of the modified row includes: Constructing a row identifier of the modified row based on the library name, table name, unique key and the value of the unique key of the modified row; Or, a row identifier of the changed row is constructed based on the library name, the table name, the unique index and the value of the unique index of the changed row.

4. The database master-slave replication method according to claim 1, characterized in that: The updating of the corresponding value in the target hash table based on the row modification times includes: Add the value of the hash value of the row identifier in the target hash table to the corresponding row modification times.

5. The database master-slave replication method according to claim 1, characterized in that: The step of creating multiple child threads on the server where the standby database is located by the coordinator includes: A plurality of the sub-threads are created on the server through the coordinator based on the remaining resources of the server.

6. The database master-slave replication method according to claim 1, characterized in that: The parsing of the transaction in the relay-log by the coordinator includes: The coordinator searches and parses transactions from the relay-log based on the transaction ID in ascending order.

7. The database master-slave replication method according to claim 1, characterized in that: The hash table is a double-layer or higher-layer hash table; accordingly, the hash value of the row identifier includes the operation values ​​of two or more hash algorithms.

8. A database master-slave replication device, characterized in that: include: The first module is used to create multiple sub-threads on the server where the standby database is located through the coordinator, build a hash table for each of the sub-threads, and synchronize transactions from the binlog of the primary database to the relay-log of the standby database; The hash table is a double-layer hash table; The second module is used to parse the transaction in the relay-log through the coordinator, determine the modified row in the transaction and the number of row modifications of the modified row, and construct the row identifier of the modified row; The third module is used to determine the hash value of the row identifier; the hash value of the row identifier includes a first hash value obtained by calculating the row identifier using a first hash algorithm and a second hash value obtained by calculating the row identifier using a second hash algorithm; A fourth module is used for determining the hash table storing the hash value of the row identifier as a target hash table when the hash value of the row identifier is stored in the hash table; A fifth module, configured to, when the hash value of the row identifier is not stored in the hash table, randomly determine a target hash table from the hash table, and store the hash value of the row identifier in the target hash table; The sixth module is used to update the corresponding value in the target hash table based on the number of row modifications, assign the transaction to the target sub-thread of the target hash table, and delete the hash value and corresponding value of the row identifier in the target hash table after the execution statement of the modified row in the target sub-thread is executed.

9. A database master-slave replication device, characterized in that: include: Memory, for storing computer programs; A processor, configured to implement the database master-slave replication method as claimed in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the database master-slave replication method according to any one of claims 1 to 7 is implemented.

Images