Solr core/shard backup and restore function ONLY became available after version 5.2 . See JIRA: https://issues.apache.org/jira/browse/SOLR-6637
To manually backup and restore shards, please follow the steps :
Assumes a SolrCloud cluster has 4 cores and 2 node, which 2 cores on each node. (2 shards, with replicationFactor=2)
Back-up each node: http://server1:8983/solr/collection/replication?command=backup&location=location1&name=backup1
Create new collection with 2 shards and replicationFactor=2 http://server:8983/solr/admin/collections?action=CREATE&name=newCollection&numShards=2&replicationFactor=2&createNodeSet=server1:8983_solr,server2:8983_solr
Restore from each backup: http://server1:8983/solr/newCollection/replication?command=restore&location=location1&name=backup1
Add replicas to each shard http://server:8983/solr/admin/collections?action=ADDREPLICA&collection=newCollection&shard=shard2&node=server1:8983_solr
In the API commands where we just have "server" without 1 or 2, it means you can issue the command from either server.
... View more
Following is a guide to split shards and add replicas for collection "ranger_audits" on SolrCloud , in case the initial ranger_audits is created with only 1 shard 1 replica :
1.Initial ranger_audits was created with only 1 shard and 1 replica
and user would like to split the shard to balance load and add more replicas for back up.
2. In the web browser, enter URL to split the shard :
http://172.25.17.51:6083/solr/admin/collections?action=SPLITSHARD&collection=ranger_audits&shard=shard1 , and user shall get a page like
which means the splitting operation is successful. And in the Solr Admin UI, user can see there are two additional shards :
Notice, the original shard1 still exists. This is because splitting a shard will take an existing shard and break it into two pieces which are written to disk as two (new) shards. The original shard will continue to contain the same data as-is but it will start re-routing requests to the new shards. The new shards will have as many replicas as the original shard. A soft commit is automatically issued after splitting a shard so that documents are made visible on sub-shards. An explicit commit (hard or soft) is not necessary after a split operation because the index is automatically persisted to disk during the split operation.
This command allows for seamless splitting and requires no downtime. A shard being split will continue to accept query and indexing requests and will automatically start routing them to the new shards once this operation is complete. This command can only be used for SolrCloud collections created with "numShards" parameter, meaning collections which rely on Solr's hash-based routing mechanism. The split is performed by dividing the original shard's hash range into two equal partitions and dividing up the documents in the original shard according to the new sub-ranges.
3. Create replicas on a different solr node with the SolrCloud for each new shards :
Notice the original solr node still has "Leader" role for both new shards. This is not all that important to worry about. The additional duties of a leader are pretty minimal. And the leaders will shift around anyway as you restart servers etc.
... View more