With solidDB^® advanced replication data synchronization, you can store, manage, and synchronize data across databases.

The advanced replication data synchronization functionality is built into the solidDB^® server. It uses all the capabilities that solidDB^® provides, such as transactions and SQL to provide a rich set of data distribution features.

As a simple example, suppose that you manage an enterprise that has multiple branch offices. You might want to give every branch office or user a local copy of your database so that each user gets the fastest possible response time. But If each office has its own copy of the database, the database can become inconsistent over time, as various data is updated in numerous databases of the system. The advanced replication feature provides the flexibility and fast access of providing local copies of the database, while maintaining the data consistency of the data of the distributed system.

Tip: The advanced replication feature is sometimes referred to as SmartFlow.

In solidDB^® advanced replication, a master database contains the master copy of the data. One or more replica databases contain full or partial copies of the master data. A replica database, like any other database, can contain multiple tables. Some tables can contain only replicated data (copied from the master), some local-only data (not copied from the master), and some a mix of replicated data and local-only data.

Each server in the advanced replication system can have its own local copy of the data that it needs. There is no need to provide users with online access to central data management resources. In addition, each replica database of an advanced replication system can serve a specific purpose. For example, one replica can be dedicated to a decision support or reporting application, while another is dedicated to an online transaction processing application.

In a multi-database system, where updates can occur in multiple databases periodically, maintaining data integrity poses challenges. For example, a technician in the field might update a customer’s address on a local replica, while a customer service person at the main office might update the customer’s address in the master database. When the replica is reconnected to the network, whose data takes precedence if the data does not match?

With the advanced replication transaction management architecture, application developers can build transaction validation capabilities into the transaction itself. You can write your own application-specific business rules and logic to resolve conflicts if they occur.

Advanced replication also provides the Intelligent Transaction feature that helps application developers control the consistency of the master database. The Intelligent Transaction feature allows a transaction to validate itself in the master database and adjust its behavior to ensure the validity of the transaction.

You can synchronize data between the master and replicas on intervals of your choice using pull-based replication models. You can also disconnect local copies of the database from the network and then reconnect them later. Each time you reconnect, you can synchronize bidirectionally. You send the latest version of your local data to the master server, and download the latest data from the master to your local replica server. Replicas can submit updates to the master server, which then verifies the updates according to rules set by the application programmers. The verified data is then published and made available to all replicas.

Each user or office can also be given only the slice of information that is relevant to their work. Partitioning the data reduces the bandwidth required to synchronize databases across a network. You can also use partitioning to increase data security by limiting access without requiring all data to be stored in a single secure location.

Application developers can also tailor the synchronization process to maximize performance. For example, large amounts of data can be transferred over the network when the available bandwidth is optimal. Similarly, you can specify that only high-priority transactions that reflect urgent data are propagated during rush hours.