diff --git a/content/operations/convert-replica-set-to-replicated-shard-cluster.txt b/content/operations/convert-replica-set-to-replicated-shard-cluster.txt index 8312801..0c1e308 100644 --- a/content/operations/convert-replica-set-to-replicated-shard-cluster.txt +++ b/content/operations/convert-replica-set-to-replicated-shard-cluster.txt @@ -11,17 +11,17 @@ filter: ## Overview This tutorial documents the process for converting a single 3-member -replica set, to a shard cluster that consists of 2 shards. Each shard +replica set to a shard cluster that consists of 2 shards. Each shard will consist of an independent 3-member replica set. The procedure that follows uses a test environment running on a local -system (i.e. localhost,) and have been tested you should feel +system (i.e. localhost,) and has been tested. You should feel encouraged to "follow along at home." In a production environment or one with multiple systems, use the same process except where noted. In brief, the process is as follows: -1. Create or select and existing a 3-member replica set, and insert +1. Create or select an existing 3-member replica set, and insert some data into a collection. 2. Start the config servers and create a shard cluster with a single @@ -40,7 +40,7 @@ In brief, the process is as follows: #### 1.1. Create Directories for First Replica Set Instance Create the following data directories for the members of the -first replica set, named set1: +first replica set, named firstset: - `/data/example/firstset1` - `/data/example/firstset2` @@ -64,9 +64,9 @@ $ bin/mongod --dbpath /data/example/firstset3 --port 10003 --replSet firstset -- **Note:** Here, the "`--oplogSize 700`" option restricts the size of the operation log (i.e. oplog) for each `mongod` process to -700MB. Without the `--oplogSize` option, `mongod` will reserve +700MB. Without the `--oplogSize` option, each `mongod` will reserve approximately 5% of the free disk space on the volume. By limiting the -size of the oplog, each process will start quicker. Omit this setting +size of the oplog, each process will start more quickly. Omit this setting in production environments. #### 1.3 Connect to One MongoDB Instance with `mongo` shell @@ -95,9 +95,9 @@ hostname, or the IP address of your system. } <% end %> -#### 1.5. Create and Populate a New a Collection +#### 1.5. Create and Populate a New Collection -The following JavScript creates one-million documents to the +The following JavScript writes one million documents to the collection "`test_collection`" in the following form: <% code 'javascript' do %> @@ -166,7 +166,7 @@ command in a new terminal window or GNU Screen window. $ bin/mongos --configdb localhost:20001,localhost:20002,localhost:20003 --port 27017 --chunkSize 1 <% end %> -**Note:** If you are using the collection created earlier, or are just +**Note:** If you are using the collection created earlier, or are just experimenting with sharding, you can use a small --chunkSize (1MB works well.) The default chunkSize of 64MB, means that your cluster will need to have 64MB of data before the MongoDB's automatic sharding @@ -176,9 +176,9 @@ size. The `configdb` options specify the *configuration servers* (e.g. `localhost:20001`, `localhost:20002`, and `localhost:2003`). The `mongos` process runs on the default "MongoDB" port (i.e. `27017`), -while the databases themselves, in this example run on ports in the +while the databases themselves, in this example, are running on ports in the `30001` series. In the above example, since `27017` is the default -port, the option "`--port 27017`" may be omitted: it is included here +port, the option "`--port 27017`" may be omitted. It is included here only as an example. #### 2.4. Add the first shard in `mongos` @@ -200,7 +200,7 @@ mongos> #### 3.1. Create Directories for Second Replica Set Instance Create the following data directories for the members of the -second replica set, named set1: +second replica set, named secondset: - `/data/example/secondset1` - `/data/example/secondset2` @@ -292,7 +292,7 @@ mongos> db.runCommand( { enablesharding : "test" } ) #### 5.2. Create an Index on the Shard Key Create an index on the shard key. The shard key is used by MongoDB to -distribute documents between shards. Once selected the shard key needs +distribute documents between shards. Once selected the shard key cannot be changed. Good shard keys: - will have values that are evenly distributed among all documents, @@ -333,8 +333,7 @@ Over the next few minutes the Balancer will begin to redistribute chunks of documents. You can confirm this activity by switching to the `test` database and running `db.stats()` or `db.printShardingStatus()`. -Future writes to the sharded collection will force MongoDB to -redistribute documents (and chunks) among the new shards. +Additional documents that are added to this collection will be distributed evenly between the shards. See the following examples: