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]
This is a followup article from my previous post.
We will need nodejs in our system. Please check https://nodejs.org/en/ for downloading and install steps.
Note: I am using ubuntu 14.04 for this setup.
1. Use npm to install jslint package globally in your system.
Many a times we have faced this problem that when we commit
something and it breaks something on the server due to some
I know that these can be caught by IDEs and good editors, but sometimes there might be an syntax error introduced after a code merge conflict resolution and commit.
To address this, we can use git pre-commit hooks to check for any syntax errors in the to be committed files.
There is a good script I found which does this at https://github.com/ReekenX/phpcheck-git
Steps to add pre-commit php syntax check with git:
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]
10 Older Entries »