From b7f024eb48c38acadd7e0c1ba2cb08db48582460 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Tue, 9 Oct 2012 12:17:11 -0400 Subject: [PATCH 1/4] DOCS-297 migrated distributed locking info to manual --- source/administration/monitoring.txt | 2 ++ source/core/sharding-internals.txt | 18 +++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/source/administration/monitoring.txt b/source/administration/monitoring.txt index bd2631eeddc..27cfae4b965 100644 --- a/source/administration/monitoring.txt +++ b/source/administration/monitoring.txt @@ -228,6 +228,8 @@ design patterns. In other situations, performance issues may indicate that the database may be operating at capacity and that it's time to add additional capacity to the database. +.. _administration-monitoring-locks: + Locks ~~~~~ diff --git a/source/core/sharding-internals.txt b/source/core/sharding-internals.txt index a884bde8140..e122570eaef 100644 --- a/source/core/sharding-internals.txt +++ b/source/core/sharding-internals.txt @@ -348,10 +348,26 @@ The migration process ensures consistency and maximizes availability of chunks during balancing: when MongoDB begins migrating a chunk, the database begins copying the data to the new server and tracks incoming write operations. After migrating chunks, the "from" :program:`mongod` -sends all new writes, to the "receiving" server. Finally, +sends all new writes to the "receiving" server. Finally, :program:`mongos` updates the chunk record in the :term:`config database` to reflect the new location of the chunk. +Distributed Locking +``````````````````` + +The mongoDB distributed :ref:`locking ` +mechanism is used to coordinate activities across a multi-server mongoDB +installation. In mongoDB versions 1.8 and earlier, the integrity of +distributed locks depends critically on accurate timekeeping between all +:program:`mongos` instances creating the distributed locks. In +particular, if the clock skew between :program:`mongos` instances grows +beyond approximately 5 minutes, there is an increasing probability that +locks will fail, resulting data loss. + +For this reason, we strongly recommend that all systems running with +mongoDB versions 1.8 and earlier use Network Time Protocol (NTP) or +otherwise ensure that all clocks are accurate. + .. _sharding-migration-thresholds: Migration Thresholds From 06bc160a0a3e124888521c820dc22c94ebf667a2 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Tue, 9 Oct 2012 12:21:42 -0400 Subject: [PATCH 2/4] DOCS-297 minor edit --- source/core/sharding-internals.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/core/sharding-internals.txt b/source/core/sharding-internals.txt index e122570eaef..6ac1b14509b 100644 --- a/source/core/sharding-internals.txt +++ b/source/core/sharding-internals.txt @@ -359,10 +359,10 @@ The mongoDB distributed :ref:`locking ` mechanism is used to coordinate activities across a multi-server mongoDB installation. In mongoDB versions 1.8 and earlier, the integrity of distributed locks depends critically on accurate timekeeping between all -:program:`mongos` instances creating the distributed locks. In -particular, if the clock skew between :program:`mongos` instances grows -beyond approximately 5 minutes, there is an increasing probability that -locks will fail, resulting data loss. +:program:`mongos` and :program:`mongod` instances creating the +distributed locks. In particular, if the clock skew between +:program:`mongos` instances grows beyond approximately 5 minutes, there +is an increasing probability that locks will fail, resulting data loss. For this reason, we strongly recommend that all systems running with mongoDB versions 1.8 and earlier use Network Time Protocol (NTP) or From f0dc84aa7d0364123f725801ab81a26f26614764 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Tue, 9 Oct 2012 12:23:58 -0400 Subject: [PATCH 3/4] DOCS-297 minor edit --- source/core/sharding-internals.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/core/sharding-internals.txt b/source/core/sharding-internals.txt index 6ac1b14509b..e07bd3809c6 100644 --- a/source/core/sharding-internals.txt +++ b/source/core/sharding-internals.txt @@ -362,7 +362,8 @@ distributed locks depends critically on accurate timekeeping between all :program:`mongos` and :program:`mongod` instances creating the distributed locks. In particular, if the clock skew between :program:`mongos` instances grows beyond approximately 5 minutes, there -is an increasing probability that locks will fail, resulting data loss. +is an increasing probability that locks will fail, resulting in data +loss. For this reason, we strongly recommend that all systems running with mongoDB versions 1.8 and earlier use Network Time Protocol (NTP) or From cc81ef4b04d91068f38d060626cca0a4aad56ffe Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Tue, 9 Oct 2012 13:33:25 -0400 Subject: [PATCH 4/4] DOCS-297 turned info into a note --- source/administration/monitoring.txt | 2 -- source/core/sharding-internals.txt | 20 ++++---------------- 2 files changed, 4 insertions(+), 18 deletions(-) diff --git a/source/administration/monitoring.txt b/source/administration/monitoring.txt index 27cfae4b965..bd2631eeddc 100644 --- a/source/administration/monitoring.txt +++ b/source/administration/monitoring.txt @@ -228,8 +228,6 @@ design patterns. In other situations, performance issues may indicate that the database may be operating at capacity and that it's time to add additional capacity to the database. -.. _administration-monitoring-locks: - Locks ~~~~~ diff --git a/source/core/sharding-internals.txt b/source/core/sharding-internals.txt index e07bd3809c6..4edcf78b785 100644 --- a/source/core/sharding-internals.txt +++ b/source/core/sharding-internals.txt @@ -352,22 +352,10 @@ sends all new writes to the "receiving" server. Finally, :program:`mongos` updates the chunk record in the :term:`config database` to reflect the new location of the chunk. -Distributed Locking -``````````````````` - -The mongoDB distributed :ref:`locking ` -mechanism is used to coordinate activities across a multi-server mongoDB -installation. In mongoDB versions 1.8 and earlier, the integrity of -distributed locks depends critically on accurate timekeeping between all -:program:`mongos` and :program:`mongod` instances creating the -distributed locks. In particular, if the clock skew between -:program:`mongos` instances grows beyond approximately 5 minutes, there -is an increasing probability that locks will fail, resulting in data -loss. - -For this reason, we strongly recommend that all systems running with -mongoDB versions 1.8 and earlier use Network Time Protocol (NTP) or -otherwise ensure that all clocks are accurate. +.. note:: Before MongoDB version 2.0, increasing clock skew between + :program:`mongos` instances could lead to failed distributed locks + and potential data loss, particularly if the skew exceeded 5 minutes. + Always run ``ntpd`` to minimize clock skew. .. _sharding-migration-thresholds: