Modern application architectures are distributed and often based on microservices. The decomposition of functionality into smaller loosely coupled modules brings with it tremendous benefits related to performance, scalability, fault tolerance, and resource sharing. In addition to these runtime benefits, functional decomposition allows development teams to deliver software autonomously, at much faster cadences than monolithic software. Teams can operate on their own release cycles, resulting in much faster overall velocity. This approach supports incremental, rapid release of software, characteristic of Agile methodology, and reduces the risk of failure inherent in the “all-or-nothing” monolithic approach.
For this approach to work, each team needs full control of its own tech stack so that the tech stack doesn’t become a cross-team dependency. When it comes to the data layer, isolation between microservices leads to a ‘database per microservice pattern’. This can, however, result in a sprawl of dedicated databases that each serve as the system of record for their respective microservice.
In a distributed architecture, a single request initiated by the user can touch several microservices. A single failure has a ripple effect all the way up the chain and across multiple paths. The overall availability of the system declines exponentially with the introduction of each additional point of failure, so even with highly reliable components, the combined reliability of the components can be quite poor.
‘Distributed architecture friendly’ applications are designed with the assumption that failures will occur and mechanisms to overcome these potential failures. For MySQL, this translates to the availability and recoverability of the database after a failure has occurred. MySQL for Pivotal Platform v2.2 makes this a reality. With v2.2, operators can offer leader-follower MySQL, without being MySQL experts. With this, operators can adopt practices that minimize meantime-to-recovery and focus on practices that meet their recovery point / time objectives. MySQL for Pivotal Platform v2.2 enables operators to meet application uptime needs with its multi-availability zone (AZ), leader-follower plans.
Introducing Leader-Follower Plans
The MySQL service broker deploys leader-follower databases as two MySQL virtual machines (VMs) in two AZs. Leader-follower is often referred to as master-slave. Any data written to the leader replicates asynchronously to the follower. In the event of a network partition, an operator can easily promote a follower to resume database availability.
In the past, managing a multi-node MySQL cluster was difficult. Using MySQL for Pivotal Platform v2.2, operators can rely on the platform to monitor and maintain multiple multi-node clusters. Standard orchestration of a cluster is automated, leaving DBAs free to focus on other tasks.
Your Data is Important Even When Disaster Strikes
Your business relies on its data being available and correct. Unfortunately, incidents happen. When they do, MySQL for Pivotal Platform v2.2 ensures your data is consistent and quickly recovered.
The CAP Theorem means any distributed system must choose between consistency or availability. Most distributed systems use algorithms like RAFT or PAXOS to determine cluster state. These algorithms mean the systems have unnecessary operational overhead. As a result, when something goes wrong, it is more difficult to recover them than less-complex systems that don’t have such overhead.
With MySQL for Pivotal Platform v2.2, Pivotal created a database that is easy to operate, at scale, even during Sev 1 incidents. It does this by not relying on any quorum algorithms. If a MySQL VM is ever recreated outside of a planned deployment, it returns in read-only mode.
MySQL for Pivotal Platform v2.2 was written with “Day 2” as a main priority. It makes recovering leader-follower instances simple by providing a few building blocks. Pivotal Platform operators don’t have to learn any new tools, as the building blocks are familiar BOSH errands. With the errands, a single command promotes a follower to resume service availability in the event of an unplanned outage.
Business Continuity is Key
When the infrastructure underneath your applications fails, as it inevitably will, you have to ensure the recoverability of your critical business data, the loss of which threatens your application’s ability to function and conduct business. Getting back online without massive data loss is key, and that’s what MySQL for Pivotal Platform v2.2 provides. It may be difficult to quantify the impact of downtime and data loss, but it’s not hard to understand that the cost is high in today’s high-demand business environment. In this regard, failure is not an option.
You can download MySQL v2.2 from Pivnet today.
About the Author
