<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Replication Benefits</title> <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> <meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /> <link rel="home" href="index.html" title="Getting Started with Replicated Berkeley DB Applications" /> <link rel="up" href="introduction.html" title="Chapter 1. Introduction" /> <link rel="previous" href="introduction.html" title="Chapter 1. Introduction" /> <link rel="next" href="apioverview.html" title="The Replication APIs" /> </head> <body> <div class="navheader"> <table width="100%" summary="Navigation header"> <tr> <th colspan="3" align="center">Replication Benefits</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td> <th width="60%" align="center">Chapter 1. Introduction</th> <td width="20%" align="right"> <a accesskey="n" href="apioverview.html">Next</a></td> </tr> </table> <hr /> </div> <div class="sect1" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h2 class="title" style="clear: both"><a id="repadvantage"></a>Replication Benefits</h2> </div> </div> <div></div> </div> <p> Replication offers your application a number of benefits that can be a tremendous help. Primarily replication's benefits revolve around performance, but there is also a benefit in terms of data durability guarantees. </p> <p> Briefly, the reasons why you might choose to implement replication in your DB application are: </p> <div class="itemizedlist"> <div class="itemizedlist"> <ul type="circle"> <li> <p> Improved application reliability. </p> <p> By spreading your data across multiple machines, you can ensure that your application's data continues to be available even in the event of a hardware failure on any given machine in the replication group. </p> </li> </ul> </div> <ul type="disc"> <li> <p> Improve read performance. </p> <p> By using replication you can spread data reads across multiple machines on your network. Doing so allows you to vastly improve your application's read performance. This strategy might be particularly interesting for applications that have readers on remote network nodes; you can push your data to the network's edges thereby improving application data read responsiveness. </p> <p> Additionally, depending on how you partition your data across your replicas, any given replica may only need to cache part of your data, decreasing cache misses and reducing I/O on the client. </p> </li> <li> <p> Improve transactional commit performance </p> <p> In order to commit a transaction and achieve a transactional durability guarantee, the commit must be made <span class="emphasis"><em>durable</em></span>. That is, the commit must be written to disk (usually, but not always, synchronously) before the application's thread of control can continue operations. </p> <p> Replication allows you to avoid this disk I/O and still maintain a degree of durability by <span class="emphasis"><em>committing to the network</em></span>. In other words, you relax your transactional durability guarantees on the master, but by virtue of replicating the data across the network you gain some additional durability guarantees above what is provided locally. </p> <p> Usually this strategy is implemented using some form of an asynchronous transactional commit on the master. In this way your data writes will eventually be written to disk, but your application will not have to wait for the disk I/O to complete before continuing with its next operation. </p> <p> Note that it is possible to cause DB's replication implementation to wait to hear from one or more replica's as to whether they have successfully saved the write before continuing. However, in this case you might be trading performance for a even higher durability guarantee (see below). </p> </li> <li> <p> Improve data durability guarantee. </p> <p> In a traditional transactional application, you commit your transactions such that data modifications are saved to disk. Beyond this, the durability of your data is dependent upon the backup strategy that you choose to implement for your site. </p> <p> Replication allows you to increase this durability guarantee by ensuring that data modifications are written to multiple machines. This means that multiple disks, disk controllers, power supplies, and CPUs are used to ensure that your data modification makes it to stable storage. In other words, replication allows you to minimize the problem of a single point of failure by using more hardware to guarantee your data writes. </p> <p> If you are using replication for this reason, then you probably will want to configure your application such that it waits to hear about a successful commit from one or more replicas before continuing with the next operation. This will obviously impact your application's write performance to some degree — with the performance penalty being largely dependent upon the speed and stability of the network connecting your replication group. </p> <p> For more information, see <a href="fwrkpermmessage.html">Permanent Message Handling</a>. </p> </li> </ul> </div> </div> <div class="navfooter"> <hr /> <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td> <td width="20%" align="center"> <a accesskey="u" href="introduction.html">Up</a> </td> <td width="40%" align="right"> <a accesskey="n" href="apioverview.html">Next</a></td> </tr> <tr> <td width="40%" align="left" valign="top">Chapter 1. Introduction </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> <td width="40%" align="right" valign="top"> The Replication APIs</td> </tr> </table> </div> </body> </html>