Archive for the ‘High Availability’ Category

New White Papers from SkySQL on MariaDB, MySQL Cluster, HA & Enterprise Monitor

Декабрь 13th, 2011

Just in time for the holidays, SkySQL has published new white papers to keep you occupied while dealing with holiday travel delays, waiting for your turkey to roast, or hiding from your in-laws! Download them, today:

  • "Should I Migrate to Version 5.3 of the MariaDB Database?" - Written by Mark Riddoch, SkySQL's Senior Software Architect, this white paper looks at those features that have been added in the version 5.3 of the MariaDB™ database and compares them to what is available with version 5.5 of the MySQL® database. This white paper addresses the value that might be gained from migrating from version 5.5 of the MySQL database (or earlier) to version 5.3 of the MariaDB database.
  • "A Closer Look at MySQL Cluster:  An Architectural Overview" - MySQL® Cluster is a separate product from the standard MySQL database, despite their being tightly linked. Due to the distributed nature of MySQL Cluster, it has a far more complicated architecture than a standard MySQL database. This white paper, written by Max Mether, SkySQL's Training Services Manager, will describe the architecture of the MySQL Cluster product and how the process and data flow takes place between the nodes of the cluster. 

PlanetMySQL Voting: Vote UP / Vote DOWN

What’s new in MySQL 5.6 Replication – free webinar

Декабрь 12th, 2011

Global Transaction IDs - simplifying replication management

There will be a webinar this Wednesday where you can get the latest information on all of the great new content that has been included in the MySQL 5.6 Development Releases as well as some features that are still being developed. As always, the webinar is free but you need to register here in advance. Even if you can’t attend the live event it’s worth registering so that you get sent the replay.

Some of the topics we’ll be discussing are:

  • Enhanced data integrity: Global Transactions Identifiers, Crash-Safe Slaves and Replication Event Checksums;
  • High performance: Multi-Threaded Slaves, Binlog Group Commit and Optimized Row-Based Replication;
  • Improved flexibility: Time Delayed Replication, Multi-Source Replication, Binlog API and Informational Log Events
The event starts on Wednesday, December 14, 2011: 09:00 Pacific time; 17:00 UK; 18:00 CET.

PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL HA Solutions – webinar replay

Декабрь 7th, 2011

If you were unable to attend the live webinar (or you want to go back and listen to it again) then it’s now available to view on-line here.

Databases are the center of today’s web and enterprise applications, storing and protecting an organization’s most valuable assets and supporting business-critical applications. Just minutes of downtime can result in significant lost revenue and dissatisfied customers. Ensuring database highly availability is therefore a top priority for any organization. Tune into this webcast to learn more.

The session discusses:

  1. Causes, effect and impact of downtime
  2. Methodologies to map applications to HA solution
  3. Overview of MySQL HA solutions
  4. Operational best practices to ensure business continuity

PlanetMySQL Voting: Vote UP / Vote DOWN

Slides for Choosing a MySQL High Availability solution

Ноябрь 1st, 2011

Here are the slides to my first talk at Percona Live UK 2011: Choosing a MySQL High Availability solution.1

  1. 1. See this for a review of the conference as a whole: http://openlife.cc/blogs/2011/october/thanks-percona-and-attendees-great-percona-live-uk-2011

read more


PlanetMySQL Voting: Vote UP / Vote DOWN

Severalnines releases ClusterControl™ for MySQL Galera in cooperation with Codership

Октябрь 25th, 2011

Stockholm – October 25th 2011


Severalnines, provider of automation and management software for easily usable, highly available and auto-scalable cloud database platforms, today announces the release of ClusterControl™ for MySQL Galera in cooperation with Codership, the replication experts organisation that leverages the latest developments in computer science to produce fast and scalable synchronous replication solutions that "just work" for databases and similar applications.



Introducing ClusterControl™ for MySQL Galera


ClusterControl™ for MySQL Galera enables customers to Deploy, Manage, Monitor and Scale a clustered MySQL database platform based on Galera Replication.


Developers and DBAs now have access to all of the features of Severalnines' flagship product ClusterControl™ specifically adapted to MySQL Galera.


Designed to address issues and needs of MySQL users relying on MySQL Replication, ClusterControl™ for MySQL Galera offers a complete set of tools to assist developers and administrators of all skill levels to deploy, manage, monitor and scale their replicated MySQL databases.



