Zero bugs - We could not change existing search functionality for end-users.Ĭhapter 3 - Problem solving and thinking of a plan. So we needed to prepare a recovery plan in case our migration failed. Recovery plan - We could not afford to “lose” or “corrupt” data, no matter the cost. ZERO downtime migration - We have active users on our system, and we could not afford for the system to be down while we were migrating. Poor visibility on our existing cluster - We wanted a better view under the hood and saw that later versions had great metrics exporting tools. Dynamic mappings in our schema - Our current schema in Elasticsearch 1.7 used a feature called dynamic mappings that made our cluster explode multiple times. Non-existent support in old Elasticsearch versions - We were missing some operative knowledge in Elasticsearch, and when we searched for outside consulting we were encouraged to migrate forward to receive support. This was reflected in frequent high latencies, high CPU usage, and more issues. Performance and stability issues - We were experiencing a huge number of outages with long MTTR that caused us a lot of headaches. What benefits were we expecting to solve by upgrading our data store? Finally -> How to do data migration between clusters. -> How did we handle the infamous mapping explosion problem?. 
Problem solving -> How did we address the constraints?.
The constraints -> What were our business requirements?.What’s in it for me? -> What were the new features that led us to upgrade our version?.This post contains 6 chapters (and one is optional): I'll also provide you with a script that does the migration for you. In this post, I will share how we migrated from Elasticsearch 1.6 to 6.8 with harsh constraints like zero downtime, no data loss, and zero bugs. My last task at BigPanda was to upgrade an existing service that was using Elasticsearch version 1.7 to a newer Elasticsearch version, 6.8.1.
0 kommentar(er)
