|Showing entries 1 to 10|
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 been covered well, and since there are still a large number of MySQL 5.0 and 5.1 installations that would upgrade or are in the process of upgrading to MySQL 5.5, I thought it necessary to discuss what these implications exactly are.
To read what Metadata Locking exactly is please read this section here in the MySQL manual.
Let’s start off with having a look at the Meta Data Locking behavior prior to MySQL 5.5.3
Global Transaction Identifiers (GTIDs) are one of the key replication enhancements in MySQL 5.6. GTIDs make it simple to track and compare replication across a master - slave topology. This enables:
- Much simpler recovery from failures of the master,
- Introduces great flexibility in the provisioning and on-going management of multi-tier or ring (circular) replication topologies.
A new on-demand MySQL 5.6 GTID webinar (http://www.mysql.com/news-and-events/web-seminars/mysql-replication-simplifying-scaling-and-ha-with-gtids/) delivered by the replication engineering team is now available, providing deep insight into the design and implementation of GTIDs, and how they enable users to simplify MySQL scaling and HA. The webinar covers:
- Concepts: What is[Read more...]
If you execute the following, what does your RDBMS do?
CREATE TABLE t1 (a int); START TRANSACTION; INSERT INTO t1 (a) VALUES (1); START TRANSACTION; INSERT INTO t1 (a) VALUES (2); ROLLBACK; SELECT * FROM t1;
The answer may surprise you.
Multi versioning concurrency control (MVCC) is a database design theory that enables relational databases to support concurrency, or more simply multiple user access to common data in your database.
In MySQL (http://www.mysql.com) the InnoDB storage engine provides MVCC, row-level locking, full ACID compliance as well as other features.
In my understanding of database theory, access to modify independent sections of unique data (e.g. UPDATE) under MVCC should fully support concurrency. I have however experienced a level of exclusive locking under Innodb.
I wanted to clearly document this situation so I could then seek the advice of the guru’s in InnoDB Internals such as Mark Callaghan, Percona and the Innodb development team for example.[Read more...]
This is the 137th edition of Log Buffer, the weekly review of database blogs. Dave Edwards is enjoying a week off, and so as part of my plot to take over the world, I am writing this week’s Log Buffer.
First, the fun stuff: Josh Berkus tells us that the American English Translation of the Manga Guide to Databases is available in Japanese Fairies and Third Normal Form.[Read more...]
The reason is that isolation between concurrent transactions cannot be guaranteed, meaning that two concurrent transactions are not guaranteed to be serializable (the result of a concurrent transaction that has committed can "leak" into an ongoing transaction). Since they are not serializable, it means they cannot be written to the binary log in an order that produce the same result on the slave as on the master.
However, when using row-based replication they are serializable, because whatever values are written to the tables are also written to the binary log, so if data "leaks" into an ongoing[Read more...]
|Showing entries 1 to 10|