I want to take a moment to thank you for reading this blog. We are working very hard on cool tools for you to use with MySQL and we really enjoy spreading the news of these tools to you.  With this in mind I wanted to update you on something that is changing. We are moving to a new blog home at http://insidemysql.com/.  From this point on all new content will be posted on our new blog and we encourage each of you to update your bookmarks accordingly.  Our aggregator at http://planet.mysql.com/ has already been updated.

Don' t worry! The old posts will still be here so your old bookmarks will still work.  You can find our new Windows focused category at

…

IST Basics

State transfers in Galera remain a mystery to most people.  Incremental State transfers (as opposed to full State Snapshot transfers) are used under the following conditions:

• The Joiner node reports Galera a valid Galera GTID to the cluster
• The Donor node selected contains all the transactions the Joiner needs to catch up to the rest of the cluster in its Gcache
• The Donor node can establish a TCP connection to the Joiner on port 4568 (by default)

IST states

Galera has many internal node states related to Joiner nodes.  They currently are:

1. Joining
2. Joining: preparing for State Transfer
3. Joining: requested State Transfer
4. Joining: receiving State Transfer
5. Joining: State …

Why Multi source replication is required?

MySQL has limitation of not allowing to replicate multiple DB’s from different master host on a single slave. MySQL replication had a limitation, fixed with this new release, that said that one slave could have only one master. That is a limiting factor when we are designing our replication environment. There were some “hacks” to make it work, but now there is an official way.

What is multisource replication?
MySQL Multi-Source Replication enables a replication slave to receive transactions from multiple sources simultaneously. Multi-source replication can be used to back up multiple servers to a single server, to merge table shards, and consolidate data from multiple servers to a single server. Multi-source replication does not implement any conflict detection or resolution when applying the transactions, and those tasks are left to the …

Hi,

I think most of the DBAs experience this error in their weekly, monthly todo list. Each one follows different approach, I would like to share some tips here:

1. You should first execute “Show Slave Status;” and check the output, analyze it. Whether SQL thread has stopped or I/O thread has stopped and check respective error , It should be either SQL error or I/O error, based on that take next step.

I/O thread has stopped:

1. Check that you can reach the master host from slave hostby using ping or traceroute/tracert to reach the host.
2. Connect to Master host and check whether “Replication thread” is connected.
3. There are multiple thread state involved, you need to take action based on thread state –  …

UPDATE: Almost solved! See at the end.

A clean installation of a database server is one where everything goes according to the expectations. It used to be easy: you only had to do what the manual says, and, presto! you would see your database server installed and ready to use. If something went wrong, you got one or more error messages that informed you of what needs to be fixed.

Sometimes, rarely, it happened that you got also a warning message, telling you that while the installation was successful, you could improve it by fine tuning this and that. No big deal.

Gone are those times. A clean installation nowadays is a much harder exercise, if not impossible. Let’s give it a try using MySQL 5.7.7.



Attempt #1 using mysql_install_db
The first error you could do when using a new version of MySQL is assuming that basic operations are …

The MySQL 5.7.8 Release Candidate was released August 3rd. But before you upgrade, be sure to read how to upgrade from 5.6 to 5.7 PLEASE.

Yes, you need to make a backup (or three or four).

Be sure to run mysql_upgrade after starting the 5.7 binary. There are some changes to tables that must be made and this is the way to do it.

The upgrade docs offers several upgrade scenarios.

Also take time to read the MySQL 5.7 Release Notes! This is not only a list of new goodies but it warns you to …

Many of us have been there in the past, you get an alert telling you that replication has stopped because of an error, you dig in to it to find that you’re getting an error for an update event that is trying to update a non-existent row, or a duplicate key error because the row ID for some INSERT already exists.

Even with the server set to read only (and not using the new super_read_only variable from MySQL 5.7.8), these problems can still happen – how many of you have seen over-zealous ops trying to “quickly fix” some problem only to royally screw up your data integrity?

The question then becomes – “who or what is making changes on my replica that shouldn’t be?!?”.

The only way to find this out in the past, and still “the conventional wisdom” (I just saw it recommended …

Today’s episode is all about Valgrind – from the pro’s to the con’s, from the why to the how! This episode will be of interest to anyone who is or wants to work with Valgrind on a regular or semi-regular basis.

1. Pro’s/Why
2. Con’s
3. How
   1. Using the latest version
      sudo [yum/apt-get] install valgrind
      #OR#
      sudo [yum/apt-get] remove valgrind
      sudo [yum/apt-get] install bzip2 glibc*
      wget http://valgrind.org/downloads/valgrind-3.10.1.tar.bz2
      tar -xf valgrind-3.10.1.tar.bz2; cd valgrind-3.10.1
      ./configure; make; sudo make install
      valgrind –version # This should now read 3.10.1
   2. VGDB (cd ./mysql-test)
      ./lib/v1/mysql-test-run.pl –start-and-exit –valgrind –valgrind-option=”–leak-check=yes”
      –valgrind-option=”–vgdb=yes” …

Execute “Show Engine InnoDB Status;” query analyze the result in “Transaction” section, find out problematic queries.

Now next step is to how to avoid this problem, and here is a solution:

Deadlocks are a classic problem in transactional databases, but they are not dangerous unless they are so frequent that you cannot run certain transactions at all. Normally, you must write your applications so that they are always prepared to re-issue a transaction if it gets rolled back because of a deadlock.

• Always be prepared to re-issue a transaction if it fails due to deadlock. Deadlocks are not dangerous. Just try again.
• Keep transactions small and short in duration to make them less prone to collision.

Reference :  …

It mentions in the message that you can try to repair it. Also, if you look at the actual FILEPATH you get, you can find out more:

• if it is something like /tmp/#sql_actor_return it means that MySQL needs to create a temporary table because of the query size. It stores it in /tmp, and that there is not enough space in your /tmp for that temporary table. increase the tmp_table_size variable and /tmp/ partition size
• If it contains the name of an actual table instead, it means that this table is very likely corrupted and you should repair it using REPAIR TABLE