Scaling MySQL @LinkedIn with Vitess

MySQL serves as the datastore for many of the important internal tools at LinkedIn. A typical MySQL cluster at LinkedIn has 1 primary and 2 replicas for read-scaling and HighAvailability. To scale the reads for all these tools, more replicas are added to the cluster. But, what about write-scaling which still goes to a single primary? We started looking for an answer to this question about a year and a half ago when one of the tools ramped up quickly and was struggling due to writes. When we decided sharding as the solution to this, there was a choice between writing the sharding logic in the application itself or choosing Vitess. Vitess stood out for us. Although we had to tweak the schema design, there were minimal changes to the application code as it supports almost all the SQL queries and connection pooling. This talk will be focused about our journey with Vitess. We will take the attendees through the ‘Why’ of our journey, why we chose Vitess and not any other sharding method; how we migrated the platform real time and what tremendous metrics we achieved post successful migration. The talk will consist of: – Introduction – Why Vitess? – Brief Introduction to Vitess – Challenges while moving to Vitess – What it looks like at the Infra-level – Key Achievements Along with talking about our journey with Vitess, we will touch base upon what is next for Vitess@LinkedIn. Key Takeaways – Vitess as a sharding solution to MySQL – Insights from our learnings Speakers: Apoorv Purohit and Karthik Appigatla – LinkedIn