Upgrade from 6.4 to 7.2

That does not make any sense.

This is saying that you have 164 documents in this index.

building-name-and-number-group-ie-2018-q4 0 p STARTED 164 81.6kb 172.27.135.207 instance-0000000001
building-name-and-number-group-ie-2018-q4 0 r STARTED 164 81.6kb 172.27.60.248 instance-0000000000

Could you run:

GET /_search?size=0

That is the whole point! If we made software like this, our customers would run a mile!

{
  "took" : 5,
  "timed_out" : false,
  "_shards" : {
    "total" : 11,
    "successful" : 11,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 10000,
      "relation" : "gte"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}

Please format your code, logs or configuration files using </> icon as explained in this guide and not the citation button. It will make your post more readable.

Or use markdown style like:

```
CODE
```

This is the icon to use if you are not using markdown format:

There's a live preview panel for exactly this reasons.

Can you add a terms agg on _index field?

Sorry can you spell out the query if it is not too cumbersome?

Hi. Don't understand. Do you mean you had the same issue?

Here we go:

GET _search
{
  "size": 0,
  "aggs": {
    "index": {
      "terms": {
        "field": "_index"
      }
    }
  }
}

Hi David. Thanks for the info. Here is the output:

{
  "took" : 13,
  "timed_out" : false,
  "_shards" : {
    "total" : 11,
    "successful" : 11,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 10000,
      "relation" : "gte"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "index" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "address-ie-2018-q4",
          "doc_count" : 10000
        },
        {
          "key" : ".security-7",
          "doc_count" : 38
        },
        {
          "key" : ".kibana_1",
          "doc_count" : 7
        },
        {
          "key" : ".kibana_task_manager",
          "doc_count" : 2
        },
        {
          "key" : "apm-7.2.0-onboarding-2019.07.02",
          "doc_count" : 1
        }
      ]
    }
  }
}

I have re-executed the shards to see if it still show documents:

thoroughfare-group-ie-2018-q4             0 p STARTED   338 171.1kb 172.27.135.207 instance-0000000001
thoroughfare-group-ie-2018-q4             0 r STARTED   338 171.1kb 172.27.60.248  instance-0000000000
address-ie-2018-q4                        0 p STARTED 10000   9.4mb 172.27.135.207 instance-0000000001
address-ie-2018-q4                        0 r STARTED 10000   9.4mb 172.27.60.248  instance-0000000000
building-name-and-number-group-ie-2018-q4 0 p STARTED   164  81.6kb 172.27.135.207 instance-0000000001
building-name-and-number-group-ie-2018-q4 0 r STARTED   164  81.6kb 172.27.60.248  instance-0000000000
secondary-thoroughfare-group-ie-2018-q4   0 p STARTED    10   9.4kb 172.27.135.207 instance-0000000001
secondary-thoroughfare-group-ie-2018-q4   0 r STARTED    10   9.4kb 172.27.60.248  instance-0000000000
apm-7.2.0-onboarding-2019.07.02           0 p STARTED     1   6.2kb 172.27.135.207 instance-0000000001
apm-7.2.0-onboarding-2019.07.02           0 r STARTED     1   6.3kb 172.27.60.248  instance-0000000000
.security-7                               0 r STARTED    38  99.2kb 172.27.135.207 instance-0000000001
.security-7                               0 p STARTED    38  63.1kb 172.27.60.248  instance-0000000000
.kibana_1                                 0 p STARTED     7  37.4kb 172.27.135.207 instance-0000000001
.kibana_1                                 0 r STARTED     7  37.4kb 172.27.60.248  instance-0000000000
building-number-group-ie-2018-q4          0 p STARTED    59  30.3kb 172.27.135.207 instance-0000000001
building-number-group-ie-2018-q4          0 r STARTED    59  30.3kb 172.27.60.248  instance-0000000000
.kibana_task_manager                      0 p STARTED     2  12.7kb 172.27.135.207 instance-0000000001
.kibana_task_manager                      0 r STARTED     2  29.5kb 172.27.60.248  instance-0000000000
building-group-ie-2018-q4                 0 p STARTED    68    48kb 172.27.135.207 instance-0000000001
building-group-ie-2018-q4                 0 r STARTED    68    48kb 172.27.60.248  instance-0000000000
building-name-group-ie-2018-q4            0 p STARTED    81  60.6kb 172.27.135.207 instance-0000000001
building-name-group-ie-2018-q4            0 r STARTED    81  60.6kb 172.27.60.248  instance-0000000000

