From f3cd08397e04527fd0dc67cf26a95918d1582558 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Mon, 29 Apr 2013 16:37:51 -0400 Subject: [PATCH 1/3] replication intro - draft 1 --- source/core/replication-introduction.txt | 56 ++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 source/core/replication-introduction.txt diff --git a/source/core/replication-introduction.txt b/source/core/replication-introduction.txt new file mode 100644 index 00000000000..4fffa29bd7b --- /dev/null +++ b/source/core/replication-introduction.txt @@ -0,0 +1,56 @@ +======================== +Replication Introduction +======================== + +.. default-domain:: mongodb + +Replication protects a database from data loss by copying its data to +multiple, different computer locations, which ensures that you can +access the database even if one location is unavailable, even if the +main database computer is unavailable. In MongoDB, production +deployments use replication. + +Replication also guarantees that *changes* to information are never lost +by copying the list of changes to all computer locations that hold the +database. Should the main database location become unavailable it has +made all current changes, the list exists on other computers, allowing +the changes still to be made. + +Finally, replication increases the speed of retrieving database +information. Requests for information can go to any one of the multiple +database instances, thus avoiding traffic slowdowns at a given instance. + +MongoDB provides replication by storing the database in a main computer +location, called a ``primary``, and copying the database to multiple +additional computer locations, called ``secondaries``. This +configuration is called a ``replica set``. Each replica set has a +:term:`primary` and one or more :term:`secondaries `. + +When a user changes data in the database, MongoDB applies the changes on +the primary in the order the user made the changes. This keeps the data +on the primary consistent. MongoDB applies the changes on the +secondaries asynchronously. + +Replica Set Architecture +------------------------ + +A replica set consists of at least three :program:`mongod` instances: a +:term:`primary` and either two :term:`secondaries ` or a +secondary and an :term:`arbiter`. The primary accepts all writes for the +set. All members accept reads. Secondaries replicate from the primary by +asynchronously reading and applying the writes. + +Failover and Recovery +--------------------- + +Replica sets provide automatic failover in the event of an outage. If a +primary becomes unavailable, the replica set automatically promotes a +secondary. The data on the new primary is now the most current in the +set. All members resynchronize when connecting to the new primary. If +the original primary comes back up, it does so as a secondary and begins +syncing off the new primary. + +For More Information +-------------------- + +For more information about replica sets, see :doc:`/replication`. From 2784f62e090e89f6457bf877fbdc7f580f01cef2 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Tue, 30 Apr 2013 15:16:41 -0400 Subject: [PATCH 2/3] replication intro - draft 2 --- source/core/replication-introduction.txt | 45 ++++++++++++------------ 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/source/core/replication-introduction.txt b/source/core/replication-introduction.txt index 4fffa29bd7b..2d0b0435786 100644 --- a/source/core/replication-introduction.txt +++ b/source/core/replication-introduction.txt @@ -4,32 +4,31 @@ Replication Introduction .. default-domain:: mongodb -Replication protects a database from data loss by copying its data to -multiple, different computer locations, which ensures that you can -access the database even if one location is unavailable, even if the -main database computer is unavailable. In MongoDB, production +Replication maintains identical copies of an entire database instance on +multiple distinct systems. +With multiple copies of the data, replication +makes the deployment resilient with regards to the loss of any particular copy +or instance. +In MongoDB, production deployments use replication. -Replication also guarantees that *changes* to information are never lost -by copying the list of changes to all computer locations that hold the -database. Should the main database location become unavailable it has -made all current changes, the list exists on other computers, allowing -the changes still to be made. +Replication also guarantees that *changes* to data are never lost +by keeping a list of changes in all replicated locations. +Replication increases theoretical throughput. With replication, if +applications do not need to write data they can read data from secondary +databases, which increases read capacity. -Finally, replication increases the speed of retrieving database -information. Requests for information can go to any one of the multiple -database instances, thus avoiding traffic slowdowns at a given instance. - -MongoDB provides replication by storing the database in a main computer -location, called a ``primary``, and copying the database to multiple -additional computer locations, called ``secondaries``. This +MongoDB provides replication by storing the database in one +location, called a *primary*, and copying the database to multiple +additional locations, called *secondaries*. This configuration is called a ``replica set``. Each replica set has a :term:`primary` and one or more :term:`secondaries `. -When a user changes data in the database, MongoDB applies the changes on +When a user adds or modifies data in the database, MongoDB applies the changes on the primary in the order the user made the changes. This keeps the data -on the primary consistent. MongoDB applies the changes on the -secondaries asynchronously. +on the primary consistent. The replication process is asynchronous. +Secondaries replicate operations after the operations are applied to the +primary. Replica Set Architecture ------------------------ @@ -45,10 +44,10 @@ Failover and Recovery Replica sets provide automatic failover in the event of an outage. If a primary becomes unavailable, the replica set automatically promotes a -secondary. The data on the new primary is now the most current in the -set. All members resynchronize when connecting to the new primary. If -the original primary comes back up, it does so as a secondary and begins -syncing off the new primary. +secondary to become the new primary, without user intervention. +The data on the new primary is now the most current in the set. When the +original primary becomes available, it will rejoin the set as a +secondary. For More Information -------------------- From 2df83747661e2a1631445945c93de6a834db6041 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Tue, 30 Apr 2013 21:00:57 -0400 Subject: [PATCH 3/3] replication intro - draft 3 --- source/core/replication-introduction.txt | 52 +++++++++++------------- 1 file changed, 23 insertions(+), 29 deletions(-) diff --git a/source/core/replication-introduction.txt b/source/core/replication-introduction.txt index 2d0b0435786..da85f845bfc 100644 --- a/source/core/replication-introduction.txt +++ b/source/core/replication-introduction.txt @@ -5,30 +5,22 @@ Replication Introduction .. default-domain:: mongodb Replication maintains identical copies of an entire database instance on -multiple distinct systems. -With multiple copies of the data, replication -makes the deployment resilient with regards to the loss of any particular copy -or instance. -In MongoDB, production -deployments use replication. - -Replication also guarantees that *changes* to data are never lost -by keeping a list of changes in all replicated locations. -Replication increases theoretical throughput. With replication, if -applications do not need to write data they can read data from secondary -databases, which increases read capacity. - -MongoDB provides replication by storing the database in one -location, called a *primary*, and copying the database to multiple -additional locations, called *secondaries*. This -configuration is called a ``replica set``. Each replica set has a -:term:`primary` and one or more :term:`secondaries `. - -When a user adds or modifies data in the database, MongoDB applies the changes on -the primary in the order the user made the changes. This keeps the data -on the primary consistent. The replication process is asynchronous. -Secondaries replicate operations after the operations are applied to the -primary. +multiple distinct systems. With multiple copies of the data, replication +makes the deployment resilient with regards to the loss of any +particular copy or instance. All MongoDB production deployments use +replication. + +Replicated data helps ensure that all changes to a data set survive +failure. Replication also increases theoretical throughput. With +replication, if applications do not need to write data they can read +data from secondary databases, which increases read capacity. + +MongoDB provides replication by storing the database in one location, +called a *primary*, and copying the database to multiple additional +locations, called *secondaries*. This configuration is called a +``replica set``. Each replica set has a :term:`primary` and one or more +:term:`secondaries `. The primary is the only member of the +set that accepts write operations. Replica Set Architecture ------------------------ @@ -37,15 +29,17 @@ A replica set consists of at least three :program:`mongod` instances: a :term:`primary` and either two :term:`secondaries ` or a secondary and an :term:`arbiter`. The primary accepts all writes for the set. All members accept reads. Secondaries replicate from the primary by -asynchronously reading and applying the writes. +asynchronously reading and applying the writes. This keeps the data on +the primary consistent. The replication process is asynchronous. +Secondaries replicate operations after the operations are applied to the +primary. Failover and Recovery --------------------- -Replica sets provide automatic failover in the event of an outage. If a -primary becomes unavailable, the replica set automatically promotes a -secondary to become the new primary, without user intervention. -The data on the new primary is now the most current in the set. When the +Replica sets provide automatic failover if the primary is not available. +In a failover situation, the replica set automatically promotes a +secondary to become the new primary, without user intervention. When the original primary becomes available, it will rejoin the set as a secondary.