Feed Aggregator

The following summary shows my personal understanding of MySQL 5.1 licenses, packages and products. It does not necessarily reflect 100% the way MySQL understands it. But after all the discussions I hope it is as close as possible to the reality:

MySQL Embedded Database Server

(Download → OEM Software)

Classic  (OEM license, -MEM -InnoDB)
Pro      (= Classic +InnoDB)
Advanced (= Pro +Partitioning)

MySQL Community Sever

(Download → Download)

Community (GPL, -NDB)

MySQL Enterprise Server

(Download → Enterprise Software)

Pro      (GPL or commercial, -NDB +InnoDB +MEM, Basic + Silver customer, MRU + QSP)
Advanced (= Pro +Partitioning, Gold + Platinum customer)

MySQL Cluster

(Download)

Community Edition (GPL, all features)
Com (ex CGE?)     (OEM or commercial, -InnoDB +NDB)
Com-Pro           (Com, all features)
Standard Edition  (= Com, -NDB-API -Cluster-Repl, -LDAP)

Upgrade

EP customer should follow the QSP trail unless it is critical for them to install an MRU to get a quick bugfix to hold them over until …

[http://www.blogger.com/profile/02551781456999098405 Jonas Oreland] said…

FYI: I also added a new config parameter in 6.3.19, that makes the redo-files to be fully initialized:

InitFragmentLogFiles=full

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hey guys,

Have a look at the addendum. I have updated it.

Regards, Oli

Anonymous said…

Thanks for sharing this. This is a very good read!

Hope the patch made it in the production code

Anonymous said…

Will this performance improvement patch made it into normal releases or will it be available for Enterprise customers only?

This week we had a very interesting problem at a customer: They complained, that their MySQL Cluster takes about 1 hour for a --initial start-up. After some tuning on the hardware and the config.ini they brought it down to around 40 minutes. But this is still unacceptable long…

This sounds a little strange to me. But let us have a look at their config.ini first. It looked more or less like the following (which is already tuned!):

#
# config.ini
#

[NDB_MGMD DEFAULT]
DataDir                      = /localdisk/cluster

[NDBD DEFAULT]
DataDir                      = /localdisk/cluster
NoOfReplicas                 =     2
LockPagesInMainMemory        =     1
DataMemory                   = 12000M
IndexMemory                  =  2000M

FragmentLogFileSize          =   256M
NoOfFragmentLogFiles         =    42

DiskCheckpointSpeedInRestart =   100M
ODirect                      =     1

BackupMaxWriteSize           =     1M
BackupDataBufferSize         =    16M
BackupLogBufferSize          =     4M
BackupMemory …

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Baron

Hmmm. Did not know about it. But to be honest: I did not yet have time to look at all the nice stuff from your Maatkit and all the cool Google Patches and OurDelta etc… :-(

But thanks for the hint!

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Willy

Yes. MySQL circular replication usually works fine (technically). I hope you have a good concept cleaning it up again when it some how messes up!

We usually recommend customers to be very very careful with this kind of replication!

Regards Oli

[http://www.blogger.com/profile/02327079024123812197 willy] said…

I have 4 servers, I need 4 servers share changes made on each one, my solution was configure them in ring schema, this is: server1 is master of server2 and slave of server4, server2 is master of server3 and slave of server1, and so on. This works fine. All server updates on same schema. Hope to be useful.

Introduction

One of the features that make MySQL so great is its easy replication set-up. If you are experienced and know-how to do it, it takes you about 15 minutes to set-up a slave. What you have in the end is a replication from one master to one or several slaves. So you can build a top-down data stream pyramid and spread your data on many slaves.

From time to time some customers are asking for the other way: Many masters replicating to one slave (which is also called multi-source replication). For this requirement MySQL replication cannot help you directly.

Possibilities

You can circumvent this situation in the following ways:

• Implement your own data transfer mechanism.
• Use this ugly hack I have written down 2 years ago: Multi-Master-Single-Slave-Replication
• Test the approach described in the following article.
• Wait until MySQL has implemented it…

Possibility number 4 for would be the nicest one. Because then the solution would be properly supported by your database vendor and you do not have …

[http://www.blogger.com/profile/01621441847303652718 Baron] said…

You can also use [http://code.google.com/p/mysql-mmre/ MySQL mmre]

When I set-up a MySQL HA environment for customers I usually do some final failover tests after configuring the whole beast.

To check if the application behaves like expected I always run my little test application (test.sh) from the server(s) where the customers application runs. It displays “graphically” how the application behaves and you can show to the customer immediately what is going on…

Make sure, that you point it to the virtual IP (VIP) or the load balancer (LB).

It was really useful for me and I recommend you to do your HA failover tests also at least with this little tool to avoid evil surprises in the future.

Das dreieckige Rad hat gegenüber dem viereckigen einen gewaltigen Vorteil: Ein Rumms weniger pro Umdrehung!

Translation:

The triangular wheel has one enormous advantage over the quadrangular: One knock less per revolution!

Maybe not new, but I have not heard it yet and I love it. It was about reinventing functionality in a well known product…

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi knetknight

Thanks for your comment.

When your are facing time/scheduling issues I recommend you to go through the MySQL online documentation (Chapter: Table Maintenance Statements and Restrictions on InnoDB Tables) because some of these commands have no effect on some table types (InnoDB) and some of them do the work already done in a previous command.

Regards Oli

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said… Hi Matthew

Thanks for your comment. This could have helped a lot. I do NOT ask why there was no message like:

Query OK, 1 row affected, 1 warning (0.10 sec)

or why the real cause was not displayed at all…

[http://www.blogger.com/profile/04421029174237420523 Matthew Montgomery] said…

In this example I lowered the MaxNoOfOrderedIndexes to 25 and created a bunch of tables, then I got.

mysql> create table foo23 like foo1; ERROR 1005 (HY000): Can’t create table ‘./test/foo23’ (errno: 904) mysql> show warnings; +——-+——+———————————————————————————–+ | Level | Code | Message | +——-+——+———————————————————————————–+ | Error | 1296 | Got error 904 ‘Out of fragment records (increase MaxNoOfOrderedIndexes)’ from NDB | | Error | …

[http://www.blogger.com/profile/04421029174237420523 Matthew Montgomery] said…

After any error in mysqld dealing with NDB tables you should always run “SHOW WARNINGS”. MySQL will only show the last error, which is the mysqld error, “no more room in index file” at execution time. This means that the NDB error which bubbled up to mysqld won’t be displayed unless you use the “SHOW WARNINGS” command.

Recently we were migrating an InnoDB/MyISAM schema to NDB. I was too lazy to calculate all the needed MySQL Cluster parameters (for example with ndb_size.pl) and just took my default config.ini template.

Because I am really lazy I have a little script doing this for me (alter_engine.pl).

But suddenly my euphoria was stopped abruptly by the following error:

MySQL error code 136: No more room in index file

The usual command that helps me in such a situation is a follows:

# perror 136
MySQL error code 136: No more room in index file

But in this case it is not really helpful. Also

# perror --ndb 136

does not bring us further. Strange: Index file… We are converting from MyISAM/InnoDB to NDB. Why the hell is he using an index file for this operation? It seems to be clearly a mysqld error message and not a MySQL Cluster error message. And we are also not using MySQL Cluster disk data tables.

After bothering a bit MySQL support I had the idea to do the following:

# ndb_show_tables | grep -ic orderedindex …

A customer has recently experienced a possible memory leak in its NDB-API application. What he did was something like:

# ps aux | grep <pid>

over time and then he saw the RSS increasing. When he would have had a look a little longer he would have seen that the RSS consumption would increase up to a certain level and then becomes stable. Which is the expected behavior.

But how to explain to the customer that his application, which was in fact not doing anything, consumes more RSS?

With a diff over time on /proc/<pid>/smaps we found that this area was the reason:

b67b7000-b6fca000 rw-p b67b7000 00:00 0 (8 Mbyte)
Size:               8268 kB
Rss:                 148 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       148 kB
Referenced:          148 kB

But what is this meaning? To find the answer we did a strace on the program and got the following system calls:

...
read(5, "127.0.0.1 localhost<br>n<br>n# The follo"..., …

[http://www.blogger.com/profile/13990877688502800403 Sheeri K. Cabral] said…

You could probably very easily put this all into a lua script, slap MySQL Proxy in front of it, and have automated failover – if it can’t reach the 1st backend, pick among the other backends by doing a query, promote it, etc.