Could it be possible for you to zip the data dir of both nodes and send it to me at david (at) elastic.co? I'd love to understand how this can be... I've never seen that.
Thanks

Sure. How do I get at them?

David. We are using Elastic Cloud.

1 Like

Could you raise a question to the support team? https://www.elastic.co/cloud/as-a-service/support

I already have. But they are taking their time! Considering the severity of this issue I thought they would be all over it immediately. Oh well.

Good. Let me check.

About response time it also depends on the contract level you have I guess. Platinum is obviously faster I guess.

I only have a standard as currently we are still in the development stage.
But as this seems to be something to do with the Elastic infrastructure I thought it may get top priority!.

P.S. my case number : #00358469 [Impaired] Elastic Cloud Standard [ref:_00Db0H5KI._5004MXqPMH:ref ]

Could you run again:

GET /_cat/indices?v

Here it is:

health status index                                     uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   building-name-and-number-group-ie-2018-q4 Gx-XwgXjQuGcI6tH37QCNw   1   1        164            0    163.3kb         81.6kb
green  open   address-ie-2018-q4                        95mb4-DvRVOX_q918af4UA   1   1      10000            0     18.8mb          9.4mb
green  open   thoroughfare-group-ie-2018-q4             J-ppzCNzQUOykEYi7J3EJQ   1   1        338           62    342.2kb        171.1kb
green  open   apm-7.2.0-onboarding-2019.07.02           AaH-e7rVTraW-Ix2FF4uTg   1   1          1            0     12.5kb          6.2kb
green  open   .security-7                               a8Nmbw8PRgSsIzUW_h65OQ   1   1         38            0    162.4kb         63.1kb
green  open   building-name-group-ie-2018-q4            hPf8p2F-SAuZtzgItku6Jw   1   1         81            0    121.3kb         60.6kb
green  open   .kibana_1                                 tx8QvopLQFmj918NUixguw   1   1          7            0     74.9kb         37.4kb
green  open   building-number-group-ie-2018-q4          i21rs4ElRyq8xsIv0BthGQ   1   1         59            0     60.6kb         30.3kb
green  open   secondary-thoroughfare-group-ie-2018-q4   0ce9CGkxQHu1DsP2ffnkuA   1   1         10            0     18.9kb          9.4kb
green  open   building-group-ie-2018-q4                 K20f_1IuS4-1GG0YZIdVDQ   1   1         68            4       96kb           48kb
green  open   .kibana_task_manager                      TZiEhVEFTui28xA8JsVnnA   1   1          2            0     42.3kb         12.7kb

Thanks again for the assistance, @han1! As discussed in the support thread our current recommendation is to update the settings for the affected indices to reset the refresh_interval from a negative to a positive integer. The current prognosis being that that value was not reset after the bulk indexing process occurred as suggested in our documentation: https://www.elastic.co/guide/en/elasticsearch/reference/7.2/indices-update-settings.html#bulk

Please let us know if the issue persists where you're unable to query your index data once those indices have been refreshed.

1 Like

Hi,

We have re-enabledrefresh after indexing using:

var result = client.Indices.UpdateSettingsAsync(indexName, u => u
            .IndexSettings(i => i
            .RefreshInterval("1s")));
            return result.IsCompleted;

Can you run:

GET building-name-and-number-group-ie-2018-q4/_settings

For example?