Posted by francisco bordenave on Oct 14, 2011
This post was thought of as an attempt to make some performance test with new multi-threaded replication in 5.6, at least that was my initial intention. Based on Luis Soarez – Replication Team Leader in Oracle – post. I wanted to play with new set of variables and features in order to understand how new multi-threaded replication works and make some performance tests. Read the rest of this entry . . .
Posted by francisco bordenave on May 30, 2011
Recently I was dealing with some locking issues in databases supporting WordPress. For those who don’t know it yet WordPress is a really cool open source tool for easy blogging. This tool is really easy to install (just drag and dropping in your home directory) and making it really easy for you to get up and running.
As a part of this easy installation there are some things that aren’t best practices for good performance and scalable sites. These limitations are related to the use of MyISAM as a storage engine. This engine was for many years the default storage engine in MySQL. It changed, fortunately, with 5.5, but in previous installations MyISAM will be there for use.
MyISAM storage engine is really good at retrieving data but:
- it doesn’t support concurrency
- all operations causes table level locking (this is not entirely true but mostly)
- it’s not crash-safe (you’ll hate it during a crash)
Read the rest of this entry . . .
Posted by francisco bordenave on May 10, 2011
A few days ago one of our customers contact us to inform a problem with one of their replication servers.
This server was reporting this issue:
Last_Error: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’s MySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.
After brief research we found the customer had deleted some binary logs from the master and relay logs from slave to release space since they were having space issues.
The customer requested us to get slave working again without affecting the production environment.
Our goal here was to figure out how to restore replication without going through an entire rebuild of slave, although this may have been the easiest solution, it had been necessary to lock the master to take a good backup, restore the binary logging, and then restore the slave of a proper replication point.
This kind of things starts to be complicated when we talk about more than 1TB to rebuild.
Unfortunately customer didn’t backed up relay-logs, but fortunately customer was backed up binary logs so that would be our starting point.
Read the rest of this entry . . .
