Writing to wrong index

Elastic Stack Elasticsearch
1

I need to update a mapping with additional fields, but decided to create an experimental map first and write documents to it to weed out the problems. As it happened, the whole thing worked first time of asking, but then the next document didn't.

When I checked, the document was in the original: "bookmarks_en_v1" and not: "bookmarks_en_v1-1".

Kibana also refused to allow me to add the index pattern: "bookmarks_en_v1-1" after removing it, in spite of the fact that it was there (I've checked in Postman).

So I deleted the experiment, renamed it to: "bookmarks_en_v1_1" and started again, where this time three documents were written before it again switched to the original, and — as before — refused to write to the experiment again.

Again, I changed the index name, this time to: "experiment", and the type to: "experiment", where it wrote once and then no more, writing — again — to the original.

There is no mention of the original index: "bookmarks_en_v1" anywhere in the application (I've used the built-in search services in the IDE, and besides, I'm passing the index names as variables).

It's worth noting this is a mature application that's been using Elastic without error since 5.6.

This behaviour is inexplicable, and — according to the code — impossible, too.

I'm using Elastic 6.2.4, and Kibana of the same version.

2

So basically you are writing one or a few documents to the intended index and then they get written to another one? That is ... unexpected. The first thing I could think about are aliases. Are you doing anything funky with them and your application might add / change them dynamically? GET /_cat/aliases?v should give you the relevant information.

3

Hi!

Yes, after spending some time on this, that appears to be what's happening.

When I run the URL you gave me, I got: alias index filter routing.index routing.search

4

Hm, that's an empty list of aliases — you're only seeing the header line (coming from the ?v in the call).

I'm a bit out of ideas why this might be happening.

5

Hi, you've already given me something else to look at, to help diagnose the problem.

It's possible I deleted those aliases last night (I was doing a lot of experimentation), or perhaps (and you would know better), this problem stems from an upgrade from 5 to 6?

I'm in the middle of a minor crisis at the moment, so response time are bound to be a bit hit and miss.

6

It is possible that you deleted the aliases , but it's hard to tell. I'm not even fully convinced that your problem stems from aliases. I doubt it's from an upgrade. You might run into errors or deprecation notices, but nothing would automatically switch your indices.

To be blunt, I've never seen a problem like this before and I'm suspecting your application to do something unexpected. Though I have no idea what in particular and if it's an alias or something else.

7

I've checked with production and got:

alias     index           filter routing.index routing.search
notes     notes_en_v1     -      -             -
folders   folders_en_v1   -      -             -
comments  comments_en_v1  -      -             -
bookmarks bookmarks_en_v1 -      -             -
messages  messages_en_v1  -      -             -

... and that is correct, so I did delete everything on development.

But is it possible that documents are getting written to an alias as if it was an index?

I ran the command: GET localhost:9000/_mapping?pretty and didn't find "bookmarks".

8

Yes, if an alias points to a single index you can write to it. If an alias points to multiple indices then it's read-only.

9

I need to do more testing tonight, but I do appreciate the information, which — I'm sure — I'll put to good use.

10

I've had a chance to look at the mapping, and the results are: "folders", "notes", "bookmarks", and "comments" which were aliases, not indexes, but — as noted — there are no aliases.

This appears to have happened as a result of the upgrade to 6.3 from 5.3 that happened in the background on the Mac, which is miraculous given how much of a pain it was to do on staging and then development.

11

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