What is MySQL Galera?


MySQL Galera is a synchronous multi-master cluster for MySQL/InnoDB or, in similar words, a synchronous multi-master replication plug-in for InnoDB. It is very different from the regular MySQL Replication and addresses a number of issues including write conflicts when writing on multiple masters, replication lag and slaves being out of sync with the master. Users do not have to know which server they can write to (the master) and which servers they can read from (the slaves). With MySQL Galera you can simply write and read from any MySQL Server.



Galera Cluster Use Cases


Galera replication works for a wide variety of use cases for high availability and scalability where you tolerate no lost of transactions or no slave lag or you look for write/read scalability Here are some common use cases where Galera can be used.


· Read Master

o Traditional MySQL master-slave topology, but with Galera all "slave" nodes are capable masters at all times, it is just the application who treats them as slaves. Galera replication can guarantee 0 slave lag for such installations and due to parallel slave applying, much better throughput for the cluster.

· Write Scalability

o Distributing writes across the cluster will harness the CPU power in slave nodes for better use to process client write transactions. Due to the row based replication method, only changes made during a client transaction will be replicated and applying such a transaction in slave applier is much faster than the processing of the original transaction. Therefore the cluster can distribute the heavy client transaction processing across many master nodes and this yields in better write transaction throughput overall.

· WAN Clustering

o Synchronous replication works fine over the WAN network. There will be a delay, which is proportional to the network round trip time (RTT), but it only affects the commit operation.

· Disaster Recovery

o Disaster recovery is a sub-class of WAN replication. Here one data center is passive and only receives replication events, but does not process any client transactions. Such a remote data center will be up to date at all times and no data loss can happen. During recovery, the spare site is just nominated as primary and application can continue as normal with a minimal fail over delay.

· Latency Eraser

o With WAN replication topology, cluster nodes can be located close to clients. Therefore all read & write operations will be super fast with the local node connection. The RTT related delay will be experienced only at commit time, and even then it can be generally accepted by end user, usually the kill-joy for end user experiences is the slow browsing response time, and read operations are as fast as they possibly can be.



Features and benefits of MySQL Galera


Galera features

· Active-active multimaster cluster

· Synchronous replication for InnoDB

· Read and write to any MySQL Server

· Automatic failover and node joining

· True Parallel replication

· Direct client connections


Galera benefits

· No slave lag or lost of data or out-of-sync situations.

o All nodes are consistent.

· Scales writes and reads

· Works synchronously over LAN/WAN/CLOUD

· No changes to applications


View all of the features here



Deploying a Galera cluster with ClusterControl™


A Galera cluster can be configured using the Severalnines Configurator


Our Online Tutorial provides an in-depth view and understanding of Galera cluster, covering the following topics:


· Introduction to Galera cluster

· Differences between MySQL Replication and Galera replication

· The pros and cons of Galera cluster

· Using Galera cluster to replicate between data centers

· Certification-based Replication

· Deploying a Galera cluster

· Failure handling with ClusterControl™ and Galera

· Adding a node to a Galera cluster

· Schema changes in Galera cluster



Try the ClusterControl™ Configurator for MySQL Galera today or book a demo to see it live in action!


· ClusterControl™ Configurator for MySQL Galera – try it today!

· Online Tutorial – ClusterControl™ for MySQL Galera

· Severalnines Knowledge Base

· Book a demo!


Please do reach out to us with your feedback on Facebook, LinkedIn, XING or directly via these contact details for fruitful and interactive discussions on this latest release. For 'instant' communication, feel free to follow us on Twitter!



About Severalnines


Severalnines provides automation and management software for easily usable, highly available and auto-scalable cloud database platforms. ClusterControl™, the company’s flagship product, used by developers and administrators of all skill levels, addresses the full deploy-manage-monitor-scale cycle. Severalnines has enabled over 7,000 deployments to date via its popular online configurator for clustered MySQL databases.


To see who is using Severalnines today, please visit our references page.



About Codership

Codership Oy was founded in 2007 by database clustering experts to exploit the latest developments in computer science and produce fast & scalable synchronous replication solutions for databases and similar applications. Currently, Codership offers multi-master cluster for MySQL database as open source. For more information about our open source MySQL Galera software and support offering, visit www.codership.com



