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

Displaying posts with tag: transactions (reset)

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:

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

    Transaction T2:

        SELECT t1.a, t2.b
          FROM xtradb_table t1 INNER JOIN pbxt_table t2 ON
        WHERE = 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...]
    SQL Locking and Transactions – OSDC 2011 video
    +0 Vote Up -0Vote Down
    This recent session at OSDC 2011 Canberra is based on part of an Open Query training day, and (due to time constraints) without much of the usual interactivity, exercises and further MySQL specific detail. People liked it anyway, which is nice! The info as presented is not MySQL specific, it provides general insight in how databases implement concurrency and what trade-offs they make. See for the talk abstract.
    Shinguz: MySQL Query Cache does not work with Complex Queries in Transactions
    +1 Vote Up -0Vote Down

    We did recently a review of one of our customers systems and we found that the Query Cache was disabled even thought it had significant more read than write queries.
    When we asked the customer why he has not enabled the Query Cache he mentioned a review that was done a few years ago and which stated that the Query Cache hit ratio was non optimal.
    This was verified on a testing system which had the Query Cache enabled by accident.

    But we all thought that the Query Cache would make sense in this situation so we investigated a bit more.

    They have a Java application where they do pretty complex queries (10 to 30-way Joins) and they Connect with Connector/J to the database. We tried it out in the application on a dedicated system and verified that the Query Cache was not serving our queries but the query did a full dive to the

      [Read more...]
    Showing entries 1 to 10 of 33 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.