mysqlguy.net

This is more of a question than me sharing knowledge, but I'm testing the effects of MySQL SSL on replication delay. Interestingly, my tests show faster replication when I enable SSL, versus disable. The slave_compressed_protocol has an effect too, and I get the best result when I use SSL and slave compression in a non-CPU bound test.

The question came up, however, of what SSL Cipher I'm using. I'm not specifying one in my CHANGE MASTER statement, so I'm guessing I'm getting the same default cipher as if I connect with the regular mysql command line client with SSL, which is:

I recently started exploring the wonders of mk-table-checksum after spending too long dismissing the magic-like maatkit toolkit. What follows is not an exhaustive treatment of mk-table-checksum, but just an overview and some things I had to learn by trying the tool out.

The basic principle is based on the CHECKSUM TABLE table maintenance statement supported in the MySQL Server. The mk-table-checksum runs a CHECKSUM TABLE command on all (or some) tables. The results of that are stored in another table on the server.

I'm not sure I care what the version number is (5.3,5.4,5.4,6.0), and you can talk about milestone releases all you want. What really matters to me is when we'll have something beyond 5.1 marked as GA. Will it be 5.5? When should I expect that?

5.4 was announced last year at the conference with lots of performance fixes for the mysql server itself. Great. Until those changes percolate up into a stable release, they aren't worth too much to me. With all the hoopla about the release cycle, I haven't seen any results in the form of new features/fixes making it to stable any faster than 5.1 did.

What's the point of any release cycle beyond getting good solid code to stable in a timely (i.e., not 3 years) and safe (i.e., well tested) manner? Can't we have both timely and safe?

Doing some performance testing on some modern hardware comparing Innodb plugin 1.0.4 with stock Innodb. I'm running a sysbench transactions test (reads and writes) with 200M rows in my table (table size is around 46G, RAM is 16G, buffer pool is set to 12G).

I was puzzled to see the innodb plugin to be decent, but not really as great as I expected, I was doing about ~6100 RW operations a second (individual statements within transactions). Then I compared it to the stock innodb and shockingly I got ~7K ops. I thought about what I tuned that was different in the plugin and came up with the innodb_io_capacity.