© 2011 Severalnines AB. Severalnines and the Severalnines logo(s) are trademarks of Severalnines AB. MySQL is a registered trademark of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.


PlanetMySQL Voting: Vote UP / Vote DOWN

Free webinar on preventing MySQL downtime

Октябрь 13th, 2011

I’ll be presenting a free one-hour webinar on preventing downtime in production MySQL servers, in conjunction with the ODTUG. It is scheduled on Thursday, November 10, 2011 3:00 PM – 4:00 PM EST, and you can register for free.

Here’s an abstract of what you’ll learn:

Everyone wants to prevent database downtime by being proactive, but how effective are the common measures such as inspecting logs and analyzing SQL? To be truly proactive, one must prevent problems, which requires studying and understanding the reasons for downtime. We have analyzed a selection of emergency issues that we have solved, to better understand what types of problems really occur in production environments. The results are somewhat surprising, and will be detailed in this talk. Most incidents we found were not MySQL-specific and will be familiar to Oracle DBAs as well as MySQL DBAs. This presentation will be valuable for the new or seasoned DBA, as well as to operational managers/directors and CTOs responsible for business critical implementations.

Please register today and I look forward to joining you.

Further Reading:


PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL HA shootout at Percona Live UK

Октябрь 11th, 2011

I'm looking at the schedule for Percona Live UK coming up in 2 weeks from now and realize there's quite a smorgasbord of High Availability talks. What's more interesting, I see that we will be presenting some opposite opinions for the audience to digest:

read more


PlanetMySQL Voting: Vote UP / Vote DOWN

Severalnines releases ClusterControl™ for MySQL Replication v. 1.1.9

Октябрь 4th, 2011
Stockholm - October 4th 2011

Severalnines, provider of automation and management software for easily usable, highly available and auto-scalable cloud database platforms, today announces the latest release of its flagship product ClusterControl™ for MySQL Replication.

Introducing ClusterControl™ for MySQL Replication v.1.1.9

ClusterControl™ for MySQL Replication enables customers to Deploy, Manage, Monitor and Scale a clustered database platform based on the standard MySQL Replication.

Developers and DBAs now have access to all of the features of Severalnines' flagship product ClusterControl™ specifically adapted to MySQL Replication.

Designed to address issues and needs of MySQL users relying on MySQL Replication, ClusterControl™ for MySQL Replication offers a complete set of tools to assist developers and administrators of all skill levels to deploy, manage, monitor and scale their replicated MySQL databases.

Features and benefits

Config wizard
- Generates individual configurations based on application needs
- Creates deployment packages
- Deploys a Replication cluster in minutes
Config manager
- Sanity checks changes to configuration parameters
- Rolls out configuration changes to all servers and automates rolling restarts
Upgrade advisor
- Keeps users up-to-date by performing upgrades
- Applies minor patches or major upgrades
- Allows roll-back to previous versions
Availability manager
- Clusterware that detects process failures
- Automates MySQL master fail-over
- Performs recovery of failed database processes
Backup manager
- Schedule backups or allow users to start an immediate backup
- Monitor and browse existing backups
- Define retention policies
- No proprietary data formats
Monitor
- Granular end-to-end transaction and database operation monitoring
Query analyzer
- Analysis on cluster-wide running queries
- Global MySQL processlist
- Deep real-time and historical visibility into individual nodes
Alarms and notifications
Scale
- Add new Slaves (or remove) to the cluster without any downtime
- Easily specify hostnames of Slaves to be added

View all of the features here.

Automated fail-over with ClusterControl™

Standard MySQL Replication is easy to set up, and is probably the most widely used mechanism to provide high availability for MySQL. Unfortunately, it is somewhat fragile. There is no support for fail-over. Slaves can easily end up with different data from the master. Diverging datasets can cause replication to stop. Crashing masters can corrupt binary logs, which means replication is not possible any more.

ClusterControl™ addresses the problems associated with master fail-over and resynchronizations, and avoids data loss by taking advantage of semi-sync replication in MySQL 5.5.

ClusterControl™ automates fail-over and reconfiguration of the replication setup to keep the Replication cluster stable and running. This online tutorial explains the MySQL Replication architecture, and how different types of failures are handled.

Users can try it now by generating their deployment package.

Reources related to this release


