# .geoip\_database index created in es7 prevents es9 upgrade

**URL:** <https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618>\
**Category:** Elasticsearch\
**Created:** [July 22, 2026, 9:27am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618 "2026-07-22T09:27:45Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 22, 2026, 9:27am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/1 "2026-07-22T09:27:45Z")

</div>

We follow an es upgrade approach where we reindex the index on every major version upgrade. We noticed during our es9 upgrade from es8, there is a system index .geoip\_database which was created in es7 is not allowing es9 to startup. We were redindexing only certain user defined indices on every major version upgrade. Since es9 is not coming up now during upgrade, what are the ways to remediate this now? Even disabling geoip module did not work

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [July 22, 2026, 10:05am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/2 "2026-07-22T10:05:33Z")

</div>

> [@manick02](#):
>
> during our es9 upgrade from es8

from which specific version to which specific version?

Did you review Upgrade Assistant before doing the 8.x --\> 9.x upgrade? Did it not flag the indices?

> [@manick02](#):
>
> Since es9 is not coming up now

This has been reported a few times, usually just temporarily reverting to the previous 8.x version and dealing with these index issues on 8.x was the route forward.

You made a snapshot before the upgrade, right?

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 22, 2026, 10:16am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/3 "2026-07-22T10:16:48Z")

</div>

Thanks for the response. We don't use upgrade assistant. We snapshot before upgrade and if the upgrade fails we revert back.

---

<div class="post-metadata">

**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\
**Post date:** [July 22, 2026, 11:47am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/4 "2026-07-22T11:47:15Z")

</div>

> [@manick02](#):
>
> Thanks for the response. We don't use upgrade assistant. We snapshot before upgrade and if the upgrade fails we revert back.

The upgrade assistant exists to detect and help fix issues that may impact the upgrade between major versions, it is the documented and recommended upgrade path.

Without following it there is no guarantee that your upgrade will work without any issues.

Were you able to restore to version 8? If so you should follow the recommended upgrade path and use the upgrade assistant.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [July 22, 2026, 12:01pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/5 "2026-07-22T12:01:28Z")

</div>

> [@manick02](#):
>
> We don't use upgrade assistant

Well, in my experience it helps to follow the documentation 🙂

Step 1 is to upgrade to latest 8.19.x patch release - did you do this?

Step 2 is

Run the Upgrade Assistant

The Upgrade Assistant identifies deprecated settings in your configuration and guides you through resolving issues that could prevent a successful upgrade. _The Upgrade Assistant also helps resolve issues with older indices created before version 8.0.0, providing the option to reindex older indices or mark them as read-only. To prevent upgrade failures, we strongly recommend you **do not** skip this step_

Often just downgrading the software (say via yum or dnf or apt on linux) to the previously-used release will work, from where you can follow the correct procedure. Of course your snapshots are also a fallback.

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 22, 2026, 12:55pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/6 "2026-07-22T12:55:23Z")

</div>

Yes it did fortunately.

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 22, 2026, 1:02pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/7 "2026-07-22T13:02:36Z")

</div>

In our current setup, es upgrade has been happening headless. What i mean is, our webapp on its start up handles reindex logic if it detects a major version change and we update the webapp for new es version changes. There is no separate manual intervention that was needed so far for sometime.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [July 22, 2026, 3:02pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/8 "2026-07-22T15:02:05Z")

</div>

> [@manick02](#):
>
> our webapp on its start up handles reindex logic if it detects a major version change and we update the webapp for new es version changes

Understood. So I guess you can now open a bug report against your webapp 😉

And note that a major version upgrade might involve other (documented) changes outside a need to re-index indices created in version N-1 when going from N to N+1. Thats what the Upgrade Assistant is there for, to help you avoid downtime and upgrade successfully. You can "roll your own" methodology obviously, but then you own that risk.

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [July 22, 2026, 3:39pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/9 "2026-07-22T15:39:04Z")

</div>

Drive By Help... not sure of the entire upgrade context but you could temporarily disable the geoip, which should clear everything, then upgrade and then reenable. Perhaps that would work... I am surprise when you move the cluster form 7.x to 8.x that there was some leftover that is blocking but perhaps disable / reenable will help in this specific case.

8.x

> **[Cluster settings - GeoIP processor | Elasticsearch Guide \[8.19\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/geoip-processor.html#geoip-cluster-settings)**
>
> The geoip processor adds information about the geographical location of an IPv4 or IPv6 address. It is compatible with the GeoIP2 and GeoLite2 IP geolocation databases available from MaxMind.

9.x.

> **[Cluster settings - GeoIP processor | Elasticsearch Reference](https://www.elastic.co/docs/reference/ingest-processor/geoip-processor#geoip-cluster-settings)**
>
> The geoip processor adds information about the geographical location of an IPv4 or IPv6 address. By default, the processor uses the GeoLite2 City, GeoLite2...

---

<div class="post-metadata">

**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\
**Post date:** [July 22, 2026, 4:12pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/10 "2026-07-22T16:12:01Z")

</div>

> [@stephenb](#):
>
> I am surprise when you move the cluster form 7.x to 8.x that there was some leftover that is blocking but perhaps disable

I think it makes sense if upgrade assistant is not used, if I'm not wrong indices in a previous major version would be no problem, but being 2 majors versions behind is the issue.

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 23, 2026, 6:40am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/11 "2026-07-23T06:40:26Z")

</div>

We dont need geoip module at all. I tried disabling using _ **ingest.geoip.downloader.enabled=false** _ but still es9 tried loading the geoip index created in es7 and aborted the startup.

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 23, 2026, 6:53am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/13 "2026-07-23T06:53:00Z")

</div>

Yeah, we understood that risk. For us we support only certain number of indices that powers our webapp, during major version upgrade we take care of the necessary changes for all the indices . On the lower environments where we dont have older data from es7 everything was fine and this issue creaped closer up in a production clone environment where we have the data from es7 time. Geoip module was enabled by default and i realise somewhere down that data got loaded. I think we needed the headless upgrade approach because provide our webapp as a hosted solution to customer, and each customer has their own infra for our webapp, and doing a headless upgrade seemed reasonable decision at that point.

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 23, 2026, 7:07am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/14 "2026-07-23T07:07:28Z")

</div>

Yes, being two version down was the issue, and some how we did not know so far that .geoip index is enabled by default and we have not been managing the index on major version upgrades

---

<div class="post-metadata">

**Author:** ![Keith\_Massey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/keith_massey/32/83666_2.png) [@Keith\_Massey](https://discuss.elastic.co/u/Keith_Massey)\
**Post date:** [July 23, 2026, 1:32pm UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/15 "2026-07-23T13:32:30Z")

</div>

If you can't use the upgrade assistant, I would _highly_ recommend at least hitting the `/_migration/deprecations` API, and not upgrading if that returns any critical deprecations. I believe it would have caught this. The upgrade assistant does other checks, too, so I'd really recommend running it. But at a minimum I'd check the API above.

---

<div class="post-metadata">

**Author:** ![manick02](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@manick02](https://discuss.elastic.co/u/manick02)\
**Post date:** [July 24, 2026, 6:22am UTC](https://discuss.elastic.co/t/geoip-database-index-created-in-es7-prevents-es9-upgrade/388618/16 "2026-07-24T06:22:49Z")

</div>

Thank you Keith for the direction. I will investigate and see how I can use it and safeguard our upgrade process
