Replication in ElevateDB is accomplished using several different aspects of the product and includes the capability to replicate virtually any type of data, including but not limited to, updates to databases.

The following image illustrates the general architecture of the replication of database updates in ElevateDB:



Publishing a Database

---

The first step in configuring a replication system for database updates in ElevateDB is to publish the database(s) that you wish to replicate updates for. You can publish a database by using the PUBLISH DATABASE statement. Once a database has been published, it will begin to log all inserts, updates, and deletes that take place so that they can be saved to an update file at a later time for replicating to other copies of the same database.

Creating a Local Store

---

The next step is to create a local store where the updates can be saved. You can use the CREATE STORE statement to create the local store.

Saving the Updates to a Database

---

Once the local store has been created, you can now save the logged updates for the database to an update file in the local store using the SAVE UPDATES statement. The frequency with which the updates are saved and replicated is completely up to you, but the general rule is that you want to save the updates more frequently as the volume of updates increases in order to minimize the synchronization time.


Creating a Remote Store

---

The next step is to create a remote store (or stores, for multiple remote locations) where the update file can be copied in order to replicate it to the remote location. You can use the CREATE STORE statement to create the local store. However, in order for this new remote store to be accessible, the store at the remote location that is pointed to by the remote store must have already been created at the remote location. The replication will not work until this step has been completed at each remote location.

Replicating the Update File

---

Once the update file has been created in the local store, you can now begin the process of replicating it to other copies of the same database. Typically, there are two types of replication used:


One method is not necessarily superior to the other, and the choice of which to use usually revolves around whether the remote locations are constantly accessible to the master location. If they are not, such as is the case with salesman on the road with laptops, then the pull replication is the better choice.

Replicating an update file from a local store to a remote store, or vice-versa, is accomplished via the COPY FILE statement. Copying an update file from a local store to a remote store will cause ElevateDB to automatically log into the remote ElevateDB Server designated for the remote store, and transfer the update file to the remote store.

Loading the Updates into a Database

---

At the remote location, we will use the LOAD UPDATES statement to load the update file from a local store into the copy of the database. The update file is assumed to already be present in the local store as a result of the previous COPY FILE operation. Once the updates are loaded, the copy of the database at the remote location is now considered to be synchronized with the database at the master location.

If there are multiple update files in a local store that need to be loaded for a database, it is very important that you do not confuse the ordering of the update files and attempt to load them out-of-order. Each update file has a creation timestamp that can be used to determine which should be loaded first, second, etc. To retrieve information about the update files in a specific store, you can use the SET UPDATES STORE statement to specify the store where the update files are located, and then use a SELECT statement to query the Updates Table in the Configuration Database. The Updates table contains information about all of the update files in the store specified by the SET UPDATES STORE statement, with one row per update file.


You can use the FROM UPDATES clause of the CREATE TABLE statement to examine the contents of any update file. This is useful when you are trying to load an update file and cannot do so due to constraint violations or other types of problems.

Bi-Directional Replication

---

In addition to a scenario where a master location replicates its updates to remote locations, you can also publish the copies of the databases at the remote locations and replicate their updates back to the database at the master location. This is called bi-directional replication, and is very common. In order to set up a bi-directional replication system, you would execute the same steps as before, but you would also repeat the same steps for each of the remote locations.

Scheduling Replication

---

The actual processing of saving and loading updates, and copying the update files between different locations, can be scheduled to run as a job by using the CREATE JOB statement.

Replicating Other Types of Data

---

The replication capabilities in ElevateDB are not limited solely to database updates. Backups and other types of files can be replicated in a similar manner, and this is very useful for situations where you want remote locations to send backups and other important information to a master location where they will be stored in a more secure fashion than what might be possible at the remote location. It is also sometimes more efficient to use backups for the initial population of new remote locations instead of using one large update file, or a series of many update files. Being able to replicate backups is very useful in such a situation.