docs: clarify steps for rollup cache purge for vmselects

Signed-off-by: hagen1778 <roman@victoriametrics.com>
(cherry picked from commit 5e38dde18d)

docs/Troubleshooting.md

@@ -154,6 +154,8 @@ If you see unexpected or unreliable query results from VictoriaMetrics, then try
    - By passing `nocache=1` query arg to every request to `/api/v1/query` and `/api/v1/query_range`.
      If you use Grafana, then this query arg can be specified in `Custom Query Parameters` field
      at Prometheus datasource settings - see [these docs](https://grafana.com/docs/grafana/latest/datasources/prometheus/) for details.
+    
+    If the problem was in the cache, try resetting it via [resetRollupCache handler](https://docs.victoriametrics.com/url-examples.html#internalresetrollupresultcache).
 
 1. If you use cluster version of VictoriaMetrics, then it may return partial responses by default
    when some of `vmstorage` nodes are temporarily unavailable - see [cluster availability docs](https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#cluster-availability)

docs/url-examples.md

@@ -631,7 +631,7 @@ curl -Is http://localhost:8428/internal/resetRollupResultCache
 
 </div>
 
-Cluster version of VictoriaMetrics::
+Cluster version of VictoriaMetrics:
 
 <div class="with-copy" markdown="1">
 
@@ -639,6 +639,10 @@ Cluster version of VictoriaMetrics::
 curl -Is http://<vmselect>:8481/select/internal/resetRollupResultCache
 ```
 
+vmselect will propagate this call to the rest of the vmselects listed in its `-selectNode` cmd-line flag. If this
+flag isn't set, then cache need to be purged from each vmselect individually.
+
+
 </div>
 
 ### TCP and UDP