{"id":20590,"date":"2019-06-10T16:30:26","date_gmt":"2019-06-10T15:30:26","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=20590"},"modified":"2020-07-30T12:54:38","modified_gmt":"2020-07-30T11:54:38","slug":"upgrading-elasticsearch","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/upgrading-elasticsearch\/","title":{"rendered":"A step-by-step guide to how we upgraded Elasticsearch with no downtime"},"content":{"rendered":"

Elasticsearch is a core technology<\/a> at Intercom. It powers everything from article, conversation and user search to reporting, billing, message delivery and even our internal log management and analytics.<\/p>\n

Because Elasticsearch has been at the core of Intercom for a long time<\/a>, upgrading it is a challenging problem. Any version upgrade needs to be completely invisible to our customers. To quote Aaron Brady from Shopify<\/a>, \u201cOur customers should not be disadvantaged by the fact that we have chosen to upgrade our infrastructure.\u201d<\/p>\n

This story begins a few months ago.<\/p>\n

\"\"<\/p>\n

It\u2019s September 2018, and there are 7 Elasticsearch clusters at Intercom. These are single purpose clusters, and they are owned by independent product teams. Intercom believes that teams should own their own infrastructure. This lets us move fast and optimize for the long term<\/a> (one of our core engineering values) by giving us control over decisions such as indices, mappings and types without being blocked for approval by red tape.<\/p>\n

“We strive to ensure it is always fast, safe and easy for these product teams to utilize our infrastructure services to build amazing things”<\/p><\/blockquote>\n

In Intercom, we are focused on shipping great product at high velocity<\/a>, and it’s critical that product teams are empowered and enabled to do this. We strive to ensure it’s always fast, safe and easy for these product teams to utilize our infrastructure services to build amazing things. This is why we made the decision to centralize this upgrade effort within a single infrastructure team.<\/p>\n

We thus chose to upgrade all of our Elasticsearch clusters, starting with our oldest cluster which was running version 2.3.3. There were 54 releases of Elasticsearch between versions 2.3.3 and 6.3.0. That\u2019s a long jump, and one we had to land perfectly.<\/p>\n

Why keep Elasticsearch up to date<\/h2>\n

Before starting this project, we made sure we were solving the right problem by asking ourselves, \u201cWhy should we keep Elasticsearch up to date?\u201d<\/p>\n

Running lots of different versions of Elasticsearch is not optimal for a few reasons:<\/p>\n