Synchronizing databases

[0002] This invention relates to synchronizing databases.

[0003] Copying changes made in one database to another database is known as database synchronization. Synchronization is typically performed to ensure that changes made to a master database are propagated to its slave databases and vice versa. A master database is one that maintains sets of data tables that are referenced by the slave databases, often in a so-called “hub and spoke” arrangement.

[0004] FIG. 1 is a block diagram of a computer system that includes master and slave databases.

[0005] FIG. 2 is a flowchart showing a process for synchronizing the master and slave databases shown in FIG. 1.

[0006] FIG. 1 shows a hub and spoke database arrangement 10, which includes one or more computers connected via a network, such as a local area network (LAN), a wide area network (WAN), and/or the Internet. Computers 11, 12 and 14 may be servers, personal computers (PCs), or any other type of processing device that is capable of managing a database.

[0007] Computer 11 manages a master database 15. Master database 15 is stored in memory 16 or other storage area of computer 11 (see view 17). A “master” database management application 19 (hereinafter “master application”), which includes computer-executable instructions, is also stored in memory 16. Processor 20 executes master application 19 to perform the “master” portion of the database synchronization process 21 of FIG. 2. The master portion of process 21 is shown on the right side of FIG. 2.

[0008] Computers 12 and 14 manage slave databases 22 and 24 respectively. For the purposes of this disclosure, computers 12 and 14, and respective databases 22 and 24, are identical. Accordingly, only slave database 22 and corresponding computer 12 are described in detail. It is noted, however, that process 21 is not limited to use with identical databases and computers. Also, although only two slave databases are shown, process 21 can be used to synchronize any number of databases.

[0009] Slave database 22 is stored in memory 25 or other storage area of computer 12 (see view 26). Slave database 22 may be identical to master database 15 or it may contain a subset thereof. A “slave” database management application 27 (hereinafter “slave application”), which includes computer-executable instructions, is also stored in memory 25. Processor 29 executes slave application 27 to perform the “slave” portion of database synchronization process 21. The slave portion of process 21 is on the left side of FIG. 2. Process 21 is described with respect to slave database 22, even though it is also performed by other databases in communication with master database 15.

[0010] Process 21 includes preprocessing phase 30, post phase 31, and get phase 32. The post and get phases are so named because they refer to a slave database “posting” its changes to the master database and the slave database “getting” changes from the master database.

[0011] The schema (S) of master database 15 includes a set of tables (T) and is defined as follows

[0012] S_M={T_M1, T_M2. . . T_Mn},

[0013] where the “M” stands for “master”. Each T_Mi(i≦n) is a table in master database 15. Each table, T_Mi, is defined by rows and columns (C), such that

[0014] T_Mi={C_M1, C_M2. . . C_Mn}.

[0015] In preprocessing phase 30, master application 19 assigns (201) an “age variable” (A_i) column to each table T_Mi. The age variable is indicative of a number of changes made to a row in master database 15, as described below. Thus, each T_Miis defined as

[0016] T_Mi={C_M1, C_M2. . . C_Mn, A_i}.

[0017] Master application 19 also defines (202) a global age variable A_Mfor master database 15 and stores A_Min association with master database 15. A_Mis initialized to zero (0), as is every A_ivalue in T_Mi. From this point on, for every database operation that inserts or updates a row in any table of master database 15, master application 19 increments A_Mby one and sets the A_ivalue in the row to the new A_Mvalue. When a row is deleted, master application 19, instead of actually deleting the row in master database 15, increments the value of A_Mto indicate a database operation and sets the A_ivalue in the deleted row to be the negative of A_M(−A_M)

[0018] Thus, master application 19 maintains the global age A_Mfor master database 15 and records changes to each row in master database 15 by incrementing A_Meach time a change (update, insert, or delete) occurs and setting that row's A_ivalue equal to the incremented A_Mvalue or its negative.

[0019] Referring now to slave database 22, the schema (S) of slave database 22 includes a set of tables (T) and is defined as follows

[0020] S_S={T_S1, T_s2. . . T_Sn},

[0021] where the “S” stands for “slave”. Each T_Si(i≦n) is a table in slave database 22. Each table, T_Siis defined by rows and columns (C), such that

[0022] T_Si={C_S1, C_S2. . . C_Sn}.

[0023] The schema of slave database 22 can be identical to, or a subset of, the schema of master database 15.

[0024] In preprocessing phase 30, slave application 27 defines (203) a global age variable A_Sfor slave database 22 and stores A_Sin association with slave database 22. A_Sis initialized to zero (0) when slave database 22 is initially created. The value of AA_Sis modified when a synchronization operation occurs, as described below.

[0025] The operations that occur during preprocessing phase 30 need not occur in the order described above. For example, the slave operations may occur before the master operations or the two may occur substantially concurrently.

[0026] Slave application 27 initiates a database synchronization operation by obtaining (204) all of the changes to slave database 22 that were made since a last database synchronization operation. Slave application 27 may keep a record, e.g., in memory 25, of the changes to slave database 22 as they occur. Slave application 27 obtains this record from memory and sends (205) the changes to master application 19 (on computer 11).

[0027] Master application 19 receives (206) the changes from slave application 27 and integrates (207) the changes to slave database 22 into master database 15. For example, master application 19 makes any updates (e.g., to A_Mand A_Mi), additions or deletions to rows/columns of master database 15 that were previously made to slave database 22.

[0028] Slave application 27 reverts (208) slave database 22 back to its state at the time of the previous synchronization operation, i.e., before any of the changes sent (205) to master database were made. These changes are re-incorporated into slave database 22 via master database 15, as described below.

[0029] Slave application 27 initiates get phase 32 by sending (209) the slave age variable (data) A_Sto master application 19. Master application 19 receives A_Sand determines (210), based on A_S, which rows of master database have changed since the last synchronization operation and, thus, which rows should be sent to slave database 22 during synchronization. This is done by comparing the value of A_S, to the value A_Miof each row. If A_Miis greater than A_S, master application 19 knows that the row corresponding to A_Mihas changed since the last synchronization operation. In addition, master application 19 queries master database 15 for all rows having an age that is less than the value of −A_S. This is done to determine if a row has been deleted from master database 15.

[0030] Once master application 19 determines which rows of master database 15 have changed (i.e., been updated, added or deleted) since the last synchronization operation, master application 19 gathers the changes and sends (211) the changes to slave application 27 (on computer 12). Slave application 27 receives the changes and integrates (212) the changes into slave database 22. Master application 19 sends slave application 27 enough information about the changed rows (e.g., primary keys and the like) to allows slave application 27 to integrate the changes into slave database 22. Master application 19 also sends (211) slave application the global age variable AM. Slave application 27 receives AM and assigns the value of A_Mto A_S, to record, at the slave database, the “age” of the master database at the time of the last synchronization operation, where “age” is measured by A_M.

[0031] Process 21 is not limited to use with the database configurations shown in FIG. 1 or to use with the hardware and software FIG. 1; it may find applicability in any computing or processing environment. Process 21 may be implemented in hardware, software, or a combination of the two. Process 21 may be implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device to perform process 21 and to generate output information.

[0032] Each such program may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language. The language may be a compiled or an interpreted language.

[0033] Each computer program may be stored on a storage medium or device (e.g., CD-ROM, hard disk, or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform process 21. Process 21 may also be implemented as a computer-readable storage medium, configured with a computer program, where, upon execution, instructions in the computer program cause the computer to operate in accordance with process 21.

[0034] Process 21, implemented by master application 19 and slave application 27, is executed outside of a database management system (DBMS). This allows synchronization to occur without a direct connection between the master and slave database systems. Process 21 can be used with any database schema and can be used to synchronize any changed portions of two databases, not just rows as described herein.

[0035] Other embodiments not described herein are also within the scope of the following claims.