diff options
Diffstat (limited to 'docs/programmer_reference/rep_clock_skew.html')
| -rw-r--r-- | docs/programmer_reference/rep_clock_skew.html | 120 |
1 files changed, 67 insertions, 53 deletions
diff --git a/docs/programmer_reference/rep_clock_skew.html b/docs/programmer_reference/rep_clock_skew.html index 515ae468..f0980de4 100644 --- a/docs/programmer_reference/rep_clock_skew.html +++ b/docs/programmer_reference/rep_clock_skew.html @@ -3,7 +3,7 @@ <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> - <title>Clock Skew</title> + <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" /> @@ -14,17 +14,15 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> - <th colspan="3" align="center">Clock Skew</th> + <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> + <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> @@ -34,56 +32,72 @@ <div class="titlepage"> <div> <div> - <h2 class="title" style="clear: both"><a id="rep_clock_skew"></a>Clock Skew</h2> + <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> + <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 /> |