As I’m sure you’re aware, DRBD disallows access (any access, including read-only) to a DRBD device in Secondary mode. This always raises questions like the one I’ve taken the liberty to quote here. It came up in a MySQL webinar on replication and HA:

Because of the asynchronous nature of [MySQL] replication we end up with a dilemma when looking at using slaves as read nodes in that the only time we go to the database for information is to build a local cache file, and that local cache file is ONLY removed when information related to that cache file changes, it is NOT based on time. If we had a synchronous method of replication we would then know the cache files were always getting the right information, but because of the asynchronous nature …

I’ve noticed that in the last five years I’ve started to become very conservative about adopting new technologies.

We’re JUST now migrating to Opterons for example. I’m only now considering adopting Java 5.0.

My stack is essentially Java 1.4.2, MySQL 4.1.22, Debian 3.1 (migrating to Etch), and Athlon processors.

There just aren’t any surprises. The entire stack works and everything is a known entity. Since I have a pretty stable foundation I can look at technologies one at a time without fundamentally changing the stability of the entire system. Java 5.0 looks interesting but no real pressure here at the moment.

MySQL 5.1’s partitioning support will probably be the only feature that pushes us to upgrade. There are some InnoDB fixes I want to incorporate as well.

MySQL AB today announced that Zappos.com subscribes to its MySQL Enterprise commercial database offering to help manage the e-commerce site?s growth and market-leading customer service. Zappos.com also recently achieved the #1 rating as the most-available Internet retailer, as reported by Gomez Inc.

My last post on the replication poll was apparently lost from Planet MySQL. If you're interested, I commented on the replication poll, our future plans, and how they were affected by the poll.

This probably warrants a bug report to MySQL, but I want to let other people know about this first. There are situations where MySQL receives incomplete statements from replication relay logs, but does not trigger a replication error. Case in point is exceeding max_allowed_packet.

I recently had a situation where once of my machines was incorrectly configured with a different value for max_allowed_packet. What happened is not what I had expected. Instead of receiving a replication error (which we monitor for using Nagios), the MySQL error log was spewing with messages about exceeding max_allowed_packet. Instead, the only visible problem through our monitoring framework was that replication had fallen behind, and was continuing to fall behind.

Fixing the problem was rather easy: stop the slave, change the max_allowed_packet variable globally in the db server and in the configuration file, and then start the slave.
…

I have recently posted a script on MySQL Forge to back up MySQL binary logs. One of the ideas that I had when I originally wrote the script was to take into account all of the slaves and what master log file & position that each one has executed. This way, only the relevant binary logs would get archived and then subsequently purged. You can find the script here.

As DBAs that manage large quantities of database servers, we are always looking for the fastest or most efficient way to load data into the database. Some DBAs have quarterly maintenance periods where they reload data into a database to refresh the indexes.

If you primarily use InnoDB tables in your MySQL database server, then these set of tricks will help in trying to make the reload process a bit faster than just a straight dump & reload.

my.cnf configuration
innodb_flush_log_at_trx_commmit = 0
innodb_support_xa = 0
skip-innodb-doublewrite
disable log-bin & log_slow_queries

Since the goal is to reload data quickly, we need to eliminate any potential bottlenecks. Setting innodb_flush_log_at_trx_commit = 0 this will reduce the amount of disk I/O by avoiding a flush to disk on each commit. If you are not using XA compliant transactions (multi system two-phase commits) then you …

MySQL AB today announced that The Phone House Telecom, a German provider of communication and entertainment services, has done an extensive consolidation of the infrastructure of its online shop -- replacing systems from Oracle and Informix with the MySQL Enterprise database.

Just found this little handy feature today:

PLAIN TEXT SQL:

1. mysql> INSERT INTO c SELECT rand()*1000, sha1(rand()) FROM c;
2. Query aborted BY Ctrl+C
3. ERROR 1317 (70100): Query execution was interrupted

So now if you press CTRL-C MySQL Command Line Client will not exit but will terminate query being executed. This is great as so many queries assumed CTRL-C would also abort running query in previous MySQL versions and I've seen many monstrous queries left running without noticing just because people would think CTRL-C terminated the query. Now it finally really does.

Great Job! I wish I would see more of such relatively simple but very handy improvements

I filed the following bug today. Basically it looks like in certain conditions Innodb may be started twice in the parallel on the same data files which can hurt database badly. It is true it does not seems to be 100% repeatable but I've seen it multiple times in different environments. I'm not sure if this is some platform which has issues with locking, Some race condition which allows to copies to start or anything else.

In any case you'we been warned - be careful and ensure MySQL is not already started when you're thinking to start one. Now when
MySQL starts to listen to the socket after Innodb Recovery is completed it is very easy to make a mistake and think MySQL is not running at all when recovery is in progress.