The following scenarios illustrate typical uses for peer-to-peer replication.
Topology That Has Two Participating Databases
Both of the preceding illustrations show two participating databases, with user traffic directed to the databases through an application server. This configuration can be used for a variety of applications, from Web sites to workgroup applications, and provides the following benefits:
-
Improved read performance, because reads are spread out over two servers.
-
Higher availability if maintenance is required or in case of failure at one node.
In both illustrations, read activity is load-balanced between the participating databases, but updates are handled differently:
-
On the left, updates are partitioned between the two servers. If the database contained a product catalog, you could, for example, have a custom application direct updates to node A for product names that start with A through M, and direct updates to node B for product names that start with N through Z. Updates are then replicated to the other node.
-
On the right, all updates are directed to node B. From there, updates are replicated to node A. If B is offline (for example, for maintenance), the application server can direct all activity to A. When B is back online, updates can flow to it, and the application server can move all updates back to B or keep directing them to A.
Peer-to-peer replication can support either approach, but the central update example on the right is also often used with standard transactional replication.
Topologies That Have Three or More Participating Databases
The preceding illustration shows three participating databases that provide data for a worldwide software support organization, with offices in Los Angeles, London, and Taipei. The support engineers at each office take customer calls and enter and update information about each customer call. The time zones for the three offices are eight hours apart, so there is no overlap in the workday. As the Taipei office closes, the London office is opening for the day. If a call is still in progress as one office is closing, the call is transferred to a representative at the next office to open.
Each location has a database and an application server, which are used by the support engineers as they enter and update information about customer calls. The topology is partitioned by time. Therefore, updates occur only at the node that is currently open for business, and then the updates flow to the other participating databases. This topology provides the following benefits:
-
Independence without isolation: Each office can insert, update, or delete data independently but can also share the data because it is replicated to all other participating databases.
-
Higher availability in case of failure or to allow maintenance at one or more of the participating databases.
The preceding illustration shows the addition of a node to the three-node topology. A node could be added in this scenario for the following reasons:
-
Because another office is opened.
-
To provide higher availability to support maintenance or increase fault tolerance if a disk failure or other major failure occurs.
Notice that in both the three- and four-node topologies, all databases publish and subscribe to all other databases. This provides maximum availability in case of maintenance needs or failure of one or more nodes. As nodes are added, you must balance availability and scalability needs against performance and the complexity of deployment and administration.