Method and system for synchronizing main database and standby database

Abstract

The invention provides a main and standby database synchronization method and system, belongs to the technical field of data synchronization, is applied to a home-end database and an opposite-end database, and is characterized in that when to-be-synchronized database tables in the home-end database and the opposite-end database execute insertion or record modification, synchronization fields of corresponding records are set as current timestamps; when the record needs to be deleted, the synchronization field of the corresponding record is set to be the number opposite to the number of the current timestamp, and the method comprises the steps that a to-be-synchronized database table record in a local end database is obtained; for each to-be-synchronized database table record, judging whether a corresponding synchronization field is greater than 0: when the synchronization field is greater than 0, updating an opposite-end database table record; and when the synchronization field is smaller than 0, deleting an opposite-end database table record. The method has the beneficial effects that the main and standby synchronization of the lightweight database is realized, the synchronization mechanism does not need to depend on third-party software, various database systems are directly supported, and the applicability is relatively wide.

Description

Technical Field

[0001] The present invention relates to the technical field of data synchronization, and in particular to a database master-slave synchronization method and system. Background Art

[0002] Database master-slave synchronization refers to the process of achieving real-time or scheduled data replication and consistency maintenance between different database systems according to preset policies and rules. This is one of the important means to ensure high data availability and disaster recovery capabilities, which is particularly important for distributed systems and cloud computing environments.

[0003] At present, there are two common methods for implementing database master-slave synchronization. The first method is to use the synchronization function that comes with the database. This function is usually integrated in large database systems, such as MySQL. By configuring the corresponding synchronization parameters, different synchronization strategies can be implemented, such as real-time synchronization, scheduled synchronization, or asynchronous replication. However, different database systems have different synchronization mechanisms and configuration methods, and the configuration operation is difficult and complicated. Moreover, the synchronization function that comes with the database is not flexible enough in controlling the synchronization process, and it is difficult to meet the user's needs for customized synchronization control. For example, the user wants to prohibit synchronization within a specific time range, or set different synchronization priorities for different database tables, or take specific processing methods when there is a synchronization conflict (such as modifications to both the master and standby databases). These requirements are often difficult to achieve with the existing database synchronization function.

[0004] Another common implementation method is to use cluster management software. This type of software usually supports multiple operating systems and database systems, and can flexibly cope with multiple scenarios such as synchronous and asynchronous replication and shared storage. However, the deployment process of cluster management software is relatively complex, requiring users to have a high level of technical skills and rich experience. At the same time, the cost of cluster management software is also high, which may be a considerable burden for projects or enterprises with limited budgets.

[0005] In summary, the current typical implementation methods of database master-slave synchronization have many shortcomings. First, the deployment is complex and costly. Whether using the database's own synchronization function or cluster management software, it takes a lot of time and resources to deploy and configure. Second, there are large differences in deployment methods under different operating systems and database systems, which increases the difficulty for users to learn and master. Third, the existing implementation methods are insufficient in customized synchronization control and it is difficult to meet users' needs for flexible synchronization control. Finally, since embedded systems usually have higher requirements for resource consumption and real-time performance, these implementation methods are also challenging to deploy in embedded usage scenarios. Summary of the invention

[0006] In order to solve the above technical problems, the present invention provides a database master-slave synchronization method; on the other hand, it also provides a database master-slave synchronization system.

[0007] The technical problem solved by the present invention can be achieved by adopting the following technical solutions:

[0008] A first aspect of the present invention is to provide a database master-slave synchronization method, which is applied to a local database and a peer database. When inserting or modifying a record, the local database and the database table to be synchronized in the peer database set the synchronization field of the corresponding record to the current timestamp, and when deleting a record, the synchronization field of the corresponding record is set to the opposite number of the current timestamp. The database master-slave synchronization method includes:

[0009] Get the database table records to be synchronized in the local database;

[0010] For each database table record to be synchronized, determine whether the corresponding synchronization field is greater than 0:

[0011] When the synchronization field is greater than 0, update the database table record of the other end;

[0012] When the synchronization field is less than 0, the database table record of the opposite end is deleted.

[0013] Preferably, updating the peer database table record includes:

[0014] Initiate an insert operation to the peer database;

[0015] When the insert operation succeeds, the update is determined to be successful.

[0016] Preferably, the updating of the peer database table record further includes:

[0017] When the insert operation fails, initiating an update operation to the peer database;

[0018] During the update operation, determine whether the local synchronization field is smaller than the absolute value of the peer synchronization field:

[0019] If yes, the peer database has been updated;

[0020] If not, the peer synchronization field is set to 0 during the update operation, and the update is determined to be successful at the end of the update operation.

[0021] Preferably, the updating of the peer database table record further includes:

[0022] When the database table record on the other end is updated successfully, the synchronization field on the local end is set to 0.

[0023] Preferably, deleting the peer database table record includes:

[0024] Initiate a deletion operation to the peer database, and during the deletion operation, determine whether the absolute value of the local synchronization field is less than the peer synchronization field:

[0025] If yes, the peer database has been updated;

[0026] If not, the peer synchronization field is set to 0 during the delete operation.

[0027] Preferably, the deleting the peer database table record further includes:

[0028] When the records in the database table on the other end are deleted successfully, the records in the database table on the local end are deleted.

[0029] Preferably, the current timestamp is the system time when the insert, modify or delete operation is performed.

[0030] Preferably, when inserting, modifying or deleting records in the database table, the database master-slave synchronization method is triggered in real time.

[0031] A second aspect of the present invention is to provide a database master-slave synchronization system for implementing the above-mentioned database master-slave synchronization method, the system comprising:

[0032] The local database and the peer database, wherein the database tables to be synchronized in the local database and the peer database set the synchronization field of the corresponding record to the current timestamp when inserting or modifying a record, and set the synchronization field of the corresponding record to the opposite number of the current timestamp when deleting a record;

[0033] A to-be-synchronized record acquisition unit, used to acquire to-be-synchronized database table records in the local database;

[0034] A synchronization unit, connected to the to-be-synchronized record acquisition unit, is used to determine whether the corresponding synchronization field is greater than 0 for each to-be-synchronized database table record, and to update the opposite-end database table record when the synchronization field is greater than 0, and to delete the opposite-end database table record when the synchronization field is less than 0.

[0035] Preferably, the current timestamp is the system time when the insert, modify or delete operation is performed.

[0036] The advantages or beneficial effects of the technical solution of the present invention are:

[0037] The present invention realizes a lightweight database master-slave synchronization method by setting the synchronization fields of the records to be synchronized in the local and opposite end databases to the current timestamp when inserting or modifying, and to the opposite number of the current timestamp when deleting. The synchronization mechanism does not need to rely on third-party software, directly supports various database systems, and has wide applicability. At the same time, the synchronization mechanism is simple and the resource occupation is extremely low, which is very suitable for deployment in various embedded devices and embedded application scenarios that meet high availability requirements. In addition, it also supports master-slave synchronization between heterogeneous database systems, allowing the master and standby databases to adopt different database systems, which provides great convenience for scenarios where heterogeneous databases are used simultaneously, such as database upgrade, replacement, migration, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 A flowchart of a method for synchronizing a master database with a standby database in a preferred embodiment of the present invention;

[0039] Figure 2 A state transition diagram of database master-slave synchronization in a preferred embodiment of the present invention;

[0040] Figure 3 This is a structural block diagram of a database master-slave synchronization system in a preferred 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] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0043] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but they are not intended to limit the present invention.

[0044] See also Figure 1 In a preferred embodiment of the present invention, based on the above problems existing in the prior art, a database master-slave synchronization method is provided, which is applied to a local database and a peer database. When inserting or modifying a record, the synchronization field of the corresponding record in the local database and the peer database to be synchronized is set to the current timestamp, and when deleting a record, the synchronization field of the corresponding record is set to the opposite number of the current timestamp. The database master-slave synchronization method includes:

[0045] S100, obtaining the database table records to be synchronized in the local database;

