MySQL: Scale Through Consolidation
“Database sprawl, in my data center?”
It’s more likely than you think.
Explosive growth and rampant success have consequences. Among the most common for MySQL relational databases are sprawl and manageability challenges.
I invite you to join me and the SolidFire team for a webinar on December 16th where we will dive into detail around MySQL consolidation on SolidFire. Before then, read on to understand MySQL’s unique role in powering the web, the path to safe and efficient database storage layer consolidation, and how Quality of Service (QoS) introduces a huge paradigm shift in storage flexibility and agility.
MySQL’s unique role in powering the web
MySQL and the web as we know it today originated in the commonly deployed LAMP stack (originally Linux, Apache, MySQL and PHP), leading to wide adoption as the the de facto database of choice for web platforms.
From powering the world’s largest social media sites, such as Facebook, Twitter and LinkedIn, to the multitude of websites enabled by WordPress, MySQL is ubiquitous. Regardless of the magnitude of any particular deployment, MySQL performance is a touchpoint for all administrators, whether they’re the top tier of the DevOps world, or the weary solo maintainers of client websites.
After fundamental query sanity, the highest impact to MySQL performance is proper alignment with I/O resources. When consolidating many database systems onto a single architectural platform, it’s critical that the underlying storage layer provide dedicated and appropriately scaled performance for the needs of the individual database instances.
Doing this on legacy SAN architectures was very difficult, cumbersome and expensive. Composing disk groups and carving out LUNs, weighing the performance tradeoffs and resource consumption calculations for differing types of RAID striping, and dealing with controller/shelf planning are common obstacles to agile and efficient operations.
The path to safe and efficient database storage layer consolidation
This path is discovered through navigating the plethora of market offerings and understanding the fundamental architectural and technological differences among various solutions available.
Regardless of MySQL database size, the key to a responsive end-user experience is low latency query performance from the underlying MySQL database. Only all-flash architectures can guarantee that all I/O will be low latency, without relying on all blocks fitting into main memory cache. Today, flash is table stakes for database performance at any scale, due to the order of magnitude of responsiveness versus that of legacy spinning disk solutions.
The harder question to answer is how to guarantee an appropriate level of performance to every MySQL instance, and how to optimize resource allocation when planning the storage architecture.
Metric-based quality of service
QoS is necessary for a consolidated storage layer, and only a QoS feature that guarantees min, max, and burst IOPS can unlock the architectural flexibility required when consolidating large numbers of disparate MySQL workloads.
No plan survives first contact with the enemy, but the process of planning is essential, nonetheless. Dynamic QoS solves for this eventuality by allowing on-the-fly adjustments to the IOPS configuration for all workloads, with changes effective in real time.
What this all means is that, with the right solution, the storage layer becomes more flexible and agile than ever before. The stickiest and most difficult-to-change part of the MySQL database environment (i.e. storage) becomes the most flexible and easy to manage — a huge paradigm shift.
Learn how you can leverage SolidFire’s scale-out all-flash storage system to safely and confidently consolidate various types of MySQL workloads, reducing data center sprawl and streamlining operations. In addition, you’ll learn how to:
- Guarantee storage performance
- Dynamically adjust storage resources on the fly
- Linearly and non-disruptively scale your MySQL database storage infrastructure
- Reduce deployment times for MySQL replication slaves and reporting copies from hours to seconds
Register now! I look forward to “seeing” you there.
| 0 comments
Posted in Database.