Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
Showing entries 1 to 10 of 35 10 Older Entries

Displaying posts with tag: transactions (reset)

When your query is blocked, but there is no blocking query - Part 3
+0 Vote Up -0Vote Down
In the previous blog posts I've talked about transactions which block other transactions but don't do anything and about some possible solutions.

In this post I will show you how to get even more information about what is locked by a transaction.

As you might have noticed the information_schema.innodb_locks table doesn't show all locks. This is what the documentation says:
"The INNODB_LOCKS table contains information about each lock that an InnoDB transaction has requested but not yet acquired, and each lock that a transaction




  [Read more...]
When your query is blocked, but there is no blocking query - Part 2
+0 Vote Up -0Vote Down
In my previous post I talked about a transaction which blocked other transactions without doing anything. I talked about finding data from the blocking transaction using SYS and performance_schema.

But what are the possible solutions?

The first solution is to (automatically) kill the blocking transactions. Long running transactions can also stall the purging in InnoDB. See this blog post by Mark Leith about a possible solution.

The second solution would be make the application end the transaction sooner and/or to commit more often. Depending on your application this might or might not work. I consider this the





  [Read more...]
Introducing TokuMX Transactions for MongoDB Applications
+1 Vote Up -1Vote Down

Since our initial release last summer, TokuMX has supported fully ACID and MVCC multi-statement transactions. I’d like to take this post to explain exactly what we’ve done and what features are now available to the user.

But before beginning, an important note: we have implemented this for non-sharded clusters only. We do not support distributed transactions across different shards.

At a high level, what have we done?

We have taken MongoDB’s basic transactional behavior, and extended it. MongoDB is transactional with respect to one, and only one, document. MongoDB guarantees single document atomicity. Journaling provides durability

  [Read more...]
How InnoDB works with transactions and auto recovery
+0 Vote Up -0Vote Down
How InnoDB work with transactions: When any transaction will be completed with COMMIT,  InnoDB will write those changes in InnoDB Buffer Pool. After that InnoDB will run some background operations like checkpoint.  Checkpoint is the most important operation which will Continue reading →   [Read more...]
MySQL needs single master to check data integrity
+0 Vote Up -0Vote Down

Read the original article at MySQL needs single master to check data integrity

MySQL slaves can drift out of sync. Many of our clients are surprised to find some data differences in their replication topology, once we do some checking and sniffing around. Such checks require a single reliable or authoritative master to compare against. Click through to the end for multi-master solutions that work with MySQL. Reason [...]

For more articles like these go to Sean Hull's Scalable Startups

Related posts:
  • MySQL requires an authoritative master to build slaves
  •   [Read more...]
    Implications of Metadata Locking Changes in MySQL 5.5
    +1 Vote Up -0Vote Down

    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.

    The post Implications of Metadata Locking Changes in MySQL 5.5 appeared first on ovais.tariq.

    Easily testing MySQL 5.6 GTID in a sandbox
    +6 Vote Up -0Vote Down

    MySQL 5.6 seems to be ready for GA. I have no inside information about it, but from some clues collected in various places I feel that the release should not be far away. Thus, it's time for some serious testing, and for that purpose I have worked at updating MySQL Sandbox with some urgent features.

    I have just released MySQL Sandbox 3.0.28, with more support for MySQL 5.6. Notably in this release, there is suppression of MySQL 5.6 annoying verbosity, additional suppression of more annoying warnings ( actually a bug) when using empty passwords

      [Read more...]
    XA Transactions between TokuDB and InnoDB
    +2 Vote Up -0Vote Down
    The recently released TokuDB brings many features. One of those features is support for XA Transactions. InnoDB already has support for XA Transactions.

    XA Transactions are transactions which span multiple databases and or applications. XA Transactions use 2-phase commit, which is also the same method which MySQL Cluster uses.

    Internal XA Transactions are used to keep the binary log and InnoDB in sync.

    Demo 1: XA Transaction on 1 node:
    mysql55-tokudb6> XA START 'demo01';
    Query OK, 0 rows affected (0.00 sec)

    mysql55-tokudb6> INSERT INTO xatest(name) VALUES('demo01');
    Query OK, 1 row affected (0.01 sec)

    mysql55-tokudb6> SELECT * FROM xatest;
    +----+--------+
    | id | name |
    +----+--------+
    | 3 | demo01 |
    +----+--------+
    1 row in set (0.00 sec)




















      [Read more...]
    Consistent transactions between storage engines
    +1 Vote Up -0Vote Down

    You may not realize it, but in MariaDB 5.2 and earlier and in MySQL up to version 5.5, START TRANSACTION WITH CONSISTENT SNAPSHOT does not give any guarantees of consistency between different storage engines.

    For example, suppose you have two transactions which run in parallel:

    Transaction T1:

    BEGIN;
        SET @t = NOW();
        UPDATE xtradb_table SET a= @t WHERE id = 5;
        UPDATE pbxt_table SET b= @t WHERE id = 5;
        COMMIT;
    

    Transaction T2:

    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
        START TRANSACTION WITH CONSISTENT SNAPSHOT;
        SELECT t1.a, t2.b
          FROM xtradb_table t1 INNER JOIN pbxt_table t2 ON t1.id=t2.id
        WHERE t1.id = 5;
    

    In the above case, it is possible, even with a "consistent" snapshot, to see the changes in a transaction only in InnoDB/XtraDB tables, and not in

      [Read more...]
    Better scaling of read-only workloads
    Employee +3 Vote Up -0Vote Down

    The problem and its cause

    There have been several complaints over the years about InnoDB’s inability to scale beyond 256 connections. One of the main issues behind this scalability bottleneck was the read view creation that is required for MVCC (Multi Version Concurrency Control) to work. When the user starts a transaction this is what InnoDB does under the hood:

    • Create or reuse a transaction instance – usually it is reused, the transactions are reused from a pool (trx_sys_t::mysql_trx_list).
    • Initialize the transaction start time and assign a rollback segment
    • Append the transaction to an active  transaction list ordered on trx_t::id in descending order

    The append to  the trx_sys_t::trx_list and corresponding remove during commit is covered by trx_sys_t::mutex. After the transaction is


      [Read more...]
    Showing entries 1 to 10 of 35 10 Older Entries

    Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

    Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.