mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
108 lines
5.4 KiB
HTML
108 lines
5.4 KiB
HTML
<?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>Clock Skew</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
|
||
<link rel="up" href="rep.html" title="Chapter 12. Berkeley DB Replication" />
|
||
<link rel="prev" href="rep_ryw.html" title="Read your writes consistency" />
|
||
<link rel="next" href="repmgr_channels.html" title="Using Replication Manager message channels" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.2</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Clock Skew</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="rep_ryw.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 12.
|
||
Berkeley DB Replication
|
||
</th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="repmgr_channels.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="rep_clock_skew"></a>Clock Skew</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Since master leases take into account a timeout that is used across
|
||
all sites in a replication group, leases must also take into account
|
||
any known skew (or drift) between the clocks on different machines
|
||
in the group. The guarantees provided by master leases take clock
|
||
skew into account. Consider a replication group where a client's
|
||
clock is running faster than the master's clock and the group has
|
||
a lease timeout of 5 seconds. If clock skew is not taken into
|
||
account, eventually, the client will believe that 5 seconds have
|
||
passed faster than the master and that client may then grant its
|
||
lease to another site. Meanwhile, the master site does not believe
|
||
5 seconds have passed because its clock is slower, and it believes
|
||
it still holds a valid lease grant. For this reason, Berkeley DB compensates
|
||
for clock skew.</p>
|
||
<p>The master of a group using leases must account for skew
|
||
in case that site has the slowest clock in the group. This computation
|
||
avoids the problem of a master site believing a lease grant is valid
|
||
too long. Clients in a group must account for skew in case they
|
||
have the fastest clock in the group. This computation avoids
|
||
the problem of a client site expiring its grant too soon and
|
||
potentially granting a lease to a different site. Berkeley DB uses
|
||
a conservative computation and accounts for clock skew on both
|
||
sides, yielding a double compensation.</p>
|
||
<p>The <a href="../api_reference/C/repclockskew.html" class="olink">DB_ENV->rep_set_clockskew()</a> method takes the values for both the fastest
|
||
and slowest clocks in the entire replication group as parameters.
|
||
The values passed in must be the same for all sites in the group.
|
||
If the user knows the maximum clock drift of their sites, then those
|
||
values can be expressed as a relative percentage. Or, if the user
|
||
runs an experiment then the actual values can be used.</p>
|
||
<p>For example, suppose the user knows that there is a maximum drift
|
||
rate of 2% among sites in the group. The user should pass in
|
||
102 and 100 for the fast and slow clock values respectively.
|
||
That is an unusually large value, so suppose, for example, the
|
||
rate is 0.03% among sites in the group. The user should pass in
|
||
10003 and 10000 for the fast and slow clock values. Those values
|
||
can be used to express the level of precision the user needs.</p>
|
||
<p>An example of an experiment a user can run to help determine skew
|
||
would be to write a program that started simultaneously on all
|
||
sites in the group. Suppose, after 1 day (86400 seconds), one
|
||
site shows 86400 seconds and the other site shows it ran faster
|
||
and it indicates 86460 seconds has passed.
|
||
The user can use 86460 and 86400 for their parameters for the
|
||
fast and slow clock values.</p>
|
||
<p>Since Berkeley DB is using those fast and slow clock values to compute
|
||
a ratio internally, if the user cannot detect or measure any
|
||
clock skew, then the same value should be passed in for both
|
||
parameters, such as 1 and 1.</p>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="rep_ryw.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="rep.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="repmgr_channels.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Read your writes consistency </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Using Replication Manager message channels</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|