Schooner beefs MySQL appliance with active clusters MySQL database clustering needs some help, and Schooner Information Technology thinks it has cooked up the code to help companies that rely on MySQL do a better job scaling out their databases. "There's a widespread concern that MySQL clustering is a little kludgey, doesn't have great performance, and can sometimes lose …
How does this scale-out? Each node has to hold the entire database, and be able to handle all the writes. Reads can be spread out, but not writes or data. If you need to hold more data or handle more writes you would have to upgrade all the nodes to beefier hardware. Or you have to shard. That sounds like scale-up not out.
In a typical scale out deployment for a MySQL service, granular sharding with small masters is required since the throughput and update rate of MySQL has been so limited. Also, each master is configured with many slaves to scale reads using MySQL asynchronous replication. The slaves lag behind the master causing stale and inconsistent data reads, and the slaves perform at a low performance level due to serial application of updates, increasing the number of required slaves. Failover of master or slaves is an error prone, manual, long process. These issues create a lot of pain for administrators, and negatively impact the quality of service (performance and availability) as well as capital and operating expenses.
Schooner MySQL core fully exploits commodity hardware allowing very large masters with extremely high performance and update traffic(effective scale-up), typically 4-20x the throughput of legacy MySQL. Schooner MySQL Active Cluster provides fully consistent data across the master and each of its slaves, very high perfromance with parallel synchronous replication, and instantaneous, transparent failover, In most cases, Schooner master performance is plenty for the natural database partitions, and master subsharding is not required (in contrast to legacy mysql). Read scaling with slaves is linear, with very simple administration to create, migrate, etc. This is coupled with fast automatic fail-over and recovery for masters or slaves. Descriptions of innovations, analysis, and benchmarks are available at www.SchoonerInfotech.com.
The net results of all of this is that building a scale-out MySQL service with excellent quality of service (high thoughput, low response time, high availability) and low TCO is much easier and cost effective with Schooner MySQL.
We recently painlessly upgraded to MySQL 5.5 and a lot of the replication issues we used to have seem to have been fixed. It looks like the recent 5.6 milestone release is also concentrating a lot on improving scaling, though it is still several months away from production use.
Were still proceeding cautiously with our MySQL projects but apart from the initial negative hype Oracle so far do seem to be putting good effort into improving the product.
Watch this space I guess
MySQL 5.5 provides semi-synch replication, which can eliminate data loss in the event of a master failure. But it comes at a price in latency, and it does not resolve slave lag or provide automated fail-over or reduce downtime. 5.6 fixes data corruption issues, but the scaling improvements in 5.6 with parallel thread appliers only work for independent databases.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
