Your favourite monitoring software throws an alert or sends an email after it finds the following in the mysql error log: InnoDB: page [page id: space=8858, page number=206777] (95 records, index id 29361) How do you find which index is … Continue reading →
10 Older Entries »
Since Percona XtraDB Cluster is a multi-master solution, when an application executes conflicting workloads one of the workloads gets rolled back with a DEADLOCK error. While the same holds true even if you fire the workload through a PREPARE statement, there are differences between using the MySQL connector API (with binary protocol) and the MySQL client (with text protocol). Let’s look at these differences with the help of an example.
- Say we have a two-node cluster (n1 and n2) with the following
base schema and tables:
use test; create table t (i int, k int, primary key pk(i)) engine=innodb; insert into t values (1, 10), (2, 20), (3, 30); …
In this blog, we’ll discuss the ramifications of the Galera Error Failed to Report Last Committed (Interrupted System Call).
I have recently seen this error with Percona XtraDB Cluster (or Galera):
[Warning] WSREP: Failed to report last committed 549684236,
-4 (Interrupted system call)
It was posted in launchpad as a bug in 2013: https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1434646
My colleague Przemek replied, and explained it as:
Reporting the last committed transaction is just a part of the certification index purge process. In case it fails for some reason (it occasionally does), the cert index purge may be a little delayed. But it does not mean the transaction was not applied successfully. This is a warning after all.
If we look up this error in the source code, we realize …[Read more]
While doing some testing (that I published later here) on the still-in-development MySQL 5.7 I wanted to do some analysis on the configuration to see if the changes in performance were due to the code changes or just to the new MySQL defaults (something that is very common in the migration from 5.5 to 5.6 due to the default transaction log size and other InnoDB parameters). This is a quick post aiming to identify the global variables changed between these two versions.
You could tell me that you could just read the release notes, but my experience (and this is not an exception, as you will see) …[Read more]
A fascinating post-mortem on high profile network failures:
This post is meant as a reference point–to illustrate that, according to a wide range of accounts, partitions occur in many real-world environments. Processes, servers, NICs, switches, local and wide area networks can all fail, and the resulting economic consequences are real. Network outages can suddenly arise in systems that are stable for months at a time, during routine upgrades, or as a result of emergency maintenance. The consequences of these outages range from increased latency and temporary unavailability to inconsistency, corruption, and data loss. Split-brain is not an academic concern: it happens to all kinds of systems–sometimes for days on end. Partitions deserve serious consideration.
Importing a text file containing a list of SQL commands into
MySQL is a straightforward task. All you need to do is simply
feed the file contents through pipe into MySQL command line
client. For example:
mysql app_production <
The reasons for doing such imports can be very different - restoring MySQL backups created with mysqldump, manually replaying binary log events or performing database migrations during software roll-outs.
While the task is simple, the import may not end successfully and when this happens, how to tell what the problem was?
Whenever database hits an error, MySQL produces an error message that describes the problem and the import process stops immediately. If the message is not clear enough, you can always refer to the reported line number, which is the line number inside the source SQL file. This way you can locate the precise command or query that …[Read more]
This would have to be one of the most common MySQL error messages that is misleading to the end user developer. The MySQL Manual page confirms the broad range of possible conditions, but offers little to a PHP developer that does not speak MySQL Geek. I am commonly asked to help solve this issue from a developer.
The problem is that there are several conditions that can cause this error, and a more meaningful explanation to the end user would help in addressing the issue. In general terms, this actually means “Your SQL statement has failed because the connection to the database has been disconnected because of ???”.
Here are a few common situations and how to check for what “???” is.
1. Your MySQL server really did go away.
We can easily check this by looking at the server uptime and the server error log.
$ …[Read more]
We’re always testing the latest versions of MySQL with most of the environments to make sure that we can find the critical issues before it goes to production. This wasn’t different with the 5.6 MySQL neither. We already started to play with this version in the summer. The first news were very promising. The performance gain is significant. However we have run into couple of errors. One of them was the
mysql_install_db problem with replicating environment
[root@hostname ~]# mysql_install_db --user=mysql --datadir=/mysql/data/ ------------------------------------------------------------------------------------ Installing MySQL system tables... 121217 10:02:20 InnoDB: The InnoDB memory heap is disabled 121217 10:02:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins 121217 10:02:20 InnoDB: Compressed tables use zlib 1.2.3 121217 10:02:20 InnoDB: Using Linux native AIO 121217 10:02:20 InnoDB: CPU supports crc32 instructions 121217 10:02:20 …[Read more]
There are mistakes that drive you crazy when you try to understand what went wrong.
One of the most annoying and hard to catch was this, apparently harmless line:
tungsten-sandbox -m 5.5.24 --topology all-masters -n 2 -p 7300 -l 12300 -r 10300 –t $HOME/mm -d tsb-mm
The person reporting the error told me that the installation directory (indicated by "-t") was not taken into account.
I usually debug by examples, so I copied the line, and pasted it into one of my servers. Sure enough, the application did not take trat option into account. The installation kept happening in the default directory.
I knew that I had done a good job at making the application configurable, but I checked the code nonetheless. The only place where the default directory is mentioned is when the related variable is initialized. Throughout the code, there are no literal values used for this purpose. And yet, the …[Read more]
I had to install Percona XtraDB Cluster, I think for the first time since it was announced stable. I remembered many problems I faced with beta releases, which was understandable given they were only for a preview, but this time I hoped for significant improvements.
I have to say I am generally quite sensitive about simple problems that could/should be easily discovered and corrected. Well, it didn’t take five minutes to see a few of such problems. These minutes I spent installing the database binaries from Percona Yum repository. It turned out that was enough to see a lot of errors for no reason. Not a good thing.
[..] Installing : 1:Percona-XtraDB-Cluster-server-5.5.23-23.5.333.rhel6.x86_64 5/5 ls: cannot access /var/lib/mysql/*.err: No such file or directory ls: cannot access /var/lib/mysql/*.err: No such file or directory [Note] Flashcache bypass: disabled
Why does it matter that ls: cannot access …[Read more]
10 Older Entries »