[0046] S200: for each database table record to be synchronized, determine whether the corresponding synchronization field is greater than 0:

[0047] S300, when the synchronization field is greater than 0, update the database table record of the peer end;

[0048] S400, when the synchronization field is less than 0, delete the database table record at the other end.

[0049] Specifically, in this embodiment, an additional synchronization field SyncFlag is added to the database tables in the local database and the peer database that need to be synchronized. The value of this field is related to the timestamp corresponding to the execution of the insert, modify or delete operation.

[0050] Preferably, the timestamp may be the system time.

[0051] Specifically, when a record is inserted or added to a database table, the synchronization field SyncFlag is configured as the current system time, indicating that the record is in a state to be synchronized.

[0052] When a record is modified, the synchronization field SyncFlag is configured with the current system time, indicating that the record is in a state to be synchronized.

[0053] When a record needs to be deleted, the synchronization field SyncFlag is configured as the opposite of the current system time (ie, a negative value, whose absolute value is the current system time), indicating that the record is in a state to be synchronized.

[0054] The present invention uses the SyncFlag field to mark the status of database records and performs synchronization operations according to these statuses. The value of the SyncFlag field not only indicates the time of inserting, modifying and deleting records, but also distinguishes the types of inserting, modifying and deleting operations by positive and negative signs.

[0055] Furthermore, during the database master-slave synchronization process, first, regularly check whether there is a database table to be synchronized in the local database (ie, the local database). If there is a database table to be synchronized, retrieve the database table record to be synchronized, and then initiate a data synchronization operation.

[0056] For each database table record to be synchronized, a judgment is made based on the value of its synchronization field SyncFlag: if the synchronization field SyncFlag is greater than 0, it means that the record needs to be updated to the peer database. If SyncFlag is less than 0, it means that the record needs to be deleted from the peer database.

[0057] Furthermore, when the database table record is synchronized, it is necessary to perform corresponding operations on the local database table to indicate that the record has been synchronized and no further synchronization is required.

[0058] Specifically, for records whose synchronization field SyncFlag is greater than 0, the synchronization field SyncFlag corresponding to the record in the local database table needs to be set to 0 after synchronization is completed.

[0059] For records whose synchronization field SyncFlag is less than 0, the local database table records must be deleted after synchronization is completed.

[0060] As a preferred implementation, updating the peer database table record includes:

[0061] Initiate an insert operation to the peer database;

[0062] When the insert operation succeeds, the update is determined to be successful.

[0063] As a preferred implementation, updating the peer database table record further includes:

[0064] When the insert operation fails, an update operation is initiated to the peer database;

[0065] During the update operation, determine whether the local synchronization field is smaller than the absolute value of the peer synchronization field:

[0066] If yes, the peer database has been updated, and the update is determined to have failed;

[0067] If not, the peer synchronization field is set to 0 during the update operation, and the update is determined to be successful at the end of the update operation.

[0068] As a preferred implementation, updating the peer database table record further includes:

[0069] When the database table record on the other end is updated successfully, the synchronization field on the local end is set to 0.

[0070] Specifically, in this embodiment, if the synchronization field SyncFlag corresponding to the database table record is greater than 0, an insert operation is first attempted to be initiated to the peer database. If the insertion is successful, it is considered to be an update success, and the synchronization field SyncFlag of the local database record is set to 0.

[0071] If the insert fails, an update operation is initiated instead.

[0072] During the update process, it is necessary to determine whether the synchronization field SyncFlag recorded in the local database is less than the absolute value of the synchronization field SyncFlag recorded in the peer database:

[0073] If the synchronization field SyncFlag recorded in the local database is smaller than the absolute value of the synchronization field SyncFlag recorded in the peer database, it means that the peer database table record has been updated and cannot be overwritten.

[0074] If the synchronization field SyncFlag recorded in the local database is not less than the absolute value of the synchronization field SyncFlag recorded in the peer database, the update can be performed, and during the update process, the synchronization field SyncFlag recorded in the peer database is set to 0.

[0075] After the database is updated successfully, the synchronization field SyncFlag of the local database record is configured to 0.

