From 0c1133da4da8e7bc5ad289b7d97ff2cd5f844bf4 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Wed, 12 Sep 2012 17:45:07 -0400 Subject: [PATCH 1/5] DOCS-246 changes to first half of change-oplog-size --- source/tutorial/change-oplog-size.txt | 42 ++++++++++++++------------- 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/source/tutorial/change-oplog-size.txt b/source/tutorial/change-oplog-size.txt index f04ec3be624..b817b610993 100644 --- a/source/tutorial/change-oplog-size.txt +++ b/source/tutorial/change-oplog-size.txt @@ -4,37 +4,38 @@ Change the Size of the Oplog .. default-domain:: mongodb -The :term:`oplog`, which supports :term:`replication`, by creating an -:term:`idempotent` operation log that :term:`secondary` members can -use to reproduce all write operations is a :term:`capped +The :term:`oplog` supports :term:`replication` by creating an +:term:`idempotent` operation log that :term:`secondary` members +use to reproduce all write operations. The oplog is a :term:`capped collection`. While the default sizing for the oplog is big enough to -support most usage patterns there are cases that require a differently +support most usage patterns, there are cases that require a differently sized oplog. This guide describes the process for changing the size if the default size is too big or too small for the needs of your deployment. +Because the oplog is a :term:`capped collection` once you have +created an oplog, you cannot modify its size except by using the +procedure outlined in this document. + Background ---------- Most :term:`replica set` deployments will never need to modify the oplog size. In most cases the :ref:`default oplog size ` is an acceptable size. If an oplog of this -size fills up in an hour, for instance, the disk will be full in less +size fills up in an hour, for instance, the disk will fill up in less then a day (about 20 hours); if the oplog fills up in a day, the disk -will be full in less than a month (about 20 days.) +will fill up in less than a month (about 20 days.) + +.. TODO better info below on when to change oplog size Some usage patterns, however, indicate a different usage pattern. For instance, large numbers of multi-updates, a significant portion of delete operations, and in place updates can generate large numbers in short periods of time. -Because the :term:`oplog` is a :term:`capped collection` once you have -created an oplog, you cannot modify its size except by using the -procedure outlined in this document. - -.. seealso:: ":ref:`Introduction to Oplog Sizing - `." +.. seealso:: The :ref:`replica-set-oplog-sizing` topic in the :doc:`/core/replication` document. Overview -------- @@ -44,21 +45,22 @@ The procedure for changing the size of the oplog is as follows: 1. Restart the current :term:`primary` instance in the replica set in "standalone" mode, running on a different port. -2. Save the last entry from the old (current) oplog, and create a - backup of the old (current) oplog. +#. Save the last entry from the old (current) oplog and then create a + backup of the old oplog. -3. Drop the current oplog, and create a new oplog of a different size. +#. Drop the old oplog. -4. Insert the previously saved last entry from the old oplog into the - new (current) oplog. +#. Create a new oplog of a different size. -5. Restart the server as a member of the replica set on its usual +#. Insert the previously saved last entry from the old oplog into the + new oplog. + +#. Restart the server as a member of the replica set on its usual port. -6. Apply this procedure to any other member of the replica set that +#. Apply this procedure to any other member of the replica set that *could become* :term:`primary`. - Procedure --------- From 18619af3eb7376ff83881e96efe7ccbc504134ad Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 13 Sep 2012 13:12:33 -0400 Subject: [PATCH 2/5] DOCS-246 changes to all of change-oplog-size --- source/administration/replica-sets.txt | 63 ++----- source/core/replication-internals.txt | 2 +- source/core/replication.txt | 20 +- source/tutorial/change-oplog-size.txt | 247 +++++++++---------------- 4 files changed, 113 insertions(+), 219 deletions(-) diff --git a/source/administration/replica-sets.txt b/source/administration/replica-sets.txt index 903633ec583..fea899177ee 100644 --- a/source/administration/replica-sets.txt +++ b/source/administration/replica-sets.txt @@ -57,8 +57,8 @@ configurations. .. _replica-set-secondary-only-members: .. _replica-set-secondary-only-configuration: -Secondary-Only -~~~~~~~~~~~~~~ +Secondary-Only Members +~~~~~~~~~~~~~~~~~~~~~~ The secondary-only configuration prevents a :term:`secondary` member in a :term:`replica set` from ever becoming a :term:`primary` in a @@ -119,8 +119,8 @@ This sets the following: .. _replica-set-hidden-members: .. _replica-set-hidden-configuration: -Hidden -~~~~~~ +Hidden Members +~~~~~~~~~~~~~~ Hidden members are part of a replica set but cannot become primary and are invisible to client applications. *However,* @@ -164,8 +164,8 @@ other members in the set will not advertise the hidden member in the .. _replica-set-delayed-members: .. _replica-set-delayed-configuration: -Delayed -~~~~~~~ +Delayed Members +~~~~~~~~~~~~~~~ Delayed members copy and apply operations from the primary's :term:`oplog` with a specified delay. If a member has a delay of one hour, then @@ -220,12 +220,9 @@ queries in normal operations. ` window, the delayed member cannot successfully replicate operations. -.. see:: For more information about delayed members, see the - section on :ref:`Delayed Replication `. - Additionally consider the following resources: - :data:`members[n].slaveDelay`, :ref:`Replica Set Reconfiguration - `, :ref:`Oplog Sizing - `, and :doc:`/tutorial/change-oplog-size`. +.. seealso:: :data:`members[n].slaveDelay`, :ref:`Replica Set Reconfiguration + `, :ref:`replica-set-oplog-sizing`, + and :doc:`/tutorial/change-oplog-size`. .. index:: replica set members; arbiters .. _replica-set-arbiters: @@ -289,8 +286,8 @@ hostname and the port. .. _replica-set-non-voting-members: .. _replica-set-non-voting-configuration: -Non-Voting -~~~~~~~~~~ +Non-Voting Members +~~~~~~~~~~~~~~~~~~ You may choose to change the number of votes that each member has in :ref:`elections ` for :term:`primary`. In general, all @@ -487,36 +484,6 @@ of the member with the highest :data:`members[n].priority` setting. ` example revolves around changing the priorities of the :data:`members` of a replica set. -.. _replica-set-procedure-change-oplog-size: - -Changing Oplog Size -~~~~~~~~~~~~~~~~~~~ - -The :term:`oplog` exists internally as a :term:`capped collection`, so -you cannot modify its size in the course of normal operations. In most -cases the :ref:`default oplog size ` is an -acceptable size; however, in some situations you may need a larger or -smaller oplog. To resize the oplog, follow these steps: - -#. Restart the current :term:`primary` instance in the :term:`replica set` in - "standalone" mode, running on a different port. - -#. Save the last entry from the old (current) oplog and create a - backup of the oplog. - -#. Drop the existing oplog and create a new oplog of a different size. - -#. Insert the previously saved last entry from the old oplog into the - new oplog. - -#. Restart the server as a member of the replica set on its usual - port. - -#. Apply this procedure to any other member of the replica set that - *could become* primary. - -.. seealso:: The :doc:`/tutorial/change-oplog-size` tutorial. - .. _replica-set-security: Security @@ -657,10 +624,10 @@ Possible causes of replication lag include: For more information see: - - the :ref:`Replication Write Concern ` section, - - the :ref:`replica-set-oplog` documentation, - - the :ref:`Oplog Sizing ` section, and - - the :doc:`/tutorial/change-oplog-size` tutorial. + - :ref:`replica-set-write-concern`. + - The :ref:`replica-set-oplog-sizing` topic in the :doc:`/core/replication` document. + - The :ref:`replica-set-oplog` topic in the :doc:`/core/replication-internals` document. + - The :doc:`/tutorial/change-oplog-size` tutorial. .. index:: pair: replica set; failover .. _replica-set-failover-administration: diff --git a/source/core/replication-internals.txt b/source/core/replication-internals.txt index b73c6802a0c..dcfe2beced4 100644 --- a/source/core/replication-internals.txt +++ b/source/core/replication-internals.txt @@ -18,7 +18,7 @@ troubleshooting and for further understanding MongoDB's behavior and approach. Oplog ----- -For an explanation of the oplog, see the :ref:`oplog ` +For an explanation of the oplog, see the :ref:`replica-set-oplog-sizing` topic in the :doc:`/core/replication` document. Under various exceptional diff --git a/source/core/replication.txt b/source/core/replication.txt index 296a2105eb5..0e144f0b2d4 100644 --- a/source/core/replication.txt +++ b/source/core/replication.txt @@ -279,7 +279,7 @@ on the :term:`primary` and then records the operations on the primary's oplog. The :term:`secondary` members then replicate this log and apply the operations to themselves in an asynchronous process. All replica set members contain a copy of the oplog, allowing them to maintain the -current state of the database. +current state of the database. The oplog is an :term:`idempotent` log. By default, the size of the oplog is as follows: @@ -297,16 +297,14 @@ By default, the size of the oplog is as follows: Before oplog creation, you can specify the size of your oplog with the :setting:`oplogSize` option. Once the oplog is created, you can only -change the size of the oplog by using the :ref:`oplog resizing procedure -`. - -.. QUESTION: SK, Can the next graph be rewritten? It's unclear to me. BG - -For example, if an oplog fits 24 hours of operations, then members can -stop copying entries from the oplog for 24 hours before they require -full resyncing *and* the disk will be full in 19 days. If this were -the case, you would have a very high-volume member. In many -circumstances, the default oplog can hold days of operations. +change the size of the oplog by using the :doc:`/tutorial/change-oplog-size` tutorial. + +In most cases, the default oplog size is sufficient. For example, if an +oplog that is 5% of free disk space fills up in an hour, then +secondaries can stop copying entries from the oplog for 20 hours before +they require full resyncing. If this were the case, you would have a +very high-volume member. In many circumstances, the default oplog can +hold days of operations. The following factors affect how MongoDB uses space in the oplog: diff --git a/source/tutorial/change-oplog-size.txt b/source/tutorial/change-oplog-size.txt index b817b610993..9d9ff2181e7 100644 --- a/source/tutorial/change-oplog-size.txt +++ b/source/tutorial/change-oplog-size.txt @@ -4,213 +4,142 @@ Change the Size of the Oplog .. default-domain:: mongodb -The :term:`oplog` supports :term:`replication` by creating an -:term:`idempotent` operation log that :term:`secondary` members -use to reproduce all write operations. The oplog is a :term:`capped -collection`. While the default sizing for the oplog is big enough to -support most usage patterns, there are cases that require a differently -sized oplog. - -This guide describes the process for changing the size if the default -size is too big or too small for the needs of your deployment. - -Because the oplog is a :term:`capped collection` once you have -created an oplog, you cannot modify its size except by using the -procedure outlined in this document. - -Background ----------- - -Most :term:`replica set` deployments will never need to modify the -oplog size. In most cases the :ref:`default oplog size -` is an acceptable size. If an oplog of this -size fills up in an hour, for instance, the disk will fill up in less -then a day (about 20 hours); if the oplog fills up in a day, the disk -will fill up in less than a month (about 20 days.) - -.. TODO better info below on when to change oplog size - -Some usage patterns, however, indicate a different usage pattern. For -instance, large numbers of multi-updates, a significant portion of -delete operations, and in place updates can generate large numbers in -short periods of time. - -.. seealso:: The :ref:`replica-set-oplog-sizing` topic in the :doc:`/core/replication` document. - -Overview --------- - -The procedure for changing the size of the oplog is as follows: - -1. Restart the current :term:`primary` instance in the replica set in - "standalone" mode, running on a different port. - -#. Save the last entry from the old (current) oplog and then create a - backup of the old oplog. - -#. Drop the old oplog. - -#. Create a new oplog of a different size. - -#. Insert the previously saved last entry from the old oplog into the - new oplog. - -#. Restart the server as a member of the replica set on its usual - port. - -#. Apply this procedure to any other member of the replica set that - *could become* :term:`primary`. +The :term:`oplog` exists internally as a :term:`capped collection`, so +you cannot modify its size in the course of normal operations. In most +cases the :ref:`default oplog size ` is an +acceptable size; however, in some situations you may need a larger or +smaller oplog. For example, you might need to change the oplog size +if your applications perform large numbers of multi-updates or +deletes in short periods of time. + +This tutorial describes how to resize the oplog. For a detailed +explanation of oplog sizing, see the :ref:`replica-set-oplog-sizing` +topic in the :doc:`/core/replication` document. For details on the how +oplog size affects :term:`delayed members ` and affects +:term:`replication lag`, see the :ref:`replica-set-delayed-members` +topic and the :ref:`replica-set-replication-lag` topic in +:doc:`/administration/replica-sets`. Procedure --------- -For the purpose of example, this document describes the process of -re-sizing the oplog on a member of the :setting:`rs0 ` -running on :setting:`port` ``27017`` with a :setting:`data directory -` of ``/srv/mongodb``. - -Quarantine the Instance -~~~~~~~~~~~~~~~~~~~~~~~ - -Issue the following command from your system shell to shutdown the -node: - -.. code-block:: sh - - mongod --dbpath /srv/mongodb --shutdown +The examples in this procedure use the following configuration: -If this node is the primary this will trigger a failover situation and -another node in the replica set will become primary. +- The active :term:`replica set` is ``rs0``. -Then restart the instance running on a different port in standalone -(i.e. without :setting:`replSet` or :option:`--replSet `,) -using the following command and the system shell: +- The replica set is running on port is ``27017``. -.. code-block:: sh +- The replica set is running with a :setting:`data directory ` + of ``/srv/mongodb``. - mongod --port 37017 --dbpath /srv/mongodb +1. Shutdown the current :term:`primary` instance in the replica set and + then restart it in "standalone" mode running on a different port. + Note that shutting down the primary will trigger a failover situation + and another member in the replica set will become primary. -Before continuing, you may want to backup the existing oplog. This -step is entirely optional. + To shut down the current primary instance, use a command that + resembles the following: -.. code-block:: sh + .. code-block:: sh - mongodump --db local --collection 'oplog.rs' --port 37017 + mongod --dbpath /srv/mongodb --shutdown -Then, connect to the instance using the :program:`mongo` shell, with -the following command to begin the procedure: + To restart the instance on a different port and in "standalone" mode + (i.e. without :setting:`replSet` or :option:`--replSet `), use a command that resembles the following: -.. code-block:: sh + .. code-block:: sh - mongo --port 37017 + mongod --port 37017 --dbpath /srv/mongodb -Save the Last Oplog Entry -~~~~~~~~~~~~~~~~~~~~~~~~~ +#. Backup the existing oplog on the standalone instance. Use the + following sequence of commands: -In the :program:`mongo` shell, you want to use the ``local`` database, -to interact with the oplog. Issue the following command: + .. code-block:: sh -.. code-block:: javascript + mongodump --db local --collection 'oplog.rs' --port 37017 - use local + Connect to the instance using the :program:`mongo` shell: -Then, use the following :method:`db.collection.save()` operation to save the last -entry in the oplog to a temporary collection: + .. code-block:: sh -.. code-block:: javascript + mongo --port 37017 - db.temp.save( db.oplog.rs.find().sort( {$natural : -1} ).limit(1).next() ) +#. Save the last entry from the old (current) oplog. -You can see this oplog entry in the ``temp`` collection by issuing -the following command: + a. In the :program:`mongo` shell, enter the following command to use the + ``local`` database to interact with the oplog: -.. code-block:: javascript + .. code-block:: javascript - db.temp.find() + use local -Resize the Oplog -~~~~~~~~~~~~~~~~ + #. Use the :method:`db.collection.save()` operation to save the last + entry in the oplog to a temporary collection: -The following operations assume that you're using the ``local`` -database. Entering ``db`` into the shell will return the name of the -current database. If this does *not* return ``local``, the ``use -local`` command will switch the shell to the ``local`` database. + .. code-block:: javascript -Drop the Existing Oplog -``````````````````````` + db.temp.save( db.oplog.rs.find().sort( {$natural : -1} ).limit(1).next() ) -Begin by dropping the existing ``oplog.rs`` collection in the -``local`` database. Use the following command: + You can see this oplog entry in the ``temp`` collection by issuing + the following command: -.. code-block:: javascript + .. code-block:: javascript - db.oplog.rs.drop() + db.temp.find() -This will return ``true`` on the shell. +#. Drop the old ``oplog.rs`` collection in the ``local`` database. Use + the following command: -Create a New Oplog -`````````````````` + .. code-block:: javascript -Use the :dbcommand:`create` command to create the new oplog. + db.oplog.rs.drop() -.. code-block:: javascript + This will return ``true`` on the shell. - db.runCommand( { create : "oplog.rs", capped : true, size : 2147483648 } ) +#. Use the :dbcommand:`create` command to create a new oplog of a + different size. Specify the ``size`` argument in bytes. A value of + ``2147483648`` will create a new oplog that's 2 gigabytes: -Specify the ``size`` argument in bytes. A value of ``2147483648`` -will create a new oplog that's 2 gigabytes. This command will return -the following status upon success: + .. code-block:: javascript -.. code-block:: javascript + db.runCommand( { create : "oplog.rs", capped : true, size : 2147483648 } ) - { "ok" : 1 } + Upon success, this command returns the following status: -Insert Saved Oplog Entry in New Oplog -````````````````````````````````````` + .. code-block:: javascript -Issue the following command to save the last entry from the oplog into -the new oplog. + { "ok" : 1 } -.. code-block:: javascript - - db.oplog.rs.save( db.temp.findOne() ) - -You can confirm that this entry is in the new oplog with the following -operation: - -.. code-block:: javascript - - db.oplog.rs.find() - -Congratulations! You have resized the oplog of this instance. +#. Insert the previously saved last entry from the old oplog into the + new oplog: -Restart Instance -~~~~~~~~~~~~~~~~ + .. code-block:: javascript -Now that the resize operation is complete, issue the following command -sequence to shut down the node and restarted in replica set mode. + db.oplog.rs.save( db.temp.findOne() ) -.. code-block:: javascript + To confirm the entry is in the new oplog, issue the following command: - mongod --dbpath /srv/mongodb --shutdown - mongod --replSet rs0 --dbpath /srv/mongodb + .. code-block:: javascript -The replica member will recover and "catch up," and then will be -eligible for election to :term:`primary`. You can use the following -command on a :program:`mongo` shell connection to the *current* -:term:`primary`. + db.oplog.rs.find() -.. code-block:: javascript +#. Restart the server as a member of the replica set on its usual + port: - rs.stepDown() + .. code-block:: javascript -This will cause the primary to step down and force an election. If -this node's :ref:`priority ` is higher than -all other nodes in the set *and* it has successfully "caught up," then -it will likely become primary. + mongod --dbpath /srv/mongodb --shutdown + mongod --replSet rs0 --dbpath /srv/mongodb -Other Replica Set Members -~~~~~~~~~~~~~~~~~~~~~~~~~ + The replica member will recover and "catch up" and then will be + eligible for election to :term:`primary`. To step down the + "temporary" primary that took over when you initially shut down the + server, use the :method:`rs.stepDown()` method. This will force an + election for primary. If the server's :ref:`priority + ` is higher than all other members in the + set *and* if it has successfully "caught up," then it will likely + become primary. -You should repeat this procedure for any member of the replica set -that *could* become primary. +#. Repeat this procedure for any other member of the replica set that + *could* become primary. From 092838c1775cfbd53d2c6734937f91730a240e1c Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 13 Sep 2012 13:46:29 -0400 Subject: [PATCH 3/5] DOCS-246 added an include on changing oplog size --- source/administration/replica-sets.txt | 16 +++++++++++++-- .../includes/procedure-change-oplog-size.rst | 20 +++++++++++++++++++ source/tutorial/change-oplog-size.txt | 10 +++++++++- 3 files changed, 43 insertions(+), 3 deletions(-) create mode 100644 source/includes/procedure-change-oplog-size.rst diff --git a/source/administration/replica-sets.txt b/source/administration/replica-sets.txt index fea899177ee..9d24c51308f 100644 --- a/source/administration/replica-sets.txt +++ b/source/administration/replica-sets.txt @@ -21,10 +21,13 @@ suggestions for administers of replica sets. The following tutorials provide task-oriented instructions for specific administrative tasks related to replica set operation. - - :doc:`/tutorial/deploy-replica-set` - - :doc:`/tutorial/expand-replica-set` + - :doc:`/tutorial/change-hostnames-in-a-replica-set` + - :doc:`/tutorial/change-oplog-size` - :doc:`/tutorial/convert-replica-set-to-replicated-shard-cluster` + - :doc:`/tutorial/convert-secondary-into-arbiter` - :doc:`/tutorial/deploy-geographically-distributed-replica-set` + - :doc:`/tutorial/deploy-replica-set` + - :doc:`/tutorial/expand-replica-set` .. _replica-set-node-configurations: .. _replica-set-member-configurations: @@ -484,6 +487,15 @@ of the member with the highest :data:`members[n].priority` setting. ` example revolves around changing the priorities of the :data:`members` of a replica set. +Changing Oplog Size +~~~~~~~~~~~~~~~~~~~ + +The following is an overview of the procedure for changing the size of the oplog: + +.. include:: /includes/procedure-change-oplog-size.rst + +For a detailed procedure, see :doc:`/tutorial/change-oplog-size`. + .. _replica-set-security: Security diff --git a/source/includes/procedure-change-oplog-size.rst b/source/includes/procedure-change-oplog-size.rst new file mode 100644 index 00000000000..529cc54ea2f --- /dev/null +++ b/source/includes/procedure-change-oplog-size.rst @@ -0,0 +1,20 @@ +1. Shut down the current :term:`primary` instance in the + :term:`replica set` and then restart it on a different port + and in "standalone" mode. + +#. Create a backup of the old (current) oplog. This is optional. + +#. Save the last entry from the old oplog. + +#. Drop the old oplog. + +#. Create a new oplog of a different size. + +#. Insert the previously saved last entry from the old oplog into the + new oplog. + +#. Restart the server as a member of the replica set on its usual + port. + +#. Apply this procedure to any other member of the replica set that + *could become* primary. \ No newline at end of file diff --git a/source/tutorial/change-oplog-size.txt b/source/tutorial/change-oplog-size.txt index 9d9ff2181e7..303194d516a 100644 --- a/source/tutorial/change-oplog-size.txt +++ b/source/tutorial/change-oplog-size.txt @@ -20,6 +20,14 @@ oplog size affects :term:`delayed members ` and affects topic and the :ref:`replica-set-replication-lag` topic in :doc:`/administration/replica-sets`. +Overview +-------- + +The following is an overview of the procedure for changing the size of +the oplog: + +.. include:: /includes/procedure-change-oplog-size.rst + Procedure --------- @@ -32,7 +40,7 @@ The examples in this procedure use the following configuration: - The replica set is running with a :setting:`data directory ` of ``/srv/mongodb``. -1. Shutdown the current :term:`primary` instance in the replica set and +1. Shut down the current :term:`primary` instance in the replica set and then restart it in "standalone" mode running on a different port. Note that shutting down the primary will trigger a failover situation and another member in the replica set will become primary. From 3643d6102cf5bdcb3c5171fc492f2df6e3a2c10a Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 13 Sep 2012 13:52:17 -0400 Subject: [PATCH 4/5] DOCS-246 added back a ref ID --- source/administration/replica-sets.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/source/administration/replica-sets.txt b/source/administration/replica-sets.txt index 9d24c51308f..8db70382a2d 100644 --- a/source/administration/replica-sets.txt +++ b/source/administration/replica-sets.txt @@ -225,7 +225,8 @@ queries in normal operations. .. seealso:: :data:`members[n].slaveDelay`, :ref:`Replica Set Reconfiguration `, :ref:`replica-set-oplog-sizing`, - and :doc:`/tutorial/change-oplog-size`. + :ref:`replica-set-procedure-change-oplog-size` in this document, + and the :doc:`/tutorial/change-oplog-size` tutorial. .. index:: replica set members; arbiters .. _replica-set-arbiters: @@ -487,6 +488,8 @@ of the member with the highest :data:`members[n].priority` setting. ` example revolves around changing the priorities of the :data:`members` of a replica set. +.. _replica-set-procedure-change-oplog-size: + Changing Oplog Size ~~~~~~~~~~~~~~~~~~~ @@ -639,6 +642,7 @@ Possible causes of replication lag include: - :ref:`replica-set-write-concern`. - The :ref:`replica-set-oplog-sizing` topic in the :doc:`/core/replication` document. - The :ref:`replica-set-oplog` topic in the :doc:`/core/replication-internals` document. + - The :ref:`replica-set-procedure-change-oplog-size` topic this document. - The :doc:`/tutorial/change-oplog-size` tutorial. .. index:: pair: replica set; failover From c5de11cadc073378b46c8bca78ac6ed29427323b Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 13 Sep 2012 14:24:51 -0400 Subject: [PATCH 5/5] DOCS-246 change to oplog example --- source/core/replication.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/core/replication.txt b/source/core/replication.txt index 0e144f0b2d4..92b4ba5bae0 100644 --- a/source/core/replication.txt +++ b/source/core/replication.txt @@ -300,9 +300,9 @@ Before oplog creation, you can specify the size of your oplog with the change the size of the oplog by using the :doc:`/tutorial/change-oplog-size` tutorial. In most cases, the default oplog size is sufficient. For example, if an -oplog that is 5% of free disk space fills up in an hour, then -secondaries can stop copying entries from the oplog for 20 hours before -they require full resyncing. If this were the case, you would have a +oplog that is 5% of free disk space fills up in 24 hours of operations, then +secondaries can stop copying entries from the oplog for 24 hours before +they require full resyncing. This example describes a very high-volume member. In many circumstances, the default oplog can hold days of operations.