Data redundancy in a distributed relational database also provides different ways for users on the distributed relational database network to access a database on the network.
The considerations a distributed relational database administrator examines to create a data redundancy strategy are more complex than ensuring communications paths are available to the data.
Tables can be replicated across servers in the network, or a snapshot of data can be used to provide data availability. DataPropagator™ for iSeries™, V8.1 can provide this capability.
The following figure shows that a copy of the MP000 server distributed relational database can be stored on the KC000 server, and a copy of the KC000 server distributed relational database can be stored on the MP000 server. The application requester (AR) from one region can link to the other application server (AS) to query or to update a replicated copy of their relational database.
The administrator must decide what is the most efficient, effective strategy to allow distributed relational database processing. Alternative strategies might include these scenarios.
One alternative might be that when MP000 is unavailable, its ARs connect to the KC000 server to query a read-only snapshot of the MP000 distributed relational database so service work can be scheduled.
DataPropagator for iSeries, V8.1 can provide a read-only copy (or snapshot) of the tables to a remote server on a regular basis. For the Spiffy Corporation, this might be at the end or the beginning of each business day. In this example, the MP000 database snapshot provides a 24-hour-old, last-point-in-time picture for dealerships to use for scheduling only. When the MP000 server is back on line, its ARs query the MP000 distributed relational database to completely process inventory requests or other work queried on the snapshot.
Another alternative might be that Spiffy Corporation wants dealership users to be able to update a replicated table at another AS when their regional AS is unavailable.
For example, an AR that normally connects to the MP000 database could connect to a replicated MP000 database on the KC000 server to process work. When the MP000 server is available again, the MP000 relational database can be updated by applying journal entries from activity originating in its replicated tables at the KCOOO location. When these journal entries have been applied to the original MP000 tables, distributed relational database users can access the MP000 as an AS again.
Journal management processes on each regional server update all relational databases. The amount of journal management copy activity in this situation should be examined because of potential adverse performance effects at these servers.