I wanted to quickly walk through my automated test environment setup for MySQL Enterprise Monitor (MEM). In doing so, I hope to help demonstrate how MEM 3 can easily be managed within an automated environment--whether you're using puppet, chef, cfengine, ansible, salt, $TheNextCoolDevOpsTool, or your own custom shell scripts like I am.

Here's how I setup my test environment:

1. I copy a "fresh" data directory into N locations.
shell# cat createtestenv.sh  #!/bin/sh
echo -n "Setting up fresh mysqld_multi setup..."
cp -R /var/lib/mysqlfresh /var/lib/mysql cp -R /var/lib/mysqlfresh /var/lib/mysql2 cp -R /var/lib/mysqlfresh /var/lib/mysql3 chown -R mysql:mysql /var/lib/mysql*
echo " done."
echo -n "Starting fresh mysqld instances..." /etc/init.d/mysql start echo " done."
2. I install the …

While playing with MySQL 5.7.5 on POWER8, I came across a rather interesting bug (74775 – and this is not the only one… I think I have a decent amount of auditing and patching to do now) which made me want to write a bit on memory barriers and the volatile keyword.

Memory barriers are hard.

Like, super hard. It’s the kind of thing that makes you curse hardware designers, probably because they’re not magically solving all your problems for you. Basically, as you get more CPU cores and each of them have caches, it gets more expensive to keep everything in sync. It’s quite obvious that with *ahem* an eventually consistent model, you could save a bunch of time and effort at the expense of shifting some complexity into software.

Those in the MySQL world should recognize this – we’ve been dealing with asynchronous replication for well over a decade …

A lot a great announcements were done today at the Visual Studio Connect event. And one of the things we are more excited about is hearing that there is a new edition of Visual Studio: Visual Studio 2013 Community.

Did your logging stop working after you set up logrotate? Then this post might be for you.

Archive your log files!

Some time ago, Peter Boros wrote about Rotating MySQL Slow Logs safely, explaining the steps of a “best practice” log rotate/archive. This post will add more info about the topic.

When running logrotate for MySQL (after proper setting the /etc/logrotate.d/mysql conf file) from anacron, there’s a situation that you might potentially face if the user and password used to execute the “flush logs” command is stored in, for example, /root/.my.cnf file.

The situation:

You might find out that you have a new MySQL log file ready to receive data, but nothing is being written to it.

Why did this happen?

The logrotate script is executed, but the postrotate …

Yesterday, I got the basics going for MySQL Cluster on POWER. Today, I finished up a couple more patches to improve performance and ran some benchmarks.

This is on a 3.7Ghz POWER8 machine with non-balanced memory (only 2 of the 4 NUMA nodes have memory, so we have less total memory bandwidth than we could have, plus I’m going to bind ndbmtd to the CPUs in these NUMA nodes)

With a setup of a single replica and two data nodes on the one machine (each bound to a specific NUMA node), running the flexAsync benchmark on MySQL Cluster 7.3.7, I could get around:

• 3.2 million reads/sec
• 2.6 million deletes/sec
• 2.4 million updates/sec
• 2.4 million inserts/sec.

So, that’s at least in the right ballpark for a first go.

(I’m running this on a big endian host …

We are excited to announce that we now support monitoring Amazon RDS for MySQL. Previously we relied exclusively on deep packet inspection, but since customers can’t install agents on RDS servers, we implemented support for the MySQL PERFORMANCE_SCHEMA tables in MySQL 5.6 and newer. Support for RDS performance monitoring is available immediately.

With VividCortex for Amazon RDS for MySQL, you can get high-resolution, 1-second granularity MySQL performance metrics on all available system and query performance in the same acclaimed user interface that VividCortex’s customers say makes them more productive and effective every day.

Teams who use Amazon RDS usually do so because they want to outsource operational aspects of their MySQL database. These companies tend to …

We are excited to announce that we now support monitoring Amazon RDS for MySQL. Previously we relied exclusively on deep packet inspection, but since customers can’t install agents on RDS servers, we implemented support for the MySQL PERFORMANCE_SCHEMA tables in MySQL 5.6 and newer. Support for RDS performance monitoring is available immediately.

With VividCortex for Amazon RDS for MySQL, you can get high-resolution, 1-second granularity MySQL performance metrics on all available system and query performance in the same acclaimed user interface that VividCortex’s customers say makes them more productive and effective every day.

Teams who use Amazon RDS usually do so because they want to outsource operational aspects of their MySQL database. These companies tend to …

Not a ground-breaking post here, but if you are interested in knowing more about the innodb_log_block_size variable, or if you use SSD cards and/or large InnoDB log files on ext4, then this is for you.

I’d read about it before briefly before, but didn’t give it too much thought until I ran across the following entry in an error log the other day:

InnoDB: Warning: innodb_log_block_size has been changed
from default value 512. (###EXPERIMENTAL### operation)

This got me wanting to know more.

Basically, this variable changes the size of transaction log records. Generally, the default of 512 is a good value. However, it has been found that setting it to 4096 has been beneficial when using SSD cards. (Note that while it is possible to set this to a value other than 512 or 4096, those are currently the only 2 values that make sense to use.)

Also, it has been found that 4096 is the best setting if you run …

So some users complete a yum install of MySQL and expect to be able to use the following  command to start the MySQL server::  /etc/init.d/mysql start only to get "No such file or directory"
So this is a quick post to help use the systemctl command.  You are likely to see this: # systemctl list-unit-files | grep mysql
mysqld.service                              disabled
First I would recommend go to tools.percona.com and create a valid my.cnf file. 
So the solution is easy, we just need to enable this so the database can start on server start up.
#systemctl enable mysqld.service
ln -s '/usr/lib/systemd/system/mysqld.service' '/etc/systemd/system/mysql.service'
ln -s …

Method 1

a) dump the database using mysqldump & ftp the file across

b)Here's the simple command to restore the database using the file you dumped in the first step:

mysql -u USER -p DBNAME < dump.sql

Method 2

The way that is described above is indeed a very sloppy way!

If you have access to the other box from that machine (if they're on

the same network/ on the 'net) you can use the following - this

essentially pipes the output from mysqldump directly into the other

database - very handy indeed - instead of just dumping it into a file

and then manually ftp it to the other box the mysql < .... it in.

The first host is where you want to copy FROM and the second is where

its going TO.

mysqldump --opt --compress …