<?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>Managing Heartbeats</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="repapp.html" title="Chapter 3. The DB Replication Framework" /> <link rel="previous" href="fmwrkconnectretry.html" title="Managing Connection Retries" /> <link rel="next" href="fwrkmasterreplica.html" title="Chapter 4. Replica versus Master Processes" /> </head> <body> <div class="navheader"> <table width="100%" summary="Navigation header"> <tr> <th colspan="3" align="center">Managing Heartbeats</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="fmwrkconnectretry.html">Prev</a> </td> <th width="60%" align="center">Chapter 3. The DB Replication Framework</th> <td width="20%" align="right"> <a accesskey="n" href="fwrkmasterreplica.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="heartbeats"></a>Managing Heartbeats</h2> </div> </div> <div></div> </div> <p> If your replicated application experiences few updates, it is possible for the replication group to lose a master without noticing it. This is because normally a replicated application only knows that a master has gone missing when update activity causes messages to be passed between the master and clients. </p> <p> To guard against this, you can configure a heartbeat. The heartbeat must be configured for both the master and each of the clients. </p> <p> On the master, you configure the application to send a heartbeat on a defined interval when it is otherwise idle. Do this by using the <span> <tt class="literal">DB_REP_HEARTBEAT_SEND</tt> flag with the <tt class="methodname">DbEnv::rep_set_timeout()</tt> method. </span> You must also provide the method a value representing the frequency of the heartbeat. Note that the heartbeat is sent only if the system is idle. </p> <p> On the client, you configure the application to listen for a heartbeat. The time that you configure here is the amount of time the client will wait for some message from the master (either the heartbeat or some other message) before concluding that the connection is lost. You do this using the <span> <tt class="literal">DB_REP_HEARTBEAT_MONITOR</tt> flag with the <tt class="methodname">DbEnv::rep_set_timeout()</tt> method and a timeout value in microseconds. </span> </p> </div> <div class="navfooter"> <hr /> <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"><a accesskey="p" href="fmwrkconnectretry.html">Prev</a> </td> <td width="20%" align="center"> <a accesskey="u" href="repapp.html">Up</a> </td> <td width="40%" align="right"> <a accesskey="n" href="fwrkmasterreplica.html">Next</a></td> </tr> <tr> <td width="40%" align="left" valign="top">Managing Connection Retries </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> <td width="40%" align="right" valign="top"> Chapter 4. Replica versus Master Processes</td> </tr> </table> </div> </body> </html>