[0076] Furthermore, updating the peer database table record also includes:

[0077] When the peer database table record update fails, wait for the next synchronization.

[0078] As a preferred implementation, deleting the peer database table record includes:

[0079] Initiate a deletion operation to the peer database, and during the deletion operation, determine whether the absolute value of the local synchronization field is less than the peer synchronization field:

[0080] If yes, the peer database has been updated and the deletion is determined to have failed;

[0081] If not, the peer synchronization field is set to 0 during the delete operation.

[0082] As a preferred implementation, deleting the peer database table record further includes:

[0083] When the records in the database table on the other end are deleted successfully, the records in the database table on the local end are deleted.

[0084] Specifically, in this embodiment, if the synchronization field SyncFlag of the local database record is less than 0, a deletion operation is initiated to the peer database. If the deletion is successful, the corresponding record in the local database is deleted; if the deletion fails, the synchronization fails and waits for the next synchronization.

[0085] During the deletion process, it is necessary to determine whether the absolute value of the synchronization field SyncFlag recorded in the local database is less than the synchronization field SyncFlag recorded in the peer database table:

[0086] If the absolute value of the synchronization field SyncFlag of the local database record is smaller than the synchronization field SyncFlag of the peer database table record, it means that the peer database table record has been updated and cannot be deleted;

[0087] If the absolute value of the synchronization field SyncFlag recorded in the local database is not less than the synchronization field SyncFlag recorded in the opposite database table, the deletion operation can be performed, and after the deletion is successful, the corresponding record in the local database is deleted.

[0088] Furthermore, deleting the records in the peer database table also includes:

[0089] When the peer database table record deletion fails, wait for the next synchronization.

[0090] As a preferred implementation, the current timestamp is the system time when the insert, modify or delete operation is performed.

[0091] Specifically, when an insert, modify or delete operation is performed, the corresponding synchronization field SyncFlag is configured as the current operation time to facilitate data synchronization management.

[0092] For example, assuming that the current system time is 10:49:30, and a delete operation is performed on the local database, the current time is first converted to a timestamp format, and then its negative value is taken, and the negative timestamp is assigned to the synchronization field SyncFlag. The synchronization field SyncFlag not only records the time when the delete operation occurs, but also clearly identifies the operation type as a delete through a negative value.

[0093] Furthermore, during implementation, the above database master-slave synchronization method is mainly used as a software implementation, such as synchronization software, to achieve data synchronization between the master and standby databases, ensuring data consistency in a relatively short period of time.

[0094] The method shown in the present invention is applied in a dual-host environment, and the synchronization software constructed by the database master-slave synchronization method of the present invention needs to be installed on both hosts.

[0095] In the dual-host architecture, including a first host and a second host, the database in the first host is recorded as the first database, and the database in the second host is recorded as the second database.

[0096] If the method shown in the present invention is applied on the first host, the first database is regarded as the local database, and the second database is regarded as the peer database.

[0097] Correspondingly, if the method shown in the present invention is applied on the second host, the second database is regarded as the local database, and the first database is regarded as the opposite database.

[0098] like Figure 2 A database synchronization state transition diagram is shown. Figure 2In the figure, S1 represents the value of the synchronization field SyncFlag corresponding to the database table record to be synchronized in the local database, and S2 represents the value of the synchronization field SyncFlag corresponding to the database table record to be synchronized in the peer database.

[0099] The database synchronization state migration includes two parts. The solid line part is the state change caused by the local database operation, and the dotted line part is the state change caused by the peer operation (database synchronization).

[0100] The database synchronization state migration mechanism consists of two major components: the solid line part is the state transition triggered by the local database operation, and the dotted line part is the state migration caused by the peer database operation (i.e., the database synchronization process).

[0101] The state migration caused by local database operations is as follows:

[0102] 1. If the current record is empty, when a record is inserted, the state will be migrated to the state of S1>0, which is the state of inserting and synchronizing.

[0103] 2. When S1>0 is in the state, if the record is modified, the value of S1 is updated according to the system time of the most recent modification operation to reflect the latest modification status.

[0104] 3. When S1>0 is in the state, if the record needs to be deleted, the value of S1 will be updated to negative (ie S1<0) according to the system time of the most recent deletion operation (the record has not been deleted at this time, and the local record will be deleted after subsequent synchronization with the other end). At this time, the record is in the deletion state to be synchronized.

[0105] 4. When S1>0 is in the state, if the synchronization with the peer database is successful, S1 is updated to 0, indicating that the synchronization operation on this end has been completed. At this time, the record is in the synchronization success state.

[0106] 5. When S1<0 is on, if a new record is inserted, the value of S1 is updated. At this time, the record is in the state of inserting and waiting for synchronization.

[0107] 6. In the S1<0 state, if the synchronization with the peer database is successful, the record will be deleted and the record will be empty.

[0108] 7. When S1=0, if the record is modified, the S1 value is updated. At this time, the record is in the insert-to-be-synchronized state.

[0109] 8. In the S1=0 state, if the record needs to be deleted, the S1 value is updated with a negative sign (S1<0). At this time, the record is in the deletion pending synchronization state.

[0110] The state migration caused by peer database operations is as follows:

[0111] 1. When S1=0 and S2>0, after the peer end is successfully synchronized, the local end database table records are updated and S1=0 is configured;

[0112] 2. When S1=0 and S2<0, after the peer end is successfully synchronized, the local end database table record is deleted and the record is empty;

[0113] 3. When S1>0, S2>=S1 (at this time, S2>0 indicates that the peer end has an updated insert or modify operation). After the peer end is successfully synchronized, the local end database table record is updated, and S1=0;

[0114] 4. In the state of S1<0, S2>=-S1 (at this time, S2>0 indicates that the peer end has an updated insert or modify operation). After the peer end is synchronized successfully, the local end database table record is updated, and S1=0;

[0115] 5. In the state of S1>0, -S2>=S1 (at this time S2<0, indicating that the peer end has an updated deletion operation), after the peer end is successfully synchronized, the local end database table record is deleted and the record is empty;

[0116] 6. In the state of S1<0, S2<=S1 (at this time S2<0, indicating that the other end has an updated deletion operation), after the synchronization of the other end is successful, the database table record of this end is deleted and the record is empty.

[0117] In the above process, updating or deleting local database table records may fail, but it will not affect the normal operation of the system.

[0118] For records that failed to synchronize, the synchronization software will continue to resynchronize these records, or synchronize the local database table records through database synchronization after the other end database table records have new updates.

[0119] As a preferred implementation, when inserting, modifying or deleting records in a database table, a database master-slave synchronization method is triggered in real time.

[0120] Specifically, the existing database table records to be synchronized are synchronized in a regular manner, and the database table records to be synchronized are synchronized at fixed time intervals. However, this method may cause synchronization conflicts after the primary and standby switches.

[0121] For example, after the first host (i.e., the master state) modifies the database table record at time T1, if a master-slave switch occurs later, the second host (which has switched to the master state) modifies the database table record again at time T2, and due to the large clock difference between the two hosts, the value of T2 is smaller than T1, then a synchronization conflict will occur, and the consequence is that the later modification will be overwritten by the earlier modification.

[0122] In order to reduce the possibility of synchronization conflicts, the embodiment of the present invention adopts a real-time triggered master-slave synchronization method when data changes. When a record in a database table changes, a master-slave synchronization request is immediately initiated, and master-slave synchronization is initiated in time, thereby avoiding synchronization conflicts caused by the need for data synchronization on both hosts.

[0123] Usually, the host needs to synchronize its clock with the clock server to ensure that the clock difference between the two hosts will be very small, generally not exceeding 10 milliseconds. When the master-slave switch occurs, it takes a certain amount of time for the backup machine to enter the master state. This time is usually in seconds, much longer than 100 milliseconds. Therefore, the data changes that occur after the switch have been greatly reduced due to the impact of the clock difference, and synchronization conflicts can basically be avoided.

[0124] Therefore, in order to ensure that there is no conflict during the synchronization process, a highly reliable clock synchronization mechanism must be ensured. In this way, even in the case of active-standby switching, data consistency and integrity can be ensured, thus avoiding problems such as data overwriting or loss.

[0125] The present invention also provides a database master-slave synchronization system for implementing the above-mentioned database master-slave synchronization method. Figure 3 As shown, the system includes:

[0126] The local database and the peer database, the database tables to be synchronized in the local database and the peer database set the synchronization field of the corresponding record to the current timestamp when inserting or modifying records, and set the synchronization field of the corresponding record to the opposite number of the current timestamp when deleting records;

[0127] The to-be-synchronized record acquisition unit 1 is used to acquire the to-be-synchronized database table records in the local database;

[0128] The synchronization unit 2 is connected to the to-be-synchronized record acquisition unit 1, and is used to determine whether the corresponding synchronization field is greater than 0 for each to-be-synchronized database table record, and to update the peer database table record when the synchronization field is greater than 0, and to delete the peer database table record when the synchronization field is less than 0.

[0129] Specifically, in this embodiment, an additional synchronization field SyncFlag is added for the database tables to be synchronized in the local database and the peer database that need to be synchronized. The value of this field is related to the timestamp corresponding to the execution of the insert, modify or delete operation.

[0130] Specifically, when a record is inserted or added to a database table, the synchronization field SyncFlag is configured to the current system time; when a record is modified, the synchronization field SyncFlag is updated to the system time of the latest modification; and when a record needs to be deleted, the synchronization field SyncFlag is set to the opposite of the current system time (i.e. a negative value, whose absolute value is the current system time). The value of the synchronization field SyncFlag indicates that the record is in a state to be synchronized.

[0131] The present invention utilizes the SyncFlag field to mark the status of database table records. The value of this field not only indicates the time of executing inserting, modifying and deleting records, but also distinguishes the types of inserting, modifying and deleting operations by positive and negative signs.

[0132] Furthermore, during the database master-slave synchronization process, first, regularly check whether there is a database to be synchronized in the local database (i.e., the local database). If there is a database to be synchronized, retrieve the database table record to be synchronized, and then initiate the data synchronization operation:

[0133] For each database table record to be synchronized, determine whether the value of its synchronization field SyncFlag is greater than 0:

[0134] If the synchronization field SyncFlag is greater than 0, it means that the record needs to be updated to the peer database, that is, update the peer database record. Specifically, first use insert. If the insertion fails, use update to update the record. When updating the record, it is necessary to determine whether the synchronization field SyncFlag of the local database table record is less than the absolute value of the synchronization field SyncFlag of the peer database table record. If it is less than, it means that the content of the peer database table record has been updated and cannot be overwritten; otherwise, it can be updated. When updating, set the synchronization field SyncFlag of the peer database table record to 0, and when the operation is successful, update the synchronization field SyncFlag of the local database table record to 0. If the update fails, wait for the next synchronization;

[0135] If the synchronization field SyncFlag is less than 0, a deletion operation is initiated to the peer database. When deleting the peer database table record, it is necessary to determine whether the absolute value of the synchronization field SyncFlag of the local database table record is less than the value of the synchronization field SyncFlag of the peer database table record; if it is less, it means that the content of the peer database table record is updated and cannot be deleted; otherwise, it can be deleted, and when the peer database table record is successfully deleted, the local database table record is deleted. If the deletion fails, the synchronization fails and waits for the next synchronization.

[0136] As a preferred implementation, the current timestamp is the system time when the insert, modify or delete operation is performed.

[0137] Specifically, during the implementation process, the above database master-slave synchronization method is mainly configured in a computer system as a software implementation, such as a database master-slave synchronization system, for realizing data synchronization between master and slave databases to ensure data consistency in a relatively short time.

[0138] The advantages or beneficial effects of adopting the above technical solution are:

[0139] (1) By adding a synchronization field, the value of the synchronization field is related to the timestamp. Specifically, the synchronization field is set to the current timestamp when inserting or modifying, and is set to the opposite of the current timestamp when deleting. The synchronization field not only indicates the time when inserting, modifying, and deleting records are executed, but also distinguishes the types of inserting, modifying, and deleting operations by positive and negative signs.

[0140] (2) The master-slave database synchronization mechanism is simple and does not require reliance on third-party software;

[0141] (3) Supports various database systems and has wide applicability;

[0142] (4) The synchronization mechanism is simple, the software is compact, and it takes up very little resources. It can be deployed on various embedded devices and is suitable for embedded application scenarios that require active-standby redundancy to meet high availability requirements.

[0143] (5) Supports master-slave synchronization between heterogeneous database systems. The master and slave databases can use different database systems, which is suitable for scenarios where heterogeneous databases are used simultaneously, such as database upgrade, replacement, and migration.

[0144] The above are only preferred embodiments of the present invention, and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the contents of this specification and illustrations should be included in the protection scope of the present invention.

Claims

1. A database master-slave synchronization method, characterized in that: Applied to a local database and a peer database, the database tables to be synchronized in the local database and the peer database set the synchronization field of the corresponding record to the current timestamp when inserting or modifying a record, and set the synchronization field of the corresponding record to the opposite number of the current timestamp when deleting a record. The database master-slave synchronization method includes: Get the database table records to be synchronized in the local database; For each database table record to be synchronized, determine whether the corresponding synchronization field is greater than 0: When the synchronization field is greater than 0, update the database table record of the other end; When the synchronization field is less than 0, the database table record of the opposite end is deleted.

2. The database master-slave synchronization method according to claim 1, characterized in that: The updating of the peer database table record includes: Initiate an insert operation to the peer database; When the insert operation succeeds, the update is determined to be successful.

3. The database master-slave synchronization method according to claim 2, characterized in that: The updating of the peer database table record also includes: When the insert operation fails, initiating an update operation to the peer database; During the update operation, determine whether the local synchronization field is smaller than the absolute value of the peer synchronization field: If yes, the peer database has been updated; If not, the peer synchronization field is set to 0 during the update operation, and the update is determined to be successful at the end of the update operation.

4. The database master-slave synchronization method according to claim 1, characterized in that: The updating of the peer database table record also includes: When the database table record on the other end is updated successfully, the synchronization field on the local end is set to 0.

5. The database master-slave synchronization method according to claim 1, characterized in that: Deleting the records in the peer database table includes: Initiate a deletion operation to the peer database, and during the deletion operation, determine whether the absolute value of the synchronization field of the local end is less than the synchronization field of the peer end: If yes, the peer database has been updated; If not, the peer synchronization field is set to 0 during the delete operation.

6. The database master-slave synchronization method according to claim 1, characterized in that: Deleting the peer database table record also includes: When the records in the database table on the other end are deleted successfully, the records in the database table on the local end are deleted.

7. The database master-slave synchronization method according to claim 1, characterized in that: The current timestamp is the system time when the insert, modify or delete operation is performed.

8. The database master-slave synchronization method according to claim 1, characterized in that: When inserting, modifying or deleting records in the database table, the database master-slave synchronization method is triggered in real time.

9. A database master-slave synchronization system, characterized in that: The system for implementing the database master-slave synchronization method according to any one of claims 1 to 8 comprises: The local database and the peer database, wherein the database tables to be synchronized in the local database and the peer database set the synchronization field of the corresponding record to the current timestamp when inserting or modifying a record, and set the synchronization field of the corresponding record to the opposite number of the current timestamp when deleting a record; A to-be-synchronized record acquisition unit, used to acquire to-be-synchronized database table records in the local database; A synchronization unit, connected to the to-be-synchronized record acquisition unit, is used to determine whether the corresponding synchronization field is greater than 0 for each to-be-synchronized database table record, and to update the opposite-end database table record when the synchronization field is greater than 0, and to delete the opposite-end database table record when the synchronization field is less than 0.

10. The database master-slave synchronization system according to claim 9, characterized in that: The current timestamp is the system time when the insert, modify or delete operation is performed.

Images