Friday, April 27, 2012

SchoonerSQL Automates Failure Handling & Failover

There are different types of failures in the database environment ranging from the loss of the network, to the loss of an instance, all the way to the loss of a node (the server hardware). A robust database is one that can detect such failures and automate the failover and recovery process without any user intervention.
SchoonerSQL does exactly that: it detects failures and provides an immediate and automated failover process.
Below are the failover scenarios and how SchoonerSQL will handle them.

Instance Failure
Consider three instances in a synchronous replication group where Node 1 has the master instance, and Node 2 and Node 3 have slave instances.
The master has one write virtual IP ( and one read virtual IP (; slave instances have read virtual IPs (, as shown in the diagram below.

When a master instance fails due to a crash or a shutdown, the failure handler will immediately detect it and migrate all the virtual IPs from the failed instance to Node 2 & Node 3. The entire process is generally quick with an average failover time of 3 to 5 seconds.
Clients automatically connect to the surviving node and continue running the queries. The entire operation is transparent to the end-user.
SchoonerSQL also possess self-healing capability with an auto restart when a crash happens. The instance will rejoin the cluster once it catches up and is in sync (virtual IPs will be re-distributed to this instance automatically when it joins the group). 
Node Failure
The failure handler detects when the entire node crashes or shuts down. Virtual IPs will then be migrated from the failed node to the instances on the remaining live nodes in the cluster.
Replication Network Failure
Consider two instances, one acting as master with write, read virtual IPs and the other acting as slave with read virtual IP.
Consider a scenario where the replication network fails causing network partitioning. The failure handler immediately detects this and shuts down the slave. The virtual IP of the slave is then migrated over to the master as shown in the diagram.
To conclude, SchoonerSQL not only detects failures but also automates the failover process thereby providing users a seamless and a transparent experience.

Thursday, April 19, 2012

Two Schooner webinars next week (April 25th, 26th)

Register for this webinar "Replication, Read-Consistent Slaves & Redundancy" where we'll discuss various replication solutions and explain why SchoonerSQL offers the best synchronous replication solution. The webinar will also cover performance benchmarks and how read-consistent slaves (redundant database nodes) can help your application stay online 24x7, providing 99.999% availability. 

Replication, Read-Consistent Slaves & Redundancy
Thursday, April 26, 2012, 10 a.m. PT / 1 p.m. ET
Webinar link

There is also another webinar on how you can "Free your Data and Budget".  This is a business discussion aimed at helping IT decision makers make better choices to protect their buying power, while lowering the overall license and support costs associated with maintaining their IT data centers. Before you default to your existing high availability database vendor for your next new deployment, listen to this webinar. 

Free your Data, Free your Budget: New Choices in the Enterprise Database Market  
Wednesday, April 25, 2012, 10 a.m. PT / 1 p.m. ET
Webinar Link

Sunday, April 15, 2012

20 Real-World Use Cases to help pick a better MySQL replication scheme

Darpan Dinker (VP of Engineering at Schooner) presented a talk on "MySQL Replication Pros-Cons: Which replication mechanism to choose and why" at Percona Live conference last week. The presentation focused on
  • Achieving Higher Performance
  • Uptime
  • Reliability
  • And Simplicity for Real-World Use Cases. 
Presentation slides can be viewed in the link below

Wednesday, April 11, 2012

Schooner Welcomes Percona’s Entry into the High-Availability MySQL Market

Schooner announced initial benchmarks of SchoonerSQL™ against the new Percona XtraDB Cluster. Percona XtraDB Cluster is a distribution of Percona Server with the Galera HA toolkit.

Standard benchmarks are a proxy for the performance that users may see with their own workloads. Schooner ran the standard DBT2 benchmark, which is the open-source OLTP version of the TPC-C benchmark, using a heavy workload of 1,000 warehouses with 32 concurrent connections to the database and zero think time. Measurements in each case were made using a typical two-node master-slave configuration. Each node was a standard IBM x86 server with 12/24 processor cores/threads, 72 GB of DRAM, and two 320 GB Fusion-io ioDriveDuos, running Red Hat Enterprise Linux 6.2. 

SchoonerSQL Delivers Three Times the Throughput of New Percona XtraDB Cluster, with 1/4th the Response Time and Half the Total Cost of Ownership

Press Release Link

Tuesday, April 3, 2012

Plaxo picks SchoonerSQL over Oracle

World’s leading online address book, Plaxo, deploys SchoonerSQL instead of Oracle database.
Watch this on-demand webinar where Ethan Erchinger, VP of Operations and Solution
Architecture at Plaxo, talks about the CIO challenge he faced and why he chose to deploy
SchoonerSQL instead of Oracle.
Also hear how SchoonerSQL offers IT decision makers an alternative that delivers both high
performance and high availability at a lower license cost than status-quo solutions.