MySQL Cluster Replication

MySQL QA

In the 5.1 release MySQL Cluster will support replication to another MySQL installation. The replication is handled using Row Bases Replication instead of Statement Based Replication.

I have been testing it for about a year now and it has gotten really hard for me to break at this point, but I am still trying.

So what is so cool about Cluster Replication? Good question!

One answer:

Cluster Replication really gives a company five 9's (99.999%) in up time. You can have a Master Cluster in the main site supporting the business and have another Slave Cluster in a total different site that can be used as a backup for times there are issues with main site. In addition, the Slave Cluster can also be used for reporting or data mining to take that traffic off of the main Cluster.

How hard is it to setup? Another great question.

Answer: Easy

So to set it up, you would create two set of Clusters configured the way that you wanted them. You configure the Master MySQLD to create a bin log and to connect to the Master Cluster. You configure the Slave MySQLD to read from that Master MySQLD and to connect to the Slave Cluster. That is basically it. Of course you have to grant replication permissions, but I am sure you knew that. Here is are some examples:
******************************************************

Master MySQLD my.cnf:

[mysqld]
server-id=1
log-bin = /space/var/master1
log = /space/var/master1.log
log-error = /space/var/master1.err
socket = /tmp/mysql.sock
port = 3306
pid-file = /space/var/hostname.pid
datadir = /space/var/
language = /usr/mysql/english/
ndbcluster # Use NDB engine
ndb-connectstring=master01:1234 # location of MGM node ndb-connectstring=host:port

Slave Cluster MySQLD my.cnf:
[mysqld]
server-id=8
relay-log=slave-relay-bin
replicate-ignore-db=mysql
master-user=rep
master-connect-retry=1
master-host=master01
master-password=test
master-port=3306
skip-slave-start
datadir=/space/var/
log-warnings
log-error=/space/var/slave.err
ndbcluster
ndb-connectstring=slave01:1234 # location of MGM node
******************************************************

Hey, in your example the slave has an ID of 8, why? You noticed.

Answer:
To really get the most out of the Cluster you need a lot feeding it. You can have more then one MySQLD process feeding the Master Cluster and producing bin logs for that matter.

Well if you have more then one MySQLD feeding the Master Cluster then how does replication work?

Answer: The injector thread.

The Master Cluster is responsible for updating the Bin Log, not the MySQLD process. This is done through the Cluster Bin Log Injector Thread.

Therefore you can have many MySQLD processes feeding the Master Cluster, but have the Slave only reading from one of them and not miss a beat (or data action).

One other questions is why do you have skip-slave-start in you Slave my.cnf? You saw that too, hmmm.

Answer:
Sometimes your Master Cluster will have been up a long time and you are wanting to bring a slave on-line, but you really don't want the slave in catch-up mode for days. So you can start the the MySQLD on the slave telling it to not start replication yet, restore a backup from the Master, run a couple of command, then start the slave and you will catch-up quickly and be in sync.

To read more about this, checkout:

http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication.html

If you have ideas for testing, or have different scenarios you would like to see tested, please send them to me. Always looking to improve.

Cheers!

MySQL CLuster Disk Data QA

MySQL QA

Now that we have Disk Data for MySQL Cluster you can have the best of both worlds. You can use memory tables for those needing quick access and updates and Disk Data Files for those that will be too large to keep in memory all the time.

One issue with this first release is not having the ability to spread the data and undo files accross the disk sub system using the config.ini file. This can be a important issue for performance. You really don't want to have everything on one disk. Here I list a work around for moving undo and/or data files off to different drives to help in disk performance that I used during performance testing.

1) Bring up the cluster to include all data nodes
2) Each data node will create its own File System ((e.g. ndb_#_fs) where # == the DN ID)).
3) Under the data node FS create the symbolic links pointing to the other drives:

Examples Single Data Node:
[ndb_2_fs]$ ls
D1 D10 D11 D2 D8 D9 LCP
[ndb_2_fs]$ ln -s /data0/log1/ dn_logs
[ndb_2_fs]$ ln -s /data1/data/ dn_data

We now have 2 symbolic links

12 Jan 31 20:31 dn_data -> /data1/data/
12 Jan 31 20:31 dn_logs -> /data0/log1/

Note: This needs to be done for each and every data node before going to next step:

4) Now do the create statements
CREATE LOGFILE GROUP lg1
ADD UNDOFILE './dn_logs/undofile.dat'
INITIAL_SIZE 150M
UNDO_BUFFER_SIZE = 1M
ENGINE=NDB;

CREATE TABLESPACE ts1
ADD DATAFILE './dn_data/datafile.dat'
USE LOGFILE GROUP TPCB_LOG
INITIAL_SIZE 5M
ENGINE=NDB;

5) Doing the same for multi data nodes running on one host.

Give each data node its own path
[ndbd]
Id: 2
HostName: host13
FileSystemPath: /data0

[ndbd]
Id: 3
HostName: host13
FileSystemPath: /data1

DN ID 2 will create it file system on /data0 and DN ID 3 will create its file system on /data1

we then repeat the steps in steps 2 & 3 placing the files in the desired location using symbolic links, and the step 4 for the actual create.

You can then make sure the above worked correctly:

[dn_data]$ cd /data1/data/
[data]$ ls -l
total 2099304
-rw-rw-r-- 1 user group 2147581952 Jan 28 19:58 datafile.dat


Best wishes,
/JBM

MySQL 5.1

MySQL QA

Testing 5.1 MySQL CLuster is moving along. We now have more automated test cases, have been using TPC-B and DBT2 in testing, conducted load and HA testing.

The great news is that many issues are now found early before the customer base has to deal with them.

This relase will be packed full of great stuff for Cluster including the first release of Disk Data and Replication for MySQL Cluster.

The MySQL User Conf is just a few weeks away where much of this will be shown. Hope to see you there.