[SERVER-15105] Automatically re-balance shards/replica-sets, as you add/remove nodes, and allow multiplexing shards/replica-sets on the same node Created: 01/Sep/14 Updated: 06/Dec/22 Resolved: 16/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.7.5 |
| Fix Version/s: | features we're not sure of |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Victor Hooi | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Won't Do | Votes: | 9 |
| Labels: | lamont-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Assigned Teams: |
Sharding EMEA
|
||||
| Participants: | |||||
| Description |
|
In ElasticSearch, each "index" (equivalent to a database in our parlance) is split across multiple "shards", each of which holds a portion of the data. Shards can be either primary shards, or replica shards (redundant copies of the data). When you create a ES index, you can specify both the number of shards, and the number of replicas to create. For example, the below will create a index called "blogs", which has 3 shards, and 1 replica for each shard:
As you add and remove nodes from a cluster, ES will transparently handle re-balancing the shards, as well as re-creating replica-shards to maintain the specified number of replicas. ES will not put a primary shard and a replica for that primary shard on the same node - if you don't have enough nodes for it to re-balance properly, it will report the cluster status as degraded (e.g. yellow), until you add another node. There is a description of the operational semantics in ES's Life in a Cluster document, as well as a discussion of it in Exploring ElasticSearch's Advanced Topics chapter. So from an operational point of view, it is much simple to manage adding/removing nodes, and changing the number of replicas versus in MongoDB. Another advantage is that it makes it seamless to multiplex multiple shards onto one node. That is, ES will automatically arrange things so that each node will automatically contain both a primary shard, as well as replica shards for other primary shards:
Cassandra 2.0 does something similar using a replication factor, which is defined per keyspace, however, it's nowhere near as automated and transparent to the end-user as ES. |
| Comments |
| Comment by Jose Luis Pedrosa [ 02/Sep/14 ] |
|
I'd like to add, that this also add some challenges to what current model supports. |
| Comment by Greg Studer [ 02/Sep/14 ] |
|
This is a large change to MongoDB's replication and sharding model, as is mentioned above. > As you add and remove nodes from a cluster, ES will transparently handle re-balancing the shards, as well as re-creating replica-shards to maintain the specified number of replicas. MongoDB automatic rebalancing currently works in an analogous way given our sharding/replication model, though there's certainly plenty of room for improvement. It seems like the real thrust of this ticket, in MongoDB terminology, is the replication of chunks across shards to allow for A) simpler administration and B) better distribution of write load in a cluster with the same number of total nodes. These are both valid goals, but it's not currently clear that this is the only approach to get there - for now, changing the replication model isn't planned. |