Showing posts with label MySQL Cluster. Show all posts
Showing posts with label MySQL Cluster. Show all posts

Tuesday, September 11, 2012

MySQL Cluster to InnoDB Replication Howto


In this blog post I will show you how to setup a replication from MySQL Cluster  (ndbcluster) to a regular MySQL Server (InnoDB). If you want to understand the concepts, check out part 7 of our free MySQL Cluster training.

First of all we start with a MySQL Cluster looking like this, and what we want to do is to setup replication server to the Reporting Server (InnoDB slave).




MySQL Cluster is great at scaling large numbers of write transactions or shorter key-based read querise, but not so good at longer reporting or analytical queries. I generally recommend people to limit analytical/reporting queries on the MySQL Cluster, in order to avoid slowing down the realtime access to the cluster. A great way of doing that is to replicate the MySQL Cluster data to a standalone MySQL Server.  

To achieve that, we will need a replication server. All data written into NDBCLUSTER is sent as events to the replication server. A MySQL Server can be turned into a replication server by specifying --log-bin. The replication server then produces a binary log, which can be replicated to a standalone InnoDB. 

(NOTE: For redundancy, it is possible to have 2 replication servers. We will cover that in a separate blog.)


Replication Layer Configuration
In the my.cnf of the replication server you should have the following:
[mysqld]
...
#REPLICATION SPECIFIC - GENERAL
#server-id must be unique across all mysql servers participating in replication.
server-id=101
#REPLICATION SPECIFIC - MASTER
log-bin=binlog
binlog-do-db=user_db_1
binlog-do-db=user_db_2
binlog-do-db=mysql
expire-logs-days=5
...
You may want to skip  the binlog-do-db=.., if you want to replicate all databases, but, if you want to replicate a particular database, make sure you also replicate the mysql database in order to get some very important data on the slave.

Restart the replication server for the settings to have effect.
Grant access to the Slave:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ip/hostname of mysqld m' 
  IDENTIFIED BY 'repl';

InnoDB Slave Configuration
The first requirement on the InnoDb slave is that it must use the mysqld binary that comes from the MySQL Cluster package. If you already have a MySQL 5.5 installed that is not clustered, you need to upgrade it to the Cluster version of it. E.g, by doing:

sudo rpm -Uvh MySQL-Cluster-server-gpl-7.2.7-1.el6.x86_64.rpm
sudo rpm -Uvh MySQL-Cluster-client-gpl-7.2.7-1.el6.x86_64.rpm

The InnoDB slave should have the following:

[mysqld]
...
binlog-format=mixed
log-bin=binlog
log-slave-updates=1
slave-exec-mode=IDEMPOTENT
expire-logs-days=5
...

If you want the InnoDb to further replicate to a set of slaves, then you should set log-slave-updates=1 otherwise you can set it to 0 (log-slave-updates=0). Thatt is all, restart the slave.

You must also create the following table on the Innodb Slave:

use mysql;
CREATE TABLE `ndb_apply_status` (
`server_id` int(10) unsigned NOT NULL,
`epoch` bigint(20) unsigned NOT NULL,
`log_name` varchar(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
`start_pos` bigint(20) unsigned NOT NULL,
`end_pos` bigint(20) unsigned NOT NULL,
PRIMARY KEY (`server_id`) USING HASH)
ENGINE=INNODB DEFAULT CHARSET=latin1;

Then do CHANGE MASTER:
CHANGE MASTER TO MASTER_HOST='ip/hostname of the replication server', MASTER_USER='repl', MASTER_PASSWORD='repl';

Staging the InnoDB Slave with Data
Now you need to stage the InnoDB slave with data. What you need to do is to disable traffic to NDBCLUSTER in order to get a consistent snapshot of the data. As there are no clusterwide table locks in NDBCLUSTER you have two options:
  1. Block the Loadbalancer from sending any transactions to MySQL Cluster
  2. Make all SQL nodes READ ONLY, by locking all tables on ALL MySQL servers (if you use NDBAPI applications, then option 1) or shutting down the applications is the the only option):  FLUSH TABLES WITH READ LOCK;
So on all MySQL Servers in the Access Layer do:
FLUSH TABLES WITH READ LOCK;

Ensure, by looking at the replication server,  that no writes are made to the NDBCLUSTER by looking at the SHOW MASTER STATUS:
mysql> show master status;
+---------------+-----------+--------------+------------------+
| File          | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+-----------+--------------+------------------+
| binlog.000008 | 859092065 |              |                  |
+---------------+-----------+--------------+------------------+
1 row in set (0.00 sec) 
Run the SHOW MASTER STATUS; a couple of times until you see the Position not changing any more

Then RESET the replication server, so you have a good clean slate to start from:
mysql> RESET MASTER;

Now use mysqldump two times to get  :
  1. one dump with the schema
  2. another dump with the data 
mysqldump --no-data --routines --trigggers > schema.sql
mysqldump --no-create-info --master-data=1 > data.sql

Of course you can dump out only the databases you are interested in.


When the dumps have finished, you can enable traffic to NDBCLUSTER again. You can do on ALL SQL nodes:

UNLOCK TABLES

Point is that you can enable traffic to NDBCLUSTER again.

Now, change the ENGINE=ndbcluster to ENGINE=innodb in schema.sql:

sed -i.bak 's#ndbcluster#innodb#g' schema.sql

Copy the schema.sql and data.sql to the slave, and load in the dump file to the InnoDb slave.

Finally you can start replication, on the InnoDB slave you can now do:

START SLAVE;
SHOW SLAVE STATUS \G

And hopefully all will be fine :)

Wednesday, August 29, 2012

MySQL Cluster: Troubleshooting Error 157 / 4009 Cluster Failure


Suddenly your application starts throwing "error 157" and performance degrades or is non-existing. It is easy to panic then and try all sorts of actions to get past the problem. We have seen several users doing:
  • rolling restart
  • stop cluster / start cluster
because they also see this in the error logs:
120828 13:15:11 [Warning] NDB: Could not acquire global schema lock (4009)Cluster Failure

That is not a really a nice error message. To begin with, it is a WARNING when something is obviously wrong. IMHO, it should be CRITICAL. Secondly, the message ‘Cluster Failure’ is misleading.  The cluster may not really have failed, so there is no point trying to restart it before we know more.

So what does error 157 mean and what can we do about it?

By using perror we can get a hint what it means:

$ perror 157
MySQL error code 157: Could not connect to storage engine

What this means is simply as it says, one SQL node is not connected to the NDB storage engine.  It can be that you have messed up the ndb-connectstring in the my.cnf of that SQL node.
It is often the case that someone has been doing ALTER TABLEs, and for some reason, the schema files have been corrupted or is of the wrong version on one or more SQL nodes. It would make sense to check the SQL nodes for potential problems there.

If you have multiple SQL nodes, you probably have the SQL nodes behind a load balancer. Which MySQL is really causing this problem? One of them, or all of them?
Let’s take a look from one of the SQL nodes:

mysql> show global status like 'ndb_number_of%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Ndb_number_of_data_nodes       | 2     |
| Ndb_number_of_ready_data_nodes | 2     |
+--------------------------------+-------+
2 rows in set (0.00 sec)

This is perfect, we have two Data nodes , and two of them are ready. This means that this particular SQL node is connected to the NDB storage engine. Now, let's look at another one:

mysql> show global status like 'ndb_number_of%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Ndb_number_of_data_nodes       | 0     |
| Ndb_number_of_ready_data_nodes | 0     |
+--------------------------------+-------+
2 rows in set (0.00 sec)

This does not look good, this SQL node is not connected to the Data nodes. Now iterate over the remaining 62 MySQL servers or how many you have to find the bad apples. However, I prefer myself to spot the faulty ones like this:

Screenshot from Severalnines ClusterControl

Now, we can stop the SQL nodes that are marked as "red":
1.     Stop the MySQL server:
service mysql stop
2.    Go into the database(s) you have in the datadir of the MySQL server:
cd /var/lib/mysql/mydatabase/
3.    Remove .frm files and .ndb files:
for x in `ls *.ndb`; do rm `basename $x .ndb`.frm; rm `basename $x`;  done
4.    Start the MySQL server
service mysql start
Is step 2) safe to do? 
Yes, the .frm files of the NDB tables are stored in the data dictionary inside the data nodes. By removing these files, and restarting the MySQL server, the MySQL server will fetch the missing .frm files from the data nodes, and you will end up with fresh ones.

Hope this helps someone,
Johan





Thursday, February 23, 2012

Deploy MySQL Cluster 7.2 GA in 288 seconds

It seems that our friends at Oracle have been pretty busy with the GA release of MySQL Cluster 7.2.

This is not just old wine in new bottles.

While it may be a dot release, it does appear to be a more significant step forward than a dot release would imply.

First off, we are very excited to announce that the Severalnines Cluster Configurator now includes support for 7.2 GA.

As the title of this blog suggests, it is possible, as we have experienced, to deploy 7.2 GA in 288 seconds, i.e. just a few minutes. This was done on m1.large instances on Amazon. We have published a quick how-to deployment guide for Amazon here: http://support.severalnines.com/entries/20916823-installing-on-amazon-ec2.

This being said, let’s have a look at some of the new features in 7.2 and why they matter.

MySQL Cluster has always suffered from poor JOIN performance, mainly because the nested loop algorithm did not work very well in a parallel environment. That meant the join was executed entirely in the MySQL Server. This resulted in a lot of network round-trips between the MySQL Server and the data nodes.

Now with 7.2, this has changed. With Adaptive Query Localization, a JOIN query is now shipped down to the data nodes and executed in parallel on local copies of data.


Results look very promising, with up to 70x factor improvement on some queries as described in this excellent post.

By getting better index statistics, the SQL optimizer can also build a better execution plan for each query. This in turn reduces the need for manual query tuning. Prior to 7.2, a lot of index hinting was needed. However, 70x speed improvement does not mean that a single query on MySQL Cluster will perform as fast as on InnoDB, since there will always be the network latency between SQL and Data nodes. But it does mean that many queries that were running very slowly in 7.1 might now run fast enough.

The Memcached API is a new addition to an already extensive list of API connectors, aimed at existing Memcached users and the NoSQL community. For a product trying to be attractive to the NoSQL community, perhaps the addition of distributed parallel JOIN algorithms may be a bit confusing. NoSQL programmers typically avoid JOIN operations, for reasons including scalability and schema flexibility.

Is someone trying to have their cake and eat it too? :-)

Among the other features described here, the separation of Data Nodes across data centers (and specially Figure 3) is misleading. With a 2-phase commit protocol to guarantee synchronous replication within a Node Group, NDB would have to defy the laws of physics to support the below diagram. Unless the data centers are physically close to each other with a low-latency redundant link in-between them, splitting of data nodes across data centers is not a good idea.

It is also worth noting that 7.2 GA is based on MySQL 5.5, whereas 7.1 was based on MySQL 5.1 – probably more relevant for users with mixed NDB and InnoDB tables.

So: is MySQL Cluster 7.2 for you?

If yes, then try it out using the Severalnines Cluster Configurator: http://www.severalnines.com/cluster-configurator/).

It will take just a few minutes to generate a deployment package, which automates the installation of the cluster. Or it might take 288 seconds ... let us know ;-)

Thursday, December 15, 2011

Walking on Cloud 9

As the saying goes, we at Severalnines have been walking on several clouds this year, 9 to be precise!


Today, we are proud to say that we are on walking on Cloud 9!


And in the spirit of celebration, we would like to announce our:



Top 9 Clouds of the Year 2011 for Severalnines



Cloud 1 – releasing ClusterControl™ - our first commercial product in April!


ClusterControl™ is our flagship product. It enables developers and database administrators to Deploy, Manage, Monitor and Scale their clustered database platforms, free from the complexity and learning curves associated with database clusters. Read more ...



Cloud 2 – releasing ClusterControl™ for 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. Read more ...



Cloud 3 - releasing ClusterControl™ for MySQL Galera together with Codership

ClusterControl™ for MySQL Galera enables customers to Deploy, Manage, Monitor and Scale a clustered MySQL database platform based on Galera Replication. MySQL Galera is a synchronous multi-master cluster for MySQL/InnoDB, and allows applications to read and write from any MySQL Server.

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


Cloud 4 – reaching over 7,000 installations via the Severalnines Configurator


The Severalnines Configurator allows you to generate a production class configuration for a clustered MySQL configuration. It also generates a deployment package that automates the deployment of the complete database setup. Topologies can be based on MySQL Replication, MySQL Cluster or MySQL Galera.


We have a great user base and in order to facilitate communication within our user community, we set up our Severalnines Customer Services platform with forums, online support, etc. both for paying customers as well as users. Check it out and join the conversation!



Cloud 5 – our Customers


At Severalnines, our goal is to reduce database costs, ease deployment, simplify management and increase DBA and developer productivity.


But rather than us telling you why we think we are great, we wanted to provide documented case studies on how our innovative products are helping customers meet and exceed business goals for their database operations. See what our customers have to say about us.



Cloud 6 – introducing Severalnines DataCloud™


Severalnines DataCloud™ enables DBaaS for public, private and hybrid clouds. It extends the advantages of cloud computing to the database infrastructure layer by enabling on-demand access, automated management, managed availability and elasticity of MySQL databases. This reduces cost and the complexities of deploying and managing databases. Read more ...



Cloud 7 – launching the first ever 100% European DbaaS with City Network


On November 23rd, Severalnines and our partner City Network announced the first fully European Database as a Service (DBaaS) solution - in beta form. The City Cloud Database Service is based and operated in the European Union - offering European customers full compliance with EU Directive on Data Protection 95/46/EC and a safe haven from the reaches of the US Patriot Act and making it the first ever offering of its kind. Read more ...



Cloud 8 – being talked about at the European Commission – Severalnines in the News


Following our announcement of the City Cloud Database Service, the press took over and 20+ original articles later, we discovered that we were even being talked about at European Commission conferences. Which shows to prove that politicians do read the papers (or are well briefed by colleagues who do) and that we had hit the right spot with our announcement. Find out more and see all the press coverage in our News Center.



Cloud 9 – winning the EuroCloud Sweden & Europe Awards 2011 for Best Startup!!!


We did it! After winning the EuroCloud Award for Sweden, we won the EuroCloud Europe Award for Best Startup last week in Paris at a prestigious ceremony on the Seine. We attended the ceremony together with our friends from City Network and needless to say that we had a great night! The Awards have been widely covered by the European press in multiple languages – visit our News Center for all the details.


All in all, it's been a great year for us and we have all of you to thank for that!


So here is a BIG 'thank you' from everyone at Severalnines to all our customers, partners, friends and supporters out there.


Have a great year-end and and an even better start to the year 2012 - see you there!


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.