Behind The Scenes of dbShards MySQL Database Sharding: Part 2
In this new series of posts, we explore the day-to-day operations of AgilData’s Remote Managed Services, supporting sites running dbShards, a MySQL database sharding product provided by AgilData. There is so much more than just highly scalable software that goes into operating a web or phone application. What better than an insider’s glimpse of some of the cool things we do and interesting problems we solve for customers and global users of our solutions? This is part 2 of this introduction. Catch up with this series by starting with Part I here.
Ongoing Maintenance, Monitoring, and Response
Once we have onboarded a new customer, we switch gears and move into ongoing maintenance operations. AgilData’s team can install database monitoring for slow queries and various types of failure events, often custom to a given system, to ensure any time the system encounters an issue, AgilData are in the alert stream. We provide up to 24×7 first-responder (tier 1) services through tier 3 response, depending upon the customer’s needs. Some customers prefer us to just pass on the notifications for them, while others prefer we fix the issues directly and report incident summaries once everything is back online. Fortunately, with dbShards high availability auto-failover issues rarely result in service interruption.
One of the great features of dbShards is our ability to take all your queries and stream data literally anywhere. It’s a best practice to partition certain datasets like analytics or leaderboards into a separate dedicated database shards. We do that with dbShards Streaming. If you had a database with 10 tables and you wanted each one of those tables streamed to its own database server dbShards can do that. We can stream from MySQL to PostgreSQL, or PostgreSQL to a AWS RDS instance. Our streaming agents are extremely configurable and allow for infinite possibilities.
Applications that require MySQL database sharding are inherently complex and the data infrastructure is big. People talk about Facebook scale but most large applications will never see that size and probably fall into the category of medium data. Scaling out medium data can be just as complicated, if not more, because each shard server is more critical and the data strategy has to be well planned and in close coordination with the application feature development. We run some large systems for customers — 64 shards or more is not uncommon. Whether supporting a global brand or a popular Facebook game, scaling requires thoughtful planning.
One of the best advantages to dbShards is the replication and high availability. Often times maintenance to a database schema can cause lots of issues to the end users. With dbShards we can simply pause replication to the slaves, run the database alter or any changes on the slaves, resume replication until they are caught up with the masters, failover and repeat. It makes this process seamless and doesn’t affect your end users.
We have recently experienced a situation where a customer of ours sold their company. This proved challenging for the new team to come in and try to figure out all the moving parts and different servers of the application. Within the first week of the new team being there one of their servers went down. We were able to provide support for them and get the server back up and running with no downtime. This had extreme value for them because they were still learning how the application was put together.
Time to Scale Your MySQL? No Problem
MySQL Database Sharding an existing application in production is a complicated matter that can be made simple with the right partners. AgilData’s remote DBA’s provide peace of mind and a steady hand from the beginning to ensure you are on the right track to a smooth operational model.