Posted on July 23rd, 2010 10 comments
There is a new video available: Demonstration of installing, configuring and running MySQL Cluster (LINUX) to accompany the MySQL Cluster Quick Start guides. The Flash video video lasts for about 7 minutes.
If you aren’t able to view Flash on your device then a (poorer quality) version is included here – watch the Flash version if you’re able to!
Posted on July 22nd, 2010 No comments
With the release of openSUSE 11.3 they announced the inclusion of MySQL Cluster. What does this mean as you could already install and run MySQL Cluster on openSUSE (and any other LINUX platform for that matter)? The change is that you can now use their tool (zypper) to install the MySQL Cluster RPMs and most importantly replace the ‘regular’ MySQL Server with the one that should be used with MySQL Cluster.
Personally I prefer installing MySQL Cluster from the tar ball as it gives me more control (for example, openSUSE is using MySQL Cluster 7.0 but I prefer to use 7.1 as that’s the latest GA release). Having said that, I was pleasantly surprised at how simple it was using the zypper tool (running as root):
linux-b3ga:/home/billy # zypper install mysql-cluster Loading repository data... Reading installed packages... Resolving package dependencies... Problem: mysql-cluster-7.0.13-2.10.i586 conflicts with namespace:otherproviders(mysql) provided by mysql-community-server-5.1.46-2.18.i586 Solution 1: Following actions will be done: deinstallation of mysql-community-server-5.1.46-2.18.i586 deinstallation of mysql-community-server-client-5.1.46-2.18.i586 Solution 2: do not install mysql-cluster-7.0.13-2.10.i586 Choose from above solutions by number or cancel [1/2/c] (c): 1 Resolving dependencies... Resolving package dependencies... The following NEW packages are going to be installed: libmysqlclusterclient16 libmysqlclusterclient_r16 mysql-cluster mysql-cluster-client The following packages are going to be REMOVED: mysql-community-server mysql-community-server-client 4 new packages to install, 2 to remove. Overall download size: 8.4 MiB. After the operation, additional 1.4 MiB will be used. Continue? [y/n/?] (y): y Removing mysql-community-server-5.1.46-2.18 [done] Additional rpm output: Shutting down service MySQL ..done Removing mysql-community-server-client-5.1.46-2.18 [done] Retrieving package libmysqlclusterclient_r16-7.0.13-2.10.i586 (1/4), 484.0 KiB (1.4 MiB unpacked) Retrieving: libmysqlclusterclient_r16-7.0.13-2.10.i586.rpm [done (455.5 KiB/s)] Installing: libmysqlclusterclient_r16-7.0.13-2.10 [done] Retrieving package libmysqlclusterclient16-7.0.13-2.10.i586 (2/4), 483.0 KiB (1.4 MiB unpacked) Retrieving: libmysqlclusterclient16-7.0.13-2.10.i586.rpm [done (67.2 KiB/s)] Installing: libmysqlclusterclient16-7.0.13-2.10 [done] Retrieving package mysql-cluster-client-7.0.13-2.10.i586 (3/4), 150.0 KiB (339.0 KiB unpacked) Retrieving: mysql-cluster-client-7.0.13-2.10.i586.rpm [done] Installing: mysql-cluster-client-7.0.13-2.10 [done] Retrieving package mysql-cluster-7.0.13-2.10.i586 (4/4), 7.3 MiB (26.9 MiB unpacked) Retrieving: mysql-cluster-7.0.13-2.10.i586.rpm [done (583.8 KiB/s)] Installing: mysql-cluster-7.0.13-2.10 [done]
At this point the regular MySQL Server (mysqld) has been replaced with the one designed for use with MySQL Cluster (still works for other storage engines).
As I also want to run the management and data nodes on the same server, I installed those too (along with the tools):
linux-b3ga:/home/billy # zypper in mysql-cluster-ndb-management
linux-b3ga:/home/billy # zypper in mysql-cluster-ndb-storage
linux-b3ga:/home/billy # zypper install mysql-cluster-ndb-tools
Once the installations are complete you can configure, fire up and test MySQL Cluster as described in previous post. Note that ndb_mgmd, ndbd/ndbmtd and mysqld will be in /usr/sbin while mysql_install_db, ndb_mgm and mysql will be in /usr/local/bin.
When you connect the mysql client, you’ll see a confirmation that you’re using the MySQL Cluster version of the MySQL Server:
billy@linux-b3ga:~/my_cluster> mysql -u root -h 127.0.0.1 -P3306
Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: 5.1.41-ndb-7.0.13 SUSE MySQL Cluster RPM
Posted on July 13th, 2010 4 comments
Many people use the MySQL MEMORY storage engine for applications where they don’t need their data to be highly available or even survive restarts. Where this works best is for applications that are dominated by reads and (obviously) where the data doesn’t need to survive any kinds of problems (or where it can be recovered from another source). Typical applications are :
- Caching of small tables to reduce the latency of database look-ups.
- Simple session management (i.e. with no analytics or reporting on the session data).
- Buffering of multiple updates for batched inserts into tables managed by other MySQL storage engines. (Note requires additional custom application development).
While great for some applications (at least initially), as the application requirements start to grow (need for transactions, data persistence/durability, increasing number of write operations, need to scale) then either you need to migrate away from MEMORY or implement more and more data management functionality needs in your application.
Why not consider using MySQL Cluster instead? While the headline Cluster configurations may scale out horizontally and provide 99.999+% availability, it is simple to configure out those features to provide a pure-memory, single host database as described in “How can a database be in-memory and durable at the same time?“. What’s more if/when you need to add extra capabilities such as ACID transactions, scalability and high availability then those features are all available to you.
If you’re constrained to a single server and your application only reads data then there is a performance impact in using MySQL Cluster (in benchmarks, throughput was 3x higher for MEMORY) but remember that you can scale out MySQL Cluster to increase performance and for models with modest write rates MySQL Cluster provides a massive performance boost even when constrained to 1 server (as shown in the graph at the head of this post, Cluster delivers a 30x improvement performance improvement when running a Sysbench benchmark – together with a 3x reduction in latency). The biggest single reason for the massive performance difference is that MySQL Cluster has row-based locks whereas MEMORY uses table-level locks.
For a more detailed comparison, take a look at the new “Scaling Web Services with MySQL Cluster: An Alternative to the MySQL Memory Storage Engine” white paper and/or listen to the associated webinar.
Migrating Data from The Memory Storage Engine to MySQL Cluster
As a starting point, it is important to understand that the MySQL Server (mysqld) binary that is provided as part of MySQL Community Edition or MySQL Enterprise Server is not suitable for use with MySQL Cluster. Therefore it is necessary to migrate your database to an instance of mysqld that is packaged with the MySQL Cluster software.
This post looks at how to migrate your data from a ‘regular’ MySQL Server to MySQL Cluster. Although MySQL Cluster is typically run over multiple servers to provide High Availability (HA), for this example migration it is run on a single server (the logic being that we’re replacing a MEMORY database that has no HA requirements). If you want to move to a HA configuration then the main change is that the MySQL Cluster configuration should include more nodes (processes) and they should be spread across multiple physical hosts. The example actually goes a step further in compromising HA and turns off the checkpointing of data to disk for the migrated tables – getting closer to the behavior of MEMORY tables.
For this example, there are assumed to be 2 MySQL installations on the server – the original binaries in <mysql-bin> and the ones for MySQL Cluster in <mysql-cluster-bin>.
Data in MyISAM and InnoDB tables (including system data such as user privileges and stored procedures) will appear in the new MySQL Server automatically. By default the contents (but not schema) for the MEMORY tables will be lost. If it is important to keep that MEMORY data then use the mysqldump command to make a copy:
[my_db]$ <mysql-bin>/mysqldump -h 127.0.0.1 -P3306 -u root --no-create-db --no-create-info --result-file=./data.txt --databases clusterdb > memory_data.txt
Create a new configuration file for the MySQL Cluster deployment:
[ndbd default] noofreplicas=1 datadir=/home/billy/mysql/my_db/data DataMemory=1000M IndexMemory=10M
[ndb_mgmd] hostname=localhost datadir=/home/billy/mysql/my_db/data
Start up the management node and data node for the Cluster:
[my_db]$ <mysql-cluster-bin>/ndb_mgmd -f conf/config.ini --configdir=./conf/ --initial [my_db]$ <mysql-cluster-bin>/ndbd -c 127.0.0.1:1186
Wait until the nodes are started:
[my_db]$ <mysql-cluster-bin>/ndb_mgm -e show
Connected to Management Server at: localhost:1186 Cluster Configuration ---------------------
[ndbd(NDB)] 1 node(s) id=1 @127.0.0.1 (mysql-5.1.44 ndb-7.1.3, Nodegroup: 0, Master)
[ndb_mgmd(MGM)] 1 node(s) id=2 @127.0.0.1 (mysql-5.1.44 ndb-7.1.3)
[mysqld(API)] 1 node(s) id=3 (not connected, accepting connect from any host)
Edit the configuration file (from the original MySQL Server) by adding the highlighted rows:
[mysqld] ndbcluster datadir=/home/billy/mysql/my_db/data basedir=/usr/local/mysqlc # The MySQL Cluster installation, not the original
Stop the original MySQL Server:
[my_db]$ <mysql-bin>/mysqladmin -u root -h 127.0.0.1 -P 3306 shutdown
Start the new MySQL Server:
[my_db]$ <mysql-cluster-bin>/mysqld --defaults-file=conf/my.cnf &
Make sure that the original database is upgraded so that the MySQL Cluster version of mysqld can properly use it and you get all of the benefits (for example, real-time reporting with ndbinfo):
Convert the MEMORY tables into MySQL Cluster ones (engine=ndb) with checkpointing to disk (logging) turned off:
[my_db]$ <mysql-cluster-bin>/ mysql -u root -h 127.0.0.1 -P 3306
mysql> SET ndb_table_no_logging=1; mysql> ALTER TABLE tab1 engine=ndb; mysql> ALTER TABLE tab2 engine=ndb; mysql> ALTER TABLE tab3 engine=ndb; mysql> SET ndb_table_no_logging=0;
If the contents of the MEMORY tables were backed up then that data can optionally be loaded at this point (original MyISAM and InnoDB table data will already be populated):
mysql> SOURCE memory_data.txt;
Finally, if there is any intent to use MySQL replication with the new version of the database then check that each of the tables has a primary key defined. If there is a table without a primary key then either make one or more of the existing columns be the primary key or add a new, auto-incrementing one:
mysql> ALTER TABLE tab1 ADD COLUMN id BIGINT AUTO_INCREMENT PRIMARY KEY;
This procedure involves loss of service while the data is migrated (it assumes that there is not enough memory available on the server for both databases to exist in parallel). If there is extra capacity available (at least during the migration) then it is possible to avoid the downtime by using replication.
In many cases, the migration would not be from a single MySQL Server to a single-server MySQL Cluster deployment, but instead from a pool of independent MySQL Servers (where the application shards data across them) to a multi-server MySQL deployment. This allows the application to stop sharding the data as all mysqld instances in the Cluster have visibility of all of the data. In this scenario, if the data from the original MySQL Servers needs to be maintained then a mysqldump would be performed on each of those Servers (for all tables) and the data loaded into any of the MySQL Servers in the MySQL Cluster deployment.
Posted on July 13th, 2010 3 comments
There is often confusion as to how it can be claimed that MySQL Cluster delivers in-memory performance while also providing durability (the “D” in ACID). This post explains how that can be achieved as well as how to mix and match scalability, High Availability and Durability.
As an aside, the user can specify specific MySQL Cluster tables or columns to be stored on disk rather than in memory – this is a solution for extra capacity but you don’t need to take this performance hit just to have the data persisted to disk. This post focuses on the in-memory approach.
There is a great deal of flexibility in how you deploy MySQL Cluster with in-memory data – allowing the user to decide which features they want to make use of.
The simplest (and least common) topology is represented by the server sitting outside of the circles in the diagram. The data is held purely in memory in a single data node and so if power is lost then so is the data. This is an option if you’re looking for an alternative to the MEMORY storage engine (and should deliver better write performance as well as more functionality). To implement this, your configuration file would look something like this:
config.ini (no Durability, Scalability or HA)
[ndbd default] NoOfReplicas=1 datadir=E:\am233268\Documents\MySQL_Cluster\My_Cluster\data [ndbd] hostname=localhost [ndb_mgmd] hostname=localhost [mysqld] hostname=localhost
By setting NoOfReplicas to 1, you are indicating that data should not be duplicated on a second data node. By only having one [ndbd] section you are specifying that there should be only 1 data node.
To indicate that the data should not be persisted to disk, make the following change:
mysql> SET ndb_table_no_logging=1;
Once ndb_table_no_logging has been set to 1, any Cluster tables that are subsequently created will be purely in-memory (and hence the contents will be volatile).
Durability can be added as an option. In this case, the changes to the in-memory data is persisted to disk asynchronously (thus minimizing any increase in transaction latency). Persistent is implemented using 2 mechanisms in combination:
- Periodically a snapshot of the in-memory data in the data node is written to disk – this is referred to as a Local Checkpoint (LCP)
- Each change is written to a Redo log buffer and then periodically these buffers are flushed to a disk-based Redo log file – this is coordinated across all data nodes in the Cluster and is referred to as a Global Checkpoint (GCP)
This checkpointing to disk is enabled by default but if you’ve previously turned it off then you can turn it back on with:
mysql> SET ndb_table_no_logging=0;
Following this change, any new Cluster tables will be asynchronously persisted to disk. If you have existing, volatile MySQL Cluster tables then you can now make them persistent:
mysql> ALTER TABLE tab1 ENGINE=ndb;
High Availability can be implemented by including extra data node(s) in the Cluster and increasing the value of NoOfReplicas (2 is the normal value so that all data is held in 2 data nodes). The set (pair) of data nodes storing the same set of data is referred to as a node group. Data is synchronously replicated between the data nodes in the node group and so changes cannot be lost unless both data nodes fail at the same time. If the 2 data nodes making up a node group are run on different servers then the data can remain available for use even if one of the servers fails. The configuration file for single, 2 data node node group Cluster would look something like:
config.ini (HA but no scalability)
[ndbd default] NoOfReplicas=2 datadir=E:\am233268\Documents\MySQL_Cluster\My_Cluster\data
[mysqld] hostname=192.168.0.2If you exceed the capacity or performance of a single node group then you can add extra data node(s) to add 1 or more extra node groups. An example configuration where we want scalability but not High Availability would have multiple node groups but each made up of a single data node. The configuration file would look something like this:config.ini (scalability but not HA)
[ndbd default] NoOfReplicas=1 datadir=E:\am233268\Documents\MySQL_Cluster\My_Cluster\data
[mysqld] hostname=192.168.0.2New node groups can be added to a Cluster without taking the database off-line (see MySQL Cluster 7.1 New Features White Paper).As shown in the diagram at the start of this post it is also possible to implement any combination of Durability, Scalability and High Availability. A typical configuration that has scalability (in this case 2 node-groups), HA (2 data nodes in each node group) and durability (there by default) could be implemented with this configuration file:config.ini (Scalability, HA & Durability)
[ndbd default] NoOfReplicas=2 datadir=E:\am233268\Documents\MySQL_Cluster\My_Cluster\data
[mysqld] hostname=192.168.0.6While that solution now provides you with scalability, durability and HA you are still vulnerable to the loss of the entire Cluster (for example, a catastrophic power failure for the whole data center) – to avoid this, asynchronous replication (Geo Replication) can be setup between 2 (or more) Clusters running at 2 different locations. There is no limit to the distance between the 2 sites. As with the nodal topology, Geo Replication can be used between Clusters deploying any combination of the features described here and there is no requirement for both sites to be using the same Cluster configuration (or even for the second site to store data in MySQL Cluster at all!). More details on Geo Replication scenarios can be found at http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/
Posted on July 9th, 2010 No comments
The MEMORY storage engine has been widely adopted by MySQL users to provide near-instant responsiveness with use cases such as caching and web session management. As these services evolve to support more users, so the scalability and availability demands can start to exceed the capabilities of the MEMORY storage engine.
The MySQL Cluster database, which itself can be implemented as a MySQL storage engine, is a viable alternative to address these evolving web service demands. MySQL Cluster can be configured and run in the same way as the MEMORY storage engine (ie on a single host with no replication and no persistence). As web services evolve, any of these attributes can then be added in any combination to deliver higher levels of scalability, availability and database functionality, especially for those workloads which predominately access data by the primary key.
As always, the webinar is free of charge but you will need to register here.
- Wed, Jul 14: 06:00 Hawaii time
- Wed, Jul 14: 09:00 Pacific time (America)
- Wed, Jul 14: 10:00 Mountain time (America)
- Wed, Jul 14: 11:00 Central time (America)
- Wed, Jul 14: 12:00 Eastern time (America)
- Wed, Jul 14: 16:00 UTC
- Wed, Jul 14: 17:00 Western European time
- Wed, Jul 14: 18:00 Central European time
- Wed, Jul 14: 19:00 Eastern European time
If you can’t make the live webinar then register anyway and you’ll get sent a link to the recording after the event.
Posted on July 1st, 2010 No comments
The new version of MySQL Workbench (5.2.25) has just gone GA – see the Workbench BLOG for details.
So what’s the relevance to MySQL Cluster? If you have a Cluster that uses MySQL Servers to provide SQL access then you can now use MySQL Workbench to manage those nodes:
- Start & stop the mysqld processes
- Configure the per-mysqld configuration data held in my.cnf or my.ini
The reason that I describe the support as ‘partial’ is that these MySQL Servers are treated as independent entities (no concept of them being part of a Cluster) and there is currently no way to use it to configure or manage the other Cluster processes (data and management nodes). Having said that, what is there provides a lot of value and Workbench is designed to be very extensible and so hopefully there can be further MySQL Cluster support in the future.
In addition to MySQL Cluster-specific configuration parameters, you can also access the Cluster-specific status variables (these are the ones starting with ndb).
While I’ve focussed on what’s unique to MySQL Cluster, you can of course use the other Workbench features with MySQL Cluster – for example:
- Creating (or reverse-engineering) your data model
- Define your schema
- View/write data to your tables
- Create your SQL queries