You searched for mysql auto commit insert

Is Synchronous Replication right for your app?

May 14, 2013 By Jay Janssen 17 Comments

I talk with lot of people who are really interested in Percona XtraDB Cluster (PXC) and mostly they are interested in PXC as a high-availability solution. But, what they tend not to think too much about is if moving from async to synchronous replication is right for their application or not. Facts about Galera replication [...]

Filed Under: MySQL, Percona Software, XtraDB Cluster Tagged With: async, Galera replication, hotspots, Jay Janssen, Percona XtraDB Cluster, pxc, Synchronous Replication

Benchmarking Percona Server TokuDB vs InnoDB

May 7, 2013 By Vadim Tkachenko 32 Comments

After compiling Percona Server with TokuDB, of course I wanted to compare InnoDB performance vs TokuDB. I have a particular workload I’m interested in testing – it is an insert-intensive workload (which is TokuDB’s strong suit) with some roll-up aggregation, which should produce updates in-place (I will use INSERT .. ON DUPLICATE KEY UPDATE statements [...]

Filed Under: Benchmarks, MySQL, Percona Server Tagged With: Benchmarking, InnoDB, Percona Server, TokuDB

Repair MySQL 5.6 GTID replication by injecting empty transactions

March 26, 2013 By Miguel Angel Nieto 1 Comment

In a previous post I explained how to repair MySQL 5.6 GTID replication using two different methods. I didn’t mention the famous SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n for a simple reason, it doesn’t work anymore if you are using MySQL GTID. Then the question is: Is there any easy way to skip a single transaction? [...]

Filed Under: MySQL

InnoDB Full-text Search in MySQL 5.6 (part 1)

February 26, 2013 By Ernie Souhrada 1 Comment

I’ve never been a very big fan of MyISAM; I would argue that in most situations, any possible advantages to using MyISAM are far outweighed by the potential disadvantages and the strengths of InnoDB. However, up until MySQL 5.6, MyISAM was the only storage engine with support for full-text search (FTS). And I’ve encountered many [...]

Filed Under: Insight for DBAs, Insight for Developers, MySQL Tagged With: Ernie Souhrada, FTS, FullText Search, InnoDB, MyISAM, MySQL 5.6

Implications of Metadata Locking Changes in MySQL 5.5

February 1, 2013 By Ovais Tariq 9 Comments

While most of the talk recently has mostly been around the new changes in MySQL 5.6 (and that is understandable), I have had lately some very interesting cases to deal with, with respect to the Metadata Locking related changes that were introduced in MySQL 5.5.3. It appears that the implications of Metadata Locking have not [...]

Filed Under: Insight for DBAs, Insight for Developers, MySQL Tagged With: alter table, ddl, metadata locking, query cache, table cache, transaction, Transaction isolation

Edge-case behavior of INSERT…ODKU

October 27, 2012 By Ernie Souhrada 6 Comments

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 [...]

Filed Under: Insight for DBAs, Insight for Developers, MySQL

Recovering from a bad UPDATE statement

October 19, 2012 By Michael Coburn 5 Comments

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:

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');

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 [...]

Filed Under: Insight for DBAs, Insight for Developers, MySQL

MySQL 5.6.7-RC in tpcc-mysql benchmark

October 8, 2012 By Vadim Tkachenko 21 Comments

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 [...]

Filed Under: Benchmarks, MySQL

Recovery after DROP & CREATE

August 22, 2012 By Aleksandr Kuzminsky 1 Comment

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”:

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 */;

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 [...]

Filed Under: MySQL Tagged With: drop table, InnoDB, Recovery

Percona XtraDB Cluster: Multi-node writing and Unexpected deadlocks

August 17, 2012 By Jay Janssen 17 Comments

Percona XtraDB Cluster (PXC) and the technology it uses (Galera) is an exciting alternative to traditional MySQL replication. For those who don’t know, it gives you: Fully Synchronous replication with a write latency increase equivalent to a ping RTT to the furthest node Automatic cluster synchronization, both incremental and full restores The ability to read [...]

Filed Under: MySQL, XtraDB Cluster

Is Synchronous Replication right for your app?

Benchmarking Percona Server TokuDB vs InnoDB

Repair MySQL 5.6 GTID replication by injecting empty transactions

InnoDB Full-text Search in MySQL 5.6 (part 1)

Implications of Metadata Locking Changes in MySQL 5.5

Edge-case behavior of INSERT…ODKU

Recovering from a bad UPDATE statement

MySQL 5.6.7-RC in tpcc-mysql benchmark

Recovery after DROP & CREATE

Percona XtraDB Cluster: Multi-node writing and Unexpected deadlocks

Search

Top Searches

Percona Webinars

ABOUT PERCONA

Percona MySQL Training

Percona Careers

SOFTWARE FROM PERCONA

SERVICES FOR MYSQL USERS

ABOUT THIS BLOG AND PERCONA