I recently encountered an error when two slave databases were using the same server_id value. I know having unique server_ids across all MySQL databases in a given replication topology is a best practice, but I'm not sure I understand exactly why MySQL is trying to enforce uniqueness in this specific case.

The most obvious reason to use unique server_id values for every database in a replication setup is to avoid having a master and slave with the same server_id. If that happens the slave will skip any events coming from that master.

But if I have two slaves with the same server_id, that should be safe unless I promote one of those slave to be the master of the other. Is that the case that MySQL is trying to protect me from, or is there some other case I am missing?

My specific problem started when I cloned a slave database. This is something I do fairly often, but most of the time I am creating a new read slave, and I …

I recently encountered an error when two slave databases were using the same server_id value. I know having unique server_ids across all MySQL databases in a given replication topology is a best practice, but I'm not sure I understand exactly why MySQL is trying to enforce uniqueness in this specific case.

The most obvious reason to use unique server_id values for every database in a replication setup is to avoid having a master and slave with the same server_id. If that happens the slave will skip any events coming from that master.

But if I have two slaves with the same server_id, that should be safe unless I promote one of those slave to be the master of the other. Is that the case that MySQL is trying to protect me from, or is there some other case I am missing?

My specific problem started when I cloned a slave database. This is something I do fairly often, but most of the time I am creating a new read slave, and I …

Due to customer requests, we have added two of our advanced MySQL training courses in late April in Zurich, Switzerland. One course will be presented in German, the other in English.

The venue is the HSO in Zurich-Oerlikon.

The following dates has been set:

Caution: the 2nd training contains May 1st (bank holiday). The training takes place regardless.

Remember to book now to reserve your place.

What happens when you use the PASSWORD() function to insert a password hash into a table?

• The hash will be written to the table
• The password might be written in clear text to the binlog
• The password might be written in clear text to the general log
• The password might be written in clear text to the slow query log

The query

mysql [localhost] {msandbox} (test) > INSERT INTO testpwd(pwd) VALUES(PASSWORD('secret_password'));
Query OK, 1 row affected (0.00 sec)

The General log

130128 16:04:41     1 Query     INSERT INTO testpwd(pwd) VALUES(PASSWORD('secret_password'))

The Slow query log

# Time: 130128 16:04:41
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.004887  Lock_time: 0.001043 Rows_sent: 0  Rows_examined: 0
SET …

I recently encountered an error when two slave databases were using the same server_id value. I know having unique server_ids across all MySQL databases in a given replication topology is a best practice, but I'm not sure I understand exactly why MySQL is trying to enforce uniqueness in this specific case.

The most obvious reason to use unique server_id values for every database in a replication setup is to avoid having a master and slave with the same server_id. If that happens the slave will skip any events coming from that master.

But if I have two slaves with the same server_id, that should be safe unless I promote one of those slave to be the master of the other. Is that the case that MySQL is trying to protect me from, or is there some other case I am missing?

My specific problem started when I cloned a slave database. This is something I do fairly often, but most of the time I am creating a new read slave, and I …

Take the authentic MySQL Cluster training to meet database challenges of next generation web, cloud and communication services with uncompromising scalability, uptime and agility.

This 3 day instructor-led class provides you a full understanding of cluster concepts as they relate to MySQL Cluster  as well as how to properly configure and manage the cluster nodes to ensure high availability, how to install the different nodes and provide a better understanding of the internals of the cluster.

Here are some of the events already on the schedule for this course:

Last week I wrote about our participation in the SkySQL and MariaDB roadshow. First event in Stuttgart completed on Friday, and the tour continues into Hamburg this Friday and Stockholm on February 7th.

But we will also be busy speaking at some other conferences this Spring.

Fosdem, Brussels. February 2-3.

Next weekend we will be in the MySQL and Friends dev-room at Fosdem. Henrik will be giving the Introduction to Galera talk.

Fosdem is …

The next Helsinki MySQL User Group is set for Tuesday, February 19. Lari Pulkkinen from Arbitron Mobile will talk about their project adopting SSD disks for better MySQL performance. Yes, there are benchmarks included.

Note the changed location: Oracle office in Gräsantörmä 2, Espoo. We are glad to have Oracle Finland sponsoring the user group by taking turns as meetup host. Food and sauna will be available after the talk as is customary.

More details and signup at Meetup.com.

This article was initially planned to follow the previous posts about RW (Read+Write) workloads on MySQL & Linux (part#1, part#2)... But, when I've started to run real MySQL/InnoDB IO-bound tests on the Fusion-io card, I've quickly realized that I'm hitting so hot internal contentions within InnoDB code, that I'm simply unable to use storage capacity on its full power.. So, I've moved to another server (having SSD only), and then continued with it (as to explain RW limits it'll be pretty enough). Also, curiously, on this server XFS performance on writes is way better than EXT4 (while on the the previous server XFS got some unexpected problems, seems to be known bugs)..

So far, for the …

I wrote pt-archiver for jobs like deleting or archiving rows from a big table in small chunks. These days, that’s the kind of task I like doing inside the database, and Shlomi’s magical common_schema feels a lot more suited for this than an external Perl script. When I say it’s magical, it really does feel magical. It’s amazing how he’s created an entire expressive scripting language that runs in MySQL and feels just right for the job.