[SOLR-14326] Number of tlog replicas off by one when restoring collections

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 7.7.2, 8.0
• Fix Version/s: 9.0, 8.9
• Component/s: Backup/Restore
• Assignee: Unassigned
• Reporter: John Wooden
• Created: 13/Mar/20 14:56
• Updated: 23/Jun/21 13:42
• Resolved: 12/Apr/21 16:31

Description

When making a request to restore a collection, the quantity of tlog replicas will always be off by one when restoring a collection that doesn't contain nrt replicas or when specifying the quantity of replicas in the request itself.

/admin/collections?action=RESTORE&name=<NAME>&location=<PATH>&collection=<COLLECTION>&tlogReplicas=1&pullReplicas=1

Despite the backup AND/OR the request specifying 1 Tlog & 1 Pull replica, this request will create 2 Tlog replicas. On a 2-node cluster with maxShardsPerNode=1, the 1 pull replica is never created due to the excess tlog replica meeting the maxShardsPerNode limit.

 

This is due to a flawed comparison where an int meant to be an iterator for tlog replicas is checked if it is greater than zero, however, since that variable was initialized as 0 just prior it will never be greater than zero. The fix is to compare the desired number of tlog replicas (like nrt) rather than the iterator.

 

int createdNrtReplicas = 0, createdTlogReplicas = 0, createdPullReplicas = 0;

// We already created either a NRT or an TLOG replica as leader
if (numNrtReplicas > 0)

Unknown macro: { createdNrtReplicas++; }

else if (createdTlogReplicas > 0)

Unknown macro: { createdTlogReplicas++; }

 

 

 

 

Issue Links

• is fixed by: SOLR-13608 Incremental backup for Solr
• links to: GitHub Pull Request #1348