CN115309831B

CN115309831B - Local database state synchronization method, electronic equipment and storage medium

Info

Publication number: CN115309831B
Application number: CN202211239263.9A
Authority: CN
Inventors: 封飞; 宋凡
Original assignee: Suzhou Qingying Feifan Software Technology Co ltd
Current assignee: Suzhou Qingying Feifan Software Technology Co ltd
Priority date: 2022-10-11
Filing date: 2022-10-11
Publication date: 2022-12-09
Anticipated expiration: 2042-10-11
Also published as: CN115309831A

Abstract

The application relates to the technical field of databases, in particular to a method for synchronizing local database states, electronic equipment and a storage medium, wherein the method comprises the following steps: uploading scripts from different development environments to a public storage space, and performing performance check on the scripts before the scripts enter the public storage space; acquiring all scripts required by iteration of a local database to the latest state from a public storage space; traversing executed scripts in a local database and all scripts required by iteration to the latest state to respectively generate a first script data body and a second script data body; comparing the first script data body with the second script data body to determine a script to be executed by a local database; judging the priority of the auxiliary information of the scripts to be executed by each local database based on the environment requirements of the local databases, and further determining the script execution sequence to execute the scripts to be executed by the local databases according to the execution sequence; the method facilitates the synchronization of the local database states of the research personnel.

Description

Local database state synchronization method, electronic equipment and storage medium

Technical Field

The present application relates to the field of database technologies, and in particular, to a method for synchronizing states of a local database, an electronic device, and a storage medium.

Background

In the development process of the business system, a plurality of research and development personnel are required to develop in a collaborative mode, due to the fact that the research and development directions of different research and development personnel are different, the research and development personnel in different directions use different development environments, each research and development personnel uses a local database to research and develop the business system, and the research and development of the whole business system need the database states of the research and development personnel to be consistent so as to ensure that errors cannot occur in the development process. At present, in the prior art, a script is used for recording change information of research and development personnel on a local database, and then the states of the local database are consistent through communication negotiation and script exchange execution among the research and development personnel.

Disclosure of Invention

In order to solve the defects in the prior art, the present application aims to provide a local database state synchronization method, an electronic device, and a storage medium, which are convenient for respective research and development personnel to synchronize their local databases efficiently and accurately.

In order to achieve the above object, the present application provides a method for synchronizing states of local databases, including:

uploading scripts from different development environments to a public storage space, and performing performance check on the scripts before the scripts enter the public storage space, wherein the performance check comprises a first-stage check based on SQL statement judgment of a matching rule and a second-stage check based on database explain result judgment; the step of first level checking comprises: presetting a matching rule, detecting slow queries with common characteristics in the script, and adding or modifying the matching rule in the configuration file after a new slow query with the characteristics appears;

acquiring all scripts required by iteration of a local database to the latest state from a public storage space;

traversing executed scripts in a local database and all scripts required by iteration to the latest state to respectively generate a first script data body and a second script data body; comparing the first script data body with the second script data body to determine a script to be executed by a local database;

judging the priority of the auxiliary information of the scripts to be executed by each local database based on the environment requirements of the local databases, and further determining the script execution sequence to execute the scripts to be executed by the local databases according to the execution sequence;

the auxiliary information includes: the method comprises the steps that a script belongs to a database object set identifier, a script iteration version identifier, a script group identifier, a script item identifier and a name identifier of the script; the group identification comprises a database operation identification, the attached information of the script of which the attached information comprises the database operation identification further comprises an environment identification, and the environment identification comprises a general environment identification and a specific environment identification.

The step of judging the priority of the auxiliary information of the script to be executed by each local database specifically comprises the following steps: judging the script iteration version identification priority to preferentially execute scripts with low iteration versions; judging the priority of the script item identifier to preferentially execute the script with high item identifier priority; judging the priority of the script database object set identifier to preferentially execute scripts with high priority of the script database object set identifier; judging the priority of the script group identification to preferentially execute scripts with high script group identification priority; and judging the script name identifier to preferentially execute the script with the higher priority of the script name identifier.

Furthermore, the script is stored according to a specific directory structure, and the nodes of the specific directory structure correspond to the attached information of the script.

Furthermore, the script comprises a mongo script written by JS grammar and a MySQL script written by standard SQL grammar.

