When calling the dremio-admin restore command on an existing backup during the restore process, an error occurs:
java.lang.IllegalArgumentException: Document contains at least one immense term in field=“SQL” (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: ‘[info about term]’, original message: bytes can be at most 32766 in length; got 58929
As far as I understand, this is due to a request in backup that is too long. At the same time, at first glance, recovery is proceeding normally - all existing requests are found, including the one on which the error occurred.
A search through the error text showed that something like this occurs in Lucene (Solr). My guess is that when I do restore, the utility interacts with Lucene, apparently trying to index the SQL field, but gets an error (because the token is out of range).
I have two questions:
- When restoring, the utility returns an error, but the data is restored (it looks like this). Does this mean that I can ignore these errors, or did something go wrong?
- Is there a way to work around this error? In relation to such an error, ElasticSearch has options with adding the ignore_aboved parameter, changing the field type, etc. What to do in the framework of the dremo is not clear to me.