Configurator for MySQL Replication
Tutorial: ClusterControl for MySQL Replication
Videos: Online Demos on MySQL Replication
Book a demo

Please do reach out to us with your feedback on Facebook, LinkedIn, XING or directly via these contact details for fruitful and interactive discussions on this latest release. For 'instant' communication, feel free to follow us on Twitter!

About Severalnines

Severalnines provides automation and management software for easily usable, highly available and auto-scalable cloud database platforms. ClusterControl™, the company’s flagship product, used by developers and administrators of all skill levels, addresses the full deploy-manage-monitor-scale cycle. Severalnines has enabled over 7,000 deployments to date via its popular online configurator for clustered MySQL databases.

To see who is using Severalnines today, please visit our references page.

PlanetMySQL Voting: Vote UP / Vote DOWN

Lack of Business Visibility Cripples Traditional SQL DaaS, Drives NewSQL

Сентябрь 23rd, 2011
More and more public cloud companies are moving to managed cloud services to improve their value-add (price premium) and the stickiness of their solution. However, the shift to a database as a service (DaaS) severely reduces the DBAs visibility into the business, thus limiting the ability to hand tune the database to the requirements of the application and the database. The solution is a cloud database that eliminates the hand-tuning of the database, thereby enabling the DBA to be equally effective even with limited visibility into the business and application needs. It is these unique needs, particularly for SQL databases, that is fueling the NewSQL movement.

DBAs traditionally have insight into the company, enabling them to hand tune the database in a collaborative basis with the development team, such as:

1. Performance Trade-offs/Tuning: The database is partitioned and tuned to address business requirements, maximizing performance of certain critical processes, while slowing less critical processes.

2. System Maintenance Planning: You need to shut down the database to do an application/database upgrade, repartition, etc. but you may need to coordinate with the development team, and the schedule may change up until the last moment.

3. Application Evolution: The database must be designed and tuned to accommodate the planned changes in the application.

4. Consulting with Application Developers: Since the database partitioning and performance are hand-tuned, the DBA must collaborate closely with the application development team on design, development and deployment.

5. Partitioning Requirements: When partitioning (or repartitioning) your database you’ll need to partition the data to suit application requirements avoiding things like cross partition joins, range scans, aggregates, etc., which can cause tremendous performance penalties if not implemented correctly.

6. Moving Processes to the Application Layer: Single server databases can handle joins, range scans, aggregates and the like internally. However, when you partition the database these functions are typically moved to the application layer. The application must add the logic to accomplish these things. It must also add the routing code to point to the correct partitions. As a result, an application written to a single server API does not work in a multi-server configuration.

When moving from a self-managed database—either in the cloud or on premise—to a DaaS, the “DBA-in-the-cloud” doesn’t have that visibility into the business requirements, performance requirements, development schedule, and more. This lack of visibility turns the already challenging task of hand-tuning the database into a near impossibility using traditional databases.

A real world example: You are the DBA-in-the-cloud. Your customer has been running on a single server, but they need to now scale-out across multiple database nodes to accommodate growth. How do you split the data? You don’t know which queries have higher performance priority. You don’t know the development plan for new version of the application. You don’t know when it is convenient to shut down the application to implement the partitioning. You need to inform the application developers how they should implement their routing code to send database requests to the right nodes. You need to inform the application developers that they need to handle joins, range scans and aggregates at the application level, since the database can no longer handle those.

DBAs have enough of a challenge scaling and maintaining databases when they have full visibility into the business. To address these challenges without that level of visibility is unrealistic. I refer to this problem as the “Blind DBA” challenge, because the DaaS DBA has a serious lack of visibility into the requirements and inner workings of the company.

ScaleDB is a NewSQL database uniquely designed to handle the Blind DBA challenge inherent in DaaS implementations. ScaleDB is based on a shared-disk architecture that scales in a manner that is invisible to the application. It eliminates the need to push functions (joins, range scans, aggregates) up to the application layer. It eliminates the need to coordinate your application and database design to work around partitions, because there are no partitions. It eliminates the performance tradeoffs in partitioning design, you get consistent performance across the database. It eliminates scheduling and coordinating application shut-down to repartition, because it doesn’t use partitions. In short, with ScaleDB the DBA needn’t have any visibility into the business to deliver optimal database performance via a single API. This is what makes ScaleDB an ideal solution for cloud companies implementing the database as a managed service or DaaS.


PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL with Windows Server 2008 R2 Failover Clustering

Сентябрь 6th, 2011

Windows Server 2008 R2 Failover Clustering

Oracle has announced support for running MySQL on Windows Server Failover Clustering (WSFC); with so many people developing and deploying MySQL on Windows, this offers a great option to add High Availability to MySQL deployments if you don’t want to go as far as deploying MySQL Cluster.

This post will give a brief overview of how to set things up but for all of the gory details a new white paper MySQL with Windows Server 2008 R2 Failover Clustering is available – please give me any feedback. I will also be presenting on this at a free webinar on Thursday 15th September (please register in advance) as well at an Oracle OpenWorld session in San Francisco on Tuesday 4th October (Tuesday, 01:15 PM, Marriott Marquis – Golden Gate C2) – a good opportunity to get more details and get your questions answered.

It sometimes surprises people just how much MySQL is used on Windows, here are a few of the reasons:

  • Lower TCO
    • 90% savings over Microsoft SQL Server
    • If your a little skeptical about this then try it out for yourself with the MySQL TCO Savings Calculator
  • Broad platform support
    • No lock-in
    • Windows, Linux, MacOS, Solaris
  • Ease of use and administration
    • < 5 mins to download, install & configure
    • MySQL Enterprise Monitor & MySQL WorkBench
  • Reliability
    • 24×7 Uptime
    • Field Proven
  • Performance and scalability
    • MySQL 5.5 delivered over 500% performance boost on Windows.
  • Integration into Windows environment
    • ADO.NET, ODBC & Microsoft Access Integration
    • And now, support for Windows Server Failover Clustering!
Probably the most common form of High Availability for MySQL is MySQL (asynchronous or semi-synchronous replication) and the option for the highest levels of availability is MySQL Cluster. We are in the process of rolling out a number of solutions that provide levels of availability somewhere in between MySQL Replication and MySQL Cluster; Oracle VM Template for MySQL Enterprise Edition was the first (overview, webinar replay, white paper) and WSFC is the second.

 

Solution Overview

MySQL with Windows Failover Clustering requires at least 2 servers within the cluster together with some shared storage (for example FCAL SAN or iSCSI disks). For redundancy, 2 LANs should be used for the cluster to avoid a single point of failure and typically one would be reserved for the heartbeats between the cluster nodes.

The MySQL binaries and data files are stored in the shared storage and Windows Failover Clustering ensures that at most one of the cluster nodes will access those files at any point in time (hence avoiding file corruptions).

Clients connect to the MySQL service through a Virtual IP Address (VIP) and so in the event of failover they experience a brief loss of connection but otherwise do not need to be aware that the failover has happened other than to handle the failure of any in-flight transactions.

Target Configuration

This post will briefly step through how to set up and use a cluster and this diagrams shows how this is mapped onto physical hardware and network addresses for the lab used later in this post. In this case, iSCSI is used for the shared storage. Note that ideally there would be an extra subnet for the heartbeat connection between ws1 and ws3.

This is only intended to be an overview and the steps have been simplified refer to the white paper for more details on the steps.

Prerequisites

  • MySQL 5.5 & InnoDB must be used for the database (note that MyISAM is not crash-safe and so failover may result in a corrupt database)
  • Windows Server 2008 R2
  • Redundant network connections between nodes and storage
  • WSFC cluster validation must pass
  • iSCSI or FCAL SAN should be used for the shared storage

Step 1 Configure iSCSI in software (optional)

Create 2 clustered disks

This post does not attempt to describe how to configure a highly available, secure and performant SAN but in order to implement the subsequent steps shared storage is required and so in this step we look at one way of using software to provide iSCSI targets without any iSCSI/SAN hardware (just using the server’s internal disk). This is a reasonable option to experiment with but probably not what you’d want to deploy with for a HA application. If you already have shared storage set up then you can skip this step and use that instead.

As part of this process you’ll create at least two virtual disks within the iSCSI target; one for the quorum file and one for the MySQL binaries and data files. The quorum file is used by Windows Failover Clustering to avoid “split-brain” behaviour.

Step 2. Ensure Windows Failover Clustering is enabled

Ensure that WSFC is enabled

To confirm that Windows Failover Clustering is installed on ws1 and ws3, open the “Features” branch in the Server Manager tool and check if “Failover Cluster Manager” is present.

If Failover Clustering is not installed then it is very simple to add it. Select “Features” within the Service Manager and then click on “Add Features” and then select “Failover Clustering” and then “Next”.

 

 

Step 3. Install MySQL as a service on both servers

Install MySQL as a Windows Service

If MySQL is already installed as a service on both ws1 and ws3 then this step can be skipped.

The installation is very straight-forward using the MySQL Windows Installer and selecting the default options is fine.

Within the MySQL installation wizard, sticking with the defaults is fine for this exercise. When you reach the configuration step, check “Create Windows Service”.

The installation and configuration must be performed on both ws1 and ws2, if necessary.

Step 4. Migrate MySQL binaries & data to shared storage

If the MySQL Service is running on either ws1 or ws3 then stop it – open the Task Manager using ctrl-shift-escape, select the “Services” tab and then right-click on the MySQL service and choose “Stop Service”.

As the iSCSI disks were enabled on ws1 you can safely access them in order to copy across the MySQL binaries and data files to the shared disk.

Step 5. Create Windows Failover Cluster

Create the Cluster (without MySQL)

From the Server Manager on either ws1 or ws3 navigate to “Features -> Failover Cluster Manager” and then select “Validate a Configuration”. When prompted enter ws1 as one name and then ws3 as the other.

In the “Testing Options” select “Run all tests” and continue. If the tests report any errors then these should be fixed before continuing.

Now that the system has been verified, select “Create a Cluster” and provide the same server names as used in the validation step. In this example, “MySQL” is provided as the “Cluster Name” and then the wizard goes on to create the cluster.

Step 6. Create Cluster of MySQL Servers within Windows Cluster

Cluster the MySQL Service

Adding the MySQL service to the new Cluster is very straight-forward. Right-click on “Services and applications” in the Server Manager tree and select “Configure a Service or Application…”. When requested by the subsequent wizard, select “Generic Service” from the list and then “MySQL” from the offered list of services. Our example name was “ClusteredMySQL”. Please choose an appropriate name for your cluster. The wizard will then offer the shared disk that has not already been established as the quorum disk for use with the Clustered service – make sure that it is selected.

Once the wizard finishes, it starts up the MySQL Service. Click on the “ClusteredMySQL” service branch to observe that the service is up and running. You should also make a note of the Virtual IP (VIP) assigned, in this case 192.168.2.18.

Step 7. Test the cluster

As described in Step 6, the VIP should be used to connect to the clustered MySQL service:

C:\ mysql –u root –h 192.168.2.18 –P3306 –pbob

From there create a database and populate some data.

mysql> CREATE DATABASE clusterdb;
mysql> USE clusterdb;
mysql> CREATE TABLE simples (id int not null primary key) ENGINE=innodb;
mysql> INSERT INTO simples VALUES (1);
mysql> SELECT * FROM simples;
+----+
| id |
+----+
| 1 |
+----+

Migrate MySQL Service Across Cluster

The MySQL service was initially created on ws1 but it can be forced to migrate to ws3 by right-clicking on the service and selecting “Move this service or application to another node”.

As the MySQL data is held in the shared storage (which has also been migrated to ws3), it is still available and can still be accessed through the existing mysql client which is connected to the VIP:

mysql> select * from simples; 
ERROR 2006 (HY000): MySQL server has gone away 
No connection. Trying to reconnect... 
Connection id: 1 
Current database: clusterdb 
+----+ 
| id | 
+----+ 
| 1 | 
+----+

Note the error shown above – the mysql client loses the connection to the MySQL service as part of the migration and so it automatically reconnects and complete the query. Any application using MySQL with Windows Failover Cluster should also expect to have to cope with these “glitches” in the connection.

Conclusion

More users develop and deploy and MySQL on Windows than any other single platform. Enhancements in MySQL 5.5 increased performance by over 5x compared to previous MySQL releases. With certification for Windows Server Failover Clustering, MySQL can now be deployed to support business critical workloads demanding high availability, enabling organizations to better meet demanding service levels while also reducing TCO and eliminating single vendor lock-in.
Please let me know how you get on by leaving comments on this post.


PlanetMySQL Voting: Vote UP / Vote DOWN