a9s MySQL for Pivotal Cloud Foundry Beta Tile Release

Introduction

anynines’ data services team announces the beta release of its MySQL solution “a9s MySQL” for PCF.
The a9s MySQL tile allows to provision a MySQL 5.6 compatible service.

Where can you download the a9s MySQL tile?

You can find the a9s MySQL tile on the Pivotal Network at
https://network.pivotal.io/products/a9s-mysql.

Documentation is available at
https://docs.pivotal.io/partners/a9s-mysql

What is the a9s MySQL tile?

With a9s MySQL, we introduce a MySQL 5.6 compatible data service, thereby offering a highly performant, synchronously replicated multi-master database management system (DBMS). This means, that you can read from and write to all nodes in the cluster.
You do not have to worry about failovers, because this is taken care of for you: failing nodes can be tolerated, while a node returning from a state of failure will automatically re-join the cluster and replay all the changes which occurred during its absence. A failed node can also be replaced easily  with a new one.

a9s MySQL offers high performance, because it uses the Galera communication library. This library makes the latest concepts in database research available in order to avoid issues common to a two-phase commit based replication. An instance of the a9s MySQL service can easily be read,  written to and scaled without incurring an increasing number of write delays because of the way Galera implements replication.

How can you benefit?

It is a highly reliable service, because there is not one single point of failure in the cluster. Each member node of the cluster is a master and can be written to as well as read from.
If one node becomes unavailable, the remaining nodes continue to service query requests without any downtime. A change to the dataset is either applied to all active nodes or not at all. This way the consistency of the data set is guaranteed.
Each instance runs on a dedicated virtual machine (VM), which has the advantage of clearly defined networking, disk, CPU and I/O resources. Choosing different service plans results in different MySQL instances, that vary in performance and reliability.

How does it work?

In general terms Galera relies on two aspects:

  1. It considers the dataset of a DBMS as a state and all modifying operations on the dataset modify the state.
  2. Queries must be executed in the same order on all nodes in the cluster. This is achieved by using Global Transaction IDs (GTID). Changes to the state are packaged into GTIDs and executed on each node in order. Because of how GTIDs are computed, the Galera node notices if there was another transaction between two consecutive transactions and therefore it can ensure that all nodes have the same state at all time.

 Galera supports multi-master clusters, so each node in the cluster is a “master node”, which can accept modifying (write) queries (and of course read queries as well). That means, there is no single point of failure and the cluster service is highly available.
Usually this comes at the expense of performance, because multi-master, synchronous replication systems use some variant of the Paxos algorithm, which is known to deliver sub-prime performance. However, the Galera replication library allows to track changes to the dataset using the dataset’s “state” and global transactions replicated to all nodes in the cluster.
The individual nodes can execute these transactions independently; provided, the order of the transaction is kept up. This way, the process of synchronising all nodes can be done in one step instead of two which avoids significant delays. If the order of the transactions is not kept, then they will not be executed and the dataset will remain the same on all cluster nodes.

Should one of the nodes become unavailable/unresponsive (e.g. because of some technical issue), the remaining nodes continue to be available and thus, the service is not interrupted (until a configurable quorum cannot be met anymore). As soon as the unresponsive node is online again, it (re-)joins the cluster and asks the other nodes for the changes to the dataset that may have occurred in the meantime. After it incorporated the changes into its own copy of the dataset, it is available again to serve SQL queries.

Can I migrate/dump my database to a9s MySQL?

The a9s MySQL service supports the InnoDB engine, which is the most commonly used. You can import an .sql file to seed your a9s MySQL service instance. We will be happy to help you figure out how to start your a9s MySQL service instance.

What features are in the pipeline?

Currently we are working to make the a9s MySQL service compatible to MySQL 5.7 and the features introduced there. We will announce our progress soon.

Need further information?

Feel free to get in touch. Give us a call or leave a comment. We would appreciate your feedback very much.
Do you need to get a proof of concept installation running? Contact us for operations and installation support.

Sign up to anynines Newsletter

Sign up to anynines Newsletter to receive news about anynines, Cloud Foundry and more

Leave a Reply

Your email address will not be published. Required fields are marked *