mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
123 lines
5.8 KiB
HTML
123 lines
5.8 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="comm_repsites.html" title="Communicating between Replication Manager Sites" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 18.1.40</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="comm_repsites.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="comm_repsites.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"> Communicating between Replication Manager Sites</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|