Further, the script identification further comprises: script execution identification; the script execution identifier is a value obtained by the script content through an MD5 information summarization algorithm and is used for judging whether the script is executed or not.

Further, the script name identification priority is determined by the code value sequence of the ASCII code identified by the script name.

Further, the step of judging the priority of the auxiliary information of the script to be executed by each local database and further determining the execution sequence of the script is stored in a script mode.

Further, the group identification includes a view identification, a stored procedure identification, and a table identification.

To achieve the above object, the present application provides an electronic device, comprising:

a processor;

a memory including one or more computer program modules;

wherein the one or more computer program modules are stored in the memory and configured to be executed by the processor, the one or more computer program modules for implementing the local database state synchronization method as described above.

To achieve the above objects, the present application provides a computer readable storage medium having stored thereon computer instructions which, when executed, perform the steps of the local database state synchronization method as described above.

According to the method for synchronizing the local database states, the local database states of the research and development personnel can be conveniently, efficiently and accurately synchronized in the development process of the service system, errors caused by the fact that the database states are asynchronous are avoided, and the efficiency of synchronizing the local database states of the research and development personnel and the development efficiency of the whole service system are improved.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application.

Drawings

The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the principles of the application and not limit the application. In the drawings:

FIG. 1 is a schematic flow chart of a local database state synchronization method according to the present application;

FIG. 2 is a schematic illustration of the contents of the configuration file of the present application;

FIG. 3 is a diagram of a local database script and associated information table;

FIG. 4 is a diagram illustrating a directory structure stored in a project script according to the present application;

FIG. 5 is a schematic block diagram of an electronic device of the present application;

fig. 6 is a schematic diagram of a storage medium of the present application.

Detailed Description

Embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present application are shown in the drawings, it should be understood that the present application may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more thorough and complete understanding of the present application. It should be understood that the drawings and embodiments of the present application are for illustration purposes only and are not intended to limit the scope of the present application.

It should be understood that the various steps recited in the method embodiments of the present application may be performed in a different order, and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present application is not limited in this respect.

The term "including" and variations thereof as used herein is intended to be open-ended, i.e., "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Relevant definitions for other terms will be given in the following description.

It is noted that references to "a", "an", and "the" modifications in this application are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that reference to "one or more" unless the context clearly dictates otherwise. "plurality" is to be understood as two or more.

Hereinafter, embodiments of the present application will be described in detail with reference to the accompanying drawings.

Example 1

One embodiment of the present application provides a method for synchronizing states of local databases, which is used for implementing state synchronization of local databases of research and development personnel.

Fig. 1 is a schematic flow chart of a local database state synchronization method according to the present application, and the local database state synchronization method according to the present application will be described in detail with reference to fig. 1:

step S101: uploading scripts from different development environments to a public storage space, and performing performance check on the scripts before the scripts enter the public storage space, wherein the performance check comprises a first-level check based on SQL statement judgment of a matching rule and a second-level check based on database explain result judgment;

in this embodiment, after the script is uploaded to the public storage space, it is checked whether the storage path and name of the script meet the specification to have all the attached information, where the specification is exemplarily: /{ database }/{ sprint }/{ table | data | sproc | view }/[ env: local | dev | ppe | test | prod ]/file. { sql | java | js }.

It should be noted that, in a high-concurrency application system, a storage system is responsible for persisting service data, and in order to ensure the correctness of the data, some control needs to be added during concurrent reading and writing of the data; secondly, the io operation itself is the slowest operation in the computer; and the storage server cannot be as easily expanded as the application server because it is stateful, resulting in the storage system being a performance bottleneck in the entire application system.

Therefore, in the present embodiment, performance checking is employed to check the performance of SQL in scripts uploaded to the common storage space.

Specifically, two-stage detection is performed, the first-stage detection is performance detection based on SQL statement judgment of a matching rule, the matching rule is written in a configuration file in advance, as shown in fig. 2, fig. 2 is a content schematic diagram of the configuration file of the present application, the matching rule is set in the configuration file in advance to detect slow queries with common features, and after a slow query with new features occurs, the matching rule is newly added or modified in the configuration file at any time to form positive feedback, so that the checking effect is better and better. The second-level detection is performance detection based on database explain result judgment, and the first-level detection mode has the advantages of high detection speed, but lack of precision and possible omission, so that the second-level detection is complementary with the first-level detection.

It should be noted that explain is a command provided by mysql database for explaining a specific sql execution plan, and by this command, execution steps of sql can be obtained without executing sql, such as whether an index is used, whether a full table scan is used, whether a temporary table is used, whether external ordering is used, whether an external join is used, and so on. And analyzing the execution speed of the sql statement. The result probability of the Explain statement is very high, different results represent execution speeds of different degrees, the analysis program can score different records, the execution speed score of the specified sql is finally calculated, and the slow query statement can be defined when the execution speed score exceeds a certain threshold value.

In this embodiment, the public storage space includes, but is not limited to, a mobile storage device, a fixed storage device, and a cloud storage space.

Step S102: acquiring all scripts required by iteration of a local database to the latest state from a public storage space;

step S103: traversing executed scripts in a local database and all scripts required by iteration to the latest state to respectively generate a first script data body and a second script data body; comparing the first script data body with the second script data body to determine a script to be executed by a local database;

in this embodiment, when the executed script in the local database and all scripts needed for iterating to the latest state are traversed to generate the first script data body and the second script data body, the auxiliary information of the script is determined according to the directory structure and the script name where the script is located.

In order to visually see the executed scripts of the local database, all executed scripts and part of the attached information of the scripts can be listed in a table form, for example, as shown in fig. 3, fig. 3 is a schematic diagram of a local database script and part of the attached information table, wherein the script execution identifier is a value obtained by the script content through the MD5 message digest algorithm.

In this embodiment, when determining the script to be executed by the local database by comparing the first script data body with the second script data body, determining whether the script in the second script data body exists in the local database by comparing the script execution identifier value of each script in the second script data body with the script execution identifier value in the local database script and the attached information table, and if the script exists and the corresponding successfully executed value is 1, proving that the script is the executed script, otherwise, determining that the script is the script to be executed.

Step S104: judging the priority of the auxiliary information of the scripts to be executed by each local database based on the environment requirements of the local databases, and further determining the script execution sequence to execute the scripts to be executed by the local databases according to the execution sequence;

in this embodiment, the auxiliary information includes at least: the method comprises the steps that a database object set identifier to which a script belongs, a script iteration version identifier, a script group identifier, a script item identifier and a name identifier of the script are identified; the group identification comprises a database operation identification, the attached information of the script of which the attached information comprises the database operation identification further comprises an environment identification, and the environment identification comprises a general environment identification and a specific environment identification.

In this embodiment, the group identifier further includes a view identifier, a stored procedure identifier, and a table identifier.

In the embodiment, the script is stored according to a specific directory structure, and the nodes of the directory structure, the script name and the attached information of the script correspond to each other; for example, fig. 4 is a schematic diagram of a directory structure stored in a certain project script of the present application, and as shown in fig. 4, a database node is a root node of a database of the project, a database object set identifier of the script corresponds to a node policy, an iteration version identifier of the script corresponds to node 2020_12_0, a group identifier of the script corresponds to node table, view, sproc and data, and an environment identifier of the script corresponds to node local, dev, ppe, test and prod. The scripts under the Local nodes are scripts in a general environment, the scripts under the other nodes are scripts under respective specific development environments, and the scripts under the specific development environments are selectively executed according to the needs of developers.

It is understood that the script identifier is not necessarily embodied by a specific directory storage, and any method may be used as long as the script identifier can be embodied, for example, the script identifier is used as a part of a script name.

In this embodiment, the script under the node table is a script of the operation table, the script under the node view is a script for the monogo database, the script under the node sproc is a script used in the storage process, the script under the node data is an SQL script of the operation data, the script directly under the node data is a script that needs to be executed in all research and development environments, and the scripts under the nodes local, dev, ppe, test and prod are scripts executed in a specific development environment.

It is understood that the hierarchy of nodes, the number of nodes, and the naming of the nodes can be modified adaptively according to the development of the business system.

In the embodiment, the content of the script for the mongo database is written by the JS grammar, and the rest of the script is the MySQL script written by the standard sql grammar.

Preferably, the priority of the auxiliary information of the script to be executed by each local database is judged, and then the execution sequence of the script is determined to be stored in a script mode. The step of determining the execution sequence is set as a script, so that the required scripts of state synchronization can be conveniently and automatically executed in sequence by the local database.

It should be noted that, in actual system applications, different development environments are used, and reference data of databases in different development environments may be different. For example, there is a configuration table in the database where one configuration is the product official web url address, which in the test development environment is http:// test. Biz.com, and in the product development environment is https:// www.biz.com. Therefore, when the database state is synchronized, scripts which do not belong to the development environment do not need to be executed.

It should be noted that, because the existing service systems mostly adopt a micro-service architecture, each service system often includes a plurality of sub-project components, and each sub-project has its own database. The database of different sub-items may have dependency relationship when performing database change, and the execution sequence of the script is especially important when performing state synchronization on the database having dependency relationship. For example, a sub-item of a business system has a commodity table using a commodity service database, another sub-item has an order table using an order service database, one column in the order table is a commodity ID, and a commodity type column needs to be added to the order table, so that the commodity type corresponding to the commodity ID of each order needs to be inquired from the commodity table of the commodity service database. After the whole business system updates several versions iteratively (for example, the iterative version reaches 10), the structure of the item table may be changed, for example, the name of the item type field may be modified. At this time, if it is necessary to use each database information change script to construct a new database environment, it is necessary to ensure that the states of each database are consistent, for example, when executing the change script of iteration version 5 for the order table of the order service database, it is necessary to ensure that the product table of the product service database is also in the state of iteration version 5, otherwise, the execution will fail. Therefore, when the local database performs database state synchronization, the sub-items in each service system need to execute the scripts with the same version according to the iteration version, and then execute the scripts with high iteration version.

Therefore, when the local databases are synchronized in state, the above situation needs to be considered, so that when the local databases in different environments are synchronized in state, scripts required by the environments where the databases are located can be executed in a certain order.

In the present embodiment, the step of determining the priority of the auxiliary information sequentially includes: judging the script iteration version identification priority to preferentially execute scripts with low iteration versions; judging the priority of the script item identifier to preferentially execute the script with high item identifier priority; judging the priority of the script database object set identifier to preferentially execute the script with high priority of the script database object set identifier; judging the priority of the script group identification to preferentially execute scripts with high priority of the script group identification; and judging the script name identifier to preferentially execute the script with the higher priority of the script name identifier.

It can be understood that the script iteration version identification is that the lower the iteration version is, the higher the execution priority is, for example, the execution priority of the 3 rd iteration version is higher than that of the 5 th iteration version; the priority of the item identification is generally determined according to the item importance and the dependency relationship between item databases; the priority of the database object set identifier, the group identifier, and the script name identifier may be set by user, that is, the priority order is not a mandatory fixed order, and is determined by the order of the code values of the ASCII codes of the identifiers in the present embodiment.

It is to be understood that the code values of the ASCII codes are used as the priority order in this embodiment for convenience only, and in other embodiments, the initials may also be used as the priority order.

Example 2

In this embodiment, an electronic device is further provided, and fig. 5 is a schematic block diagram of the electronic device provided in this application. As shown in fig. 5, the electronic device 130 includes a processor 131 and a memory 132. The memory 132 is used to store non-transitory computer-readable instructions (e.g., one or more computer program modules). The processor 131 is configured to execute non-transitory computer readable instructions that, when executed by the processor 131, may perform one or more of the steps of the local database state synchronization method described above.

For example, the processor 131 may be a Central Processing Unit (CPU), a Digital Signal Processor (DSP), or other form of processing unit having data processing capabilities and/or program execution capabilities, such as a Field Programmable Gate Array (FPGA), or the like; for example, the Central Processing Unit (CPU) may be an X86 or ARM architecture or the like.

For example, memory 132 may include any combination of one or more computer program products that may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory. Volatile memory can include, for example, random Access Memory (RAM), cache memory (or the like). The non-volatile memory may include, for example, read Only Memory (ROM), a hard disk, an Erasable Programmable Read Only Memory (EPROM), a portable compact disc read only memory (CD-ROM), USB memory, flash memory, and the like. One or more computer program modules may be stored on the computer-readable storage medium and executed by processor 131 to implement various functions of electronic device 130. Various applications and various data, as well as various data used and/or generated by the applications, and the like, may also be stored in the computer-readable storage medium.

It should be noted that, in the embodiment of the present application, reference may be made to the above description on the local database state synchronization method for specific functions and technical effects of the electronic device 130, and details are not described here again.

Example 3

In this embodiment, a computer-readable storage medium is further provided, and fig. 6 is a schematic diagram of a storage medium according to the present application. As shown in fig. 6, storage medium 150 is used to store non-transitory computer readable instructions 151. For example, the non-transitory computer readable instructions 151, when executed by a computer, may perform one or more steps in a method for synchronizing states of a local database according to the above description.

For example, the storage medium 150 may be applied to the electronic device 130 described above. For example, the storage medium 150 may be the memory 132 in the electronic device 130 shown in fig. 5. For example, the related description about the storage medium 150 may refer to the corresponding description of the memory 132 in the electronic device 130 shown in fig. 5, and is not repeated here.

It should be noted that the storage medium (computer-readable medium) described above in the present application may be a computer-readable signal medium or a non-transitory computer-readable storage medium or any combination of the two. The non-transitory computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the above. More specific examples of the non-transitory computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

In the present application, a non-transitory computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a non-transitory computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.

The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device.

Computer program code for carrying out operations for aspects of the present application may be written in any combination of one or more programming languages, including but not limited to an object oriented programming language such as Java, smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware. Where the name of an element does not in some cases constitute a limitation on the element itself.

The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems on a chip (SOCs), complex Programmable Logic Devices (CPLDs), and the like.

The above description is only a few embodiments of the present application and is intended to be illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the disclosure herein is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the disclosure. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the application. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A local database state synchronization method comprises the following steps:

uploading scripts from different development environments to a public storage space, and performing performance check on the scripts before the scripts enter the public storage space, wherein the performance check comprises the following steps: a first-level check based on SQL statement judgment of the matching rule and a second-level check based on database explain result judgment; the step of first level inspection comprises: presetting a matching rule, detecting slow queries with common characteristics in the script, and adding or modifying the matching rule in the configuration file after a new slow query with the characteristics appears;

traversing executed scripts in a local database and all scripts required by iteration to the latest state to respectively generate a first script data body and a second script data body;

comparing the first script data body with the second script data body to determine a script to be executed by a local database;

the auxiliary information includes: the method comprises the steps that a script belongs to a database object set identifier, a script iteration version identifier, a script group identifier, a script item identifier and a script name identifier; the script group identification comprises a database operation identification, the attached information of the script of which the attached information comprises the database operation identification also comprises an environment identification, and the environment identification comprises a general environment identification and a specific environment identification;

the step of judging the priority of the auxiliary information of the script to be executed by each local database comprises the following steps: judging the script iteration version identification priority to preferentially execute scripts with low iteration versions; judging the priority of the script item identifier to preferentially execute the script with high item identifier priority; judging the priority of the script database object set identifier to preferentially execute the script with high priority of the script database object set identifier; judging the priority of the script group identification to preferentially execute scripts with high priority of the script group identification; and judging the script name identifier to preferentially execute the script with the higher priority of the script name identifier.

2. The method of claim 1, wherein the script is stored in a specific directory structure, and the nodes of the specific directory structure correspond to the attached information of the script.

3. The local database state synchronization method according to claim 1, wherein the script comprises a mongo script written by JS syntax and a MySQL script written by standard SQL syntax.

4. The local database state synchronization method of claim 1, wherein the auxiliary information further comprises: script execution identification; the script execution identifier is a value obtained by the script content through an MD5 information summarization algorithm and is used for judging whether the script is executed or not.

5. The local database state synchronization method as claimed in claim 1, wherein the script name identification priority is determined by a code value order of ASCII codes identified by the script name.

6. The method for synchronizing the statuses of local databases according to claim 1, wherein the step of determining the priority of the auxiliary information of the scripts to be executed by each local database and determining the execution sequence of the scripts is stored in a script manner.

7. The local database state synchronization method of claim 1, wherein the group identification further comprises a view identification, a stored procedure identification, and a table identification.

8. An electronic device, comprising:

a processor;

a memory including one or more computer program modules;

wherein the one or more computer program modules are stored in the memory and configured to be executed by the processor, the one or more computer program modules for implementing the local database state synchronization method of any of claims 1-7.

9. A computer readable storage medium having stored thereon computer instructions which, when executed, perform the steps of the local database state synchronization method of any of claims 1-7.