Fichas
Mongo_Sharding
Fichas del conjunto (17)
- 1provide high availability and disaster recovery can be provided by using ?replica sets
- 2Can I change the shard key after sharding a collection?No.
There is no automatic support in MongoDB for changing a shard key after sharding a collection. This reality underscores the importance of choosing a good shard key. If you must change a shard key after sharding a collection, the best option is to:
dump all data from MongoDB into an external format.
drop the original sharded collection.
configure sharding using a more ideal shard key.
pre-split the shard key range to ensure initial even distribution.
restore the dumped data into MongoDB. - 3What happens if a client updates a document in a chunk during a migration?The mongos routes the operation to the “old” shard, where it will succeed immediately. Then the shard mongod instances will replicate the modification to the “new” shard before the sharded cluster updates that chunk’s “ownership,” which effectively finalizes the migration process.
- 4What happens to queries if a shard is inaccessible or slow?If a shard is inaccessible or unavailable, queries will return with an error.
However, a client may set the partial query bit, which will then return results from all available shards, regardless of whether a given shard is unavailable.
If a shard is responding slowly, mongos will merely wait for the shard to return results. - 5I’ve enabled sharding and added a second shard, but all the data is still on one server. Why?First, ensure that you’ve declared a shard key for your collection. Until you have configured the shard key, MongoDB will not create chunks, and sharding will not occur.
Next, keep in mind that the default chunk size is 64 MB. As a result, in most situations, the collection needs to have at least 64 MB of data before a migration will occur.
Additionally, the system which balances chunks among the servers attempts to avoid superfluous migrations. Depending on the number of shards, your shard key, and the amount of data, systems often require at least 10 chunks of data to trigger migrations.
You can run db.printShardingStatus() to see all the chunks present in your cluster. - 6Is it safe to remove old files in the moveChunk directory?¶Yes. mongod creates these files as backups during normal shard balancing operations. If some error occurs during a migration, these files may be helpful in recovering documents affected during the migration.
Once the migration has completed successfully and there is no need to recover documents from these files, you may safely delete these files. Or, if you have an existing backup of the database that you can use for recovery, you may also delete these files after migration.
To determine if all migrations are complete, run sh.isBalancerRunning() while connected to a mongos instance. - 7How does mongos use connections?Each client maintains a connection to a mongos instance. Each mongos instance maintains a pool of connections to the members of a replica set supporting the sharded cluster. Clients use connections between mongos and mongod instances one at a time. Requests are not multiplexed or pipelined. When client requests complete, the mongos returns the connection to the pool.
- 8Why does mongos hold connections open?mongos uses a set of connection pools to communicate with each shard. These pools do not shrink when the number of clients decreases.
This can lead to an unused mongos with a large number of open connections. If the mongos is no longer in use, it is safe to restart the process to close existing connections. - 9Where does MongoDB report on connections used by mongos?Connect to the mongos with the mongo shell, and run the following command:
db._adminCommand("connPoolStats"); - 10What does writebacklisten in the log mean?The writeback listener is a process that opens a long poll to relay writes back from a mongod or mongos after migrations to make sure they have not gone to the wrong server. The writeback listener sends writes back to the correct server if necessary.
These messages are a key part of the sharding infrastructure and should not cause concern. - 11When do the mongos servers detect config server changes?mongos instances maintain a cache of the config database that holds the metadata for the sharded cluster. This metadata includes the mapping of chunks to shards.
mongos updates its cache lazily by issuing a request to a shard and discovering that its metadata is out of date. There is no way to control this behavior from the client, but you can run the flushRouterConfig command against any mongos to force it to refresh its cache. - 12How do indexes impact queries in sharded systemsIf the query does not include the shard key, the mongos must send the query to all shards as a “scatter/gather” operation. Each shard will, in turn, use either the shard key index or another more efficient index to fulfill the query.
If the query includes multiple sub-expressions that reference the fields indexed by the shard key and the secondary index, the mongos can route the queries to a specific shard and the shard will use the index that will allow it to fulfill most efficiently. - 13Can shard keys be randomly generated?Shard keys can be random. Random keys ensure optimal distribution of data across the cluster.
Sharded clusters, attempt to route queries to specific shards when queries include the shard key as a parameter, because these directed queries are more efficient. In many cases, random keys can make it difficult to direct queries to specific shards. - 14Can shard keys have a non-uniform distribution of valuesYes. There is no requirement that documents be evenly distributed by the shard key.
However, documents that have the same shard key must reside in the same chunk and therefore on the same server. If your sharded data set has too many documents with the exact same shard key you will not be able to distribute those documents across your sharded cluster. - 15Can you shard on the _id fieldYou can use any field for the shard key. The _id field is a common shard key.
Be aware that ObjectId() values, which are the default value of the _id field, increment as a timestamp. As a result, when used as a shard key, all new documents inserted into the collection will initially belong to the same chunk on a single shard. Although the system will eventually divide this chunk and migrate its contents to distribute data more evenly, at any moment the cluster can only direct insert operations at a single shard. This can limit the throughput of inserts. If most of your write operations are updates, this limitation should not impact your performance. However, if you have a high insert volume, this may be a limitation.
To address this issue, MongoDB 2.4 provides hashed shard keys - 16Must read page from mongo db https://docs.mongodb.org/manual/reference/glossary/#term-gridfshttps://docs.mongodb.org/manual/reference/glossary/#term-gridfs
- 17—
Información
- Descripción
- Fichas sobre Mongo_Sharding, creado por raj.mattew el 17/08/2015.
- Creado por
- raj.mattew
- Visitas
- 2
- Valoración