docs: rm mentions of vmrecover as it still doesn't exist

While there, add a hint about truncated error messages.

Signed-off-by: hagen1778 <roman@victoriametrics.com>
This commit is contained in:
hagen1778 2024-06-26 11:10:42 +02:00
parent 4b77778ff5
commit 6775a00622
No known key found for this signature in database
GPG key ID: 3BF75F3741CA9640
3 changed files with 6 additions and 3 deletions

View file

@ -2430,7 +2430,8 @@ and [cardinality explorer docs](#cardinality-explorer).
* If VictoriaMetrics doesn't work because of certain parts are corrupted due to disk errors,
then just remove directories with broken parts. It is safe removing subdirectories under `<-storageDataPath>/data/{big,small}/YYYY_MM` directories
when VictoriaMetrics isn't running. This recovers VictoriaMetrics at the cost of data loss stored in the deleted broken parts.
In the future, `vmrecover` tool will be created for automatic recovering from such errors.
The names of broken parts should be present in the error message. If you see that error message is truncated and doesn't contain all the information
try increasing `-loggerMaxArgLen` cmd-line flag to higher values to avoid error messages truncation.
* If you see gaps on the graphs, try resetting the cache by sending request to `/internal/resetRollupResultCache`.
If this removes gaps on the graphs, then it is likely data with timestamps older than `-search.cacheTimestampOffset`

View file

@ -2433,7 +2433,8 @@ and [cardinality explorer docs](#cardinality-explorer).
* If VictoriaMetrics doesn't work because of certain parts are corrupted due to disk errors,
then just remove directories with broken parts. It is safe removing subdirectories under `<-storageDataPath>/data/{big,small}/YYYY_MM` directories
when VictoriaMetrics isn't running. This recovers VictoriaMetrics at the cost of data loss stored in the deleted broken parts.
In the future, `vmrecover` tool will be created for automatic recovering from such errors.
The names of broken parts should be present in the error message. If you see that error message is truncated and doesn't contain all the information
try increasing `-loggerMaxArgLen` cmd-line flag to higher values to avoid error messages truncation.
* If you see gaps on the graphs, try resetting the cache by sending request to `/internal/resetRollupResultCache`.
If this removes gaps on the graphs, then it is likely data with timestamps older than `-search.cacheTimestampOffset`

View file

@ -2441,7 +2441,8 @@ and [cardinality explorer docs](#cardinality-explorer).
* If VictoriaMetrics doesn't work because of certain parts are corrupted due to disk errors,
then just remove directories with broken parts. It is safe removing subdirectories under `<-storageDataPath>/data/{big,small}/YYYY_MM` directories
when VictoriaMetrics isn't running. This recovers VictoriaMetrics at the cost of data loss stored in the deleted broken parts.
In the future, `vmrecover` tool will be created for automatic recovering from such errors.
The names of broken parts should be present in the error message. If you see that error message is truncated and doesn't contain all the information
try increasing `-loggerMaxArgLen` cmd-line flag to higher values to avoid error messages truncation.
* If you see gaps on the graphs, try resetting the cache by sending request to `/internal/resetRollupResultCache`.
If this removes gaps on the graphs, then it is likely data with timestamps older than `-search.cacheTimestampOffset`