Percona is glad to announce the release of Percona Server 5.1.66-14.2 on January 15th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.1.66, including all the bug fixes in it, Percona Server 5.1.66-14.2 is now the current stable release in the 5.1 series. All of Percona‘s software is open-source and free, all the details of the release can [...]
Announcing Percona Server 5.5.28-29.3
Percona is glad to announce the release of Percona Server 5.5.28-29.3 on January 8th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.28, including all the bug fixes in it, Percona Server 5.5.28-29.3 is now the current stable release in the 5.5 series. All of Percona‘s software is open-source and free, all the details of the release can [...]
Announcing Percona XtraDB Cluster 5.5.28-23.7
Percona is glad to announce the release of Percona XtraDB Cluster on November 15th, 2012. Binaries are available from downloads area or from our software repositories. Features: Percona XtraDB Cluster has ported Twitter’s MySQL NUMA patch. This patch implements improved NUMA support as it prevents imbalanced memory allocation across NUMA nodes. Number of binlog files [...]
Percona XtraDB Cluster – installation and setup webinar follow up Q&A
Thanks for all, who attended my webinar, I got many questions and I wanted to take this opportunity to answer them. Q: Even ntp has a delay of 0.3-0.4 between servers does that mean a 0.25 as from logs can be an issue ? A: My demo vms were running for a few hours before [...]
Edge-case behavior of INSERT…ODKU
A few weeks back, I was working on a customer issue wherein they were observing database performance that dropped through the floor (to the point of an outage) roughly every 4 weeks or so. Nothing special about the environment, the hardware, or the queries; really, the majority of the database was a single table with [...]
Recovering from a bad UPDATE statement
Did you just run an UPDATE against your 10 million row users table without a WHERE clause? Did you know that in MySQL 5.5 that sometimes you can recover from a bad UPDATE statement? This is possible if you are running in binlog_format=ROW ! Imagine this scenario:
1 2 3 4 5 6 | CREATE TABLE `t1` ( `c1` int(11) NOT NULL AUTO_INCREMENT, `c2` varchar(10) NOT NULL, PRIMARY KEY (`c1`) ) ENGINE=InnoDB; INSERT INTO `t1` (`c2`) VALUES ('michael'), ('peter'), ('aamina'); |
We run an accidental UPDATE statement that [...]
MySQL 5.6.7-RC in tpcc-mysql benchmark
MySQL 5.6.7 RC is there, so I decided to test how it performs in tpcc-mysql workload from both performance and stability standpoints. I can’t say that my experience was totally flawless, I bumped into two bugs: MySQL 5.6.7 locks itself on CREATE INDEX MySQL 5.6.7-rc crashed under tpcc-mysql workload But at the end, is not [...]
Automation: A case for synchronous replication
Just yesterday I wrote about math of automatic failover today I’ll share my thoughts about what makes MySQL failover different from many other components and why asynchronous nature of standard replication solution is causing problems with it. Lets first think about properties of simple components we fail over – web servers, application servers etc. We [...]
Adaptive flushing in MySQL 5.6
As you may know, flushing in MySQL is an area of my interest, I wrote about it several times, i.e. http://www.mysqlperformanceblog.com/2011/09/18/disaster-mysql-5-5-flushing/ http://www.mysqlperformanceblog.com/2011/03/31/innodb-flushing-a-lot-of-memory-and-slow-disk/ http://www.mysqlperformanceblog.com/2011/01/03/mysql-5-5-8-in-search-of-stability/ In MySQL 5.6 there was implemented a new flushing logic, so I decided to check what do we have now.
Recovery after DROP & CREATE
In a very popular data loss scenario a table is dropped and empty one is created with the same name. This is because mysqldump in many cases generates the “DROP TABLE” instruction before the “CREATE TABLE”:
1 2 3 4 5 6 7 8 9 10 11 12 | DROP TABLE IF EXISTS `actor`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `actor` ( `actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT, `first_name` varchar(45) NOT NULL, `last_name` varchar(45) NOT NULL, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`actor_id`), KEY `idx_actor_last_name` (`last_name`) ) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8; /*!40101 SET character_set_client = @saved_cs_client */; |
If there were no subsequent CREATE TABLE the recovery would be trivial. Index_id of the PRIMARY index of [...]

