IOException while reading synonyms_path_path: /etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt

While trying to restore snapshot in Azure VM.
I am facing this issue .

{
  "error": {
    "root_cause": [
      {
        "type": "exception",
        "reason": "Failed to verify index [articleinformation/2Sr5kjDzT7WmBtVl79HF4A]"
      }
    ],
    "type": "exception",
    "reason": "Failed to verify index [articleinformation/2Sr5kjDzT7WmBtVl79HF4A]",
    "caused_by": {
      "type": "illegal_argument_exception",
      "reason": "IOException while reading synonyms_path_path: /etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt",
      "caused_by": {
        "type": "no_such_file_exception",
        "reason": "/etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt"
      }
    }
  },
  "status": 500
}

Interesting. You probably defined a synonym file in your index settings but snapshot/restore does not backup such a file.

So you need to provide the synonym list manually on all nodes.

cc @Igor_Motov

Hi ,
Thanks for help. I have only one node . I pasted my synonym file in

/etc/elasticsearch$ ls
elasticsearch.yml jvm.options log4j2.properties synonym.txt

Now when i try to Open the index it gives same error. I am new to this so you may feel annoying with my stupid questions.

Many Thanks

Also i get no error while restoring ,
POST /_snapshot/backupazure/snapshot_1/_restore.
but Shards remains UNASSIGNED.

After this closed index and when i try to reopen i get this error

{
  "error": {
    "root_cause": [
      {
        "type": "exception",
        "reason": "Failed to verify index [articleinformation/2Sr5kjDzT7WmBtVl79HF4A]"
      }
    ],
    "type": "exception",
    "reason": "Failed to verify index [articleinformation/2Sr5kjDzT7WmBtVl79HF4A]",
    "caused_by": {
      "type": "illegal_argument_exception",
      "reason": "IOException while reading synonyms_path_path: /etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt",
      "caused_by": {
        "type": "no_such_file_exception",
        "reason": "/etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt"
      }
    }
  },
  "status": 500
}

Sounds like it was wrongly set in your index settings as /etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt? Or are your trying to restore a old snapshot in a 6.2 cluster?

If so, what was the version you used?

Hi,

I am trying to restore snapshot created in version 6.2.2 to 6.2.3

My synonyms setting .

PUT /articleinformation/_settings
{
    "analysis": {
      "filter": {
        "my_synonym_filter": {
          "type": "synonym",
          "synonyms_path": "synonym.txt"
        }
      },
      "analyzer": {
        "my_synonyms": {
          "tokenizer": "whitespace",
          "filter": [
            "lowercase",
            "my_synonym_filter"
          ]
        }
      }
    }
  }

if it is wrong how do i correct it

Interesting.

So the synonym path seemed to have been translated from "synonym.txt" to "/etc/elasticsearch/C:/elasticsearch-6.2.2/config/synonym.txt" which does not make sense to me as it seems that one path is from Linux and the other from Windows.

Are you doing snapshot and restore from/to the same platform?

I am trying to restore snapshot taken from windows to Linux

I see. Looks like a bug to me. Could you open an issue, describe this scenario and add a link to this thread?

Cc @jpountz @Igor_Motov I'm case you have any idea.

Hi raised issue .

please do comments if you find any thing wrong.

@Abhinaw On the cluster where you restored the index (and which has the restored shard as unassigned), can you do a GET /articleinformation/_settings and paste the output here?

{
  "articleinformation": {
    "settings": {
      "index": {
        "refresh_interval": "300s",
        "number_of_shards": "30",
        "provided_name": "articleinformation",
        "max_result_window": "500000",
        "creation_date": "1523736717057",
        "analysis": {
          "filter": {
            "my_synonym_filter": {
              "type": "synonym",
              "synonyms_path": "synonym.txt"
            },
            "my_synonyms": {
              "type": "synonym",
              "synonyms_path": "synonym.txt"
            },
            "synonym": {
              "type": "synonym",
              "synonyms_path": "C:/elasticsearch-6.2.2/config/synonym.txt"
            }
          },
          "analyzer": {
            "my_synonyms": {
              "filter": [
                "lowercase",
                "my_synonym_filter"
              ],
              "tokenizer": "whitespace"
            },
            "synonym": {
              "filter": [
                "synonym"
              ],
              "tokenizer": "whitespace"
            }
          }
        },
        "number_of_replicas": "1",
        "uuid": "1iOz8JmhS66IA-FPdz0Txw",
        "version": {
          "created": "6020299",
          "upgraded": "6020499"
        }
      }
    }
  }
}

Ok, it looks like you configured your synonym path on windows (where you took the snapshot) as an absolute path (not just synonym.txt).

Do you still have the Windows cluster around and try to run the same command there?

You can change the path while restoring (see https://www.elastic.co/guide/en/elasticsearch/reference/6.2/modules-snapshots.html#_changing_index_settings_during_restore ) by setting

"index_settings": {
    "analysis.filter.my_synonym_filter.synonyms_path": "synonym.txt"
  }

on the restore request.

1 Like

I am sorry I do not have it now I started reindexing without synonyms .
But I remember I have tried this in Linux server and it didn't work there

Is there anything we can still investigate here or can we close this? As we take the index setting for the synonyms_path verbatim from the user, I suspect this to be a user error.

Thanks for looking into this, Yes it works fine when synonyms absolute path is given while indexing.
Still we have an issue, in case user gives exact path in windows and then try to restore in linux server then the snapshot restore doesn't work.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.