MySQL High Availability – Guaranteed!
Get up & running with Xeround in minutes!
- No Downtime SLA Guarantee
- Built-in Replicas for High Availability
- No Configuration Required
- Zero Maintenance
- No Changes Required to Your App
MySQL Availability Challenges in the Cloud:
The continuous operation of any database-driven application is dependent on the availability of its underlying database.
The traditional challenges of maintaining a highly-available database are only compounded by the dynamic and unpredictable nature of the cloud. Maintaining high availability in the cloud isn’t just about hardware resiliency anymore (as in your on-premise datacenter), but it is dependent on the availability of ‘more of the same’ resources and the ability to dynamically provision them across the entire resiliency chain.
To maintain high-availability in the cloud you need to closely monitor the cloud environment for any failures, and be able to react in a way that’s:
- Immediate – So it won’t affect the availability of the service
- Transparent – So that the application is unaware of it
- Painless – So you won’t lose sleep over availability issues and trying to keep up with maintaining the service.
There isn’t much you can do to lower the chances of a cloud machine failing, but in case it fails (or WHEN it fails) – you want to be able to seamlessly provision a new one on-the-fly and maintain service.
With Xeround’s unique self-healing architecture and built-in replicas, you ensure high availability and full resiliency of your database in the event of failure and schema changes — and all with just 1 click. With failover handled automatically, you are spared the monitoring, maintenance, and configuration updates to ensure your DB is always on.
Xeround’s Highly-Available Architecture:
Xeround is a distributed cloud database. Its availability is guaranteed because it doesn’t have any single point of failure and because all the system components are automatically replicated and distributed across several cloud servers for failover purposes.
Xeround’s technology allows for arbitrarily setting the number of data replicas that the service manages, as well as the role each plays and the location each resides in. Today our service is offered with two active-active replicas, with additional high availability options offered soon.
Xeround’s Auto-Healing Capabilities:
If a cloud server fails, all the data is still available in the surviving replicas and the DB is operational. As the self-healing process kicks in, replacement servers are acquired on-the-fly and re-sync is executed from the remaining replicas.
Under the Hood:
Availability via Redundancy
Xeround’s distributed database-as-a-service architecture consists of three separate functional layers working in tandem to provide the service. Each layer is multiplied and automatically replicated so it is independently highly available – so the service is always maintained:
Load Balancing Layer
Load Balancing Layer
Each of Xeround’s database instances is accessible via a unique hostname. When establishing a connection to the database instance, round-robin DNS is used to automatically resolve this hostname to one of the active load balancers that are used by that instance.
A load balancer’s failure disconnects all open connections to it but new connections can be opened against any of the remaining load balancers. Depending on the failure’s nature, the failed load balancer is either re-launched or a new load balancer is instantiated by the service automatically.
MySQL Engine Layer
MySQL Engine Layer
Statement processing and result set retrieval are handled by a set of MySQL engine processes. Each engine process is stateless and only keeps the contexts of its currently active transactions. Although the failure of an engine process will cause a rollback all of its in-flight & non-committed transactions and disconnect all connections to it, connections can be re-opened and the transactions re-attempted against any of the surviving engines.
A failed engine process is automatically restarted or re-deployed, depending on the nature of the failure, by the service in order to return to normal operational parameters.
Data Storage Layer
Data Storage Layer
Data is managed across multiple, dedicated data storage backend processes. The database is automatically and transparently segmented to virtual partitions in such a fashion that each of the instance’s data backend processes is assigned with a sub-set of the database’s partitions to manage.
Each data partition is replicated internally between several backend processes, so the effects of any given data storage backend’s failure are seamlessly mitigated by the existence of surviving data replicas that are managed by other backends. The lost replicas of data partitions are automatically “re-grown” within the data storage layer, while the service restores lost data management capacity by restarting the failed process or replacing it with a newly-deployed one.
Additionally, all operations in Xeround are non-blocking and parallelized so the database is kept available at all times. Our service’s distributed design makes it all but impossible for the database to “freeze” when executing a particularly resource-intense statement and enables other statements to continue unhindered. Administrative and operational tasks, such as schema management and database backups, are done online and without the need to lock or shut down the database. In most cases, even the service’s maintenance procedures, including servers’ management and software updates, are carried out in the background without interrupting the database’s availability.
Xeround’s distributed architecture supports both high availability and extremely granular elasticity. See how Xeround’s database layers deliver seamless and unlimited MySQL scalability for both throughput and size.
