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

Displaying posts with tag: gtid (reset)

Refactoring replication topology with Pseudo GTID
+0 Vote Up -0Vote Down

This post describes in detail the method of using Pseudo GTID to achieve unplanned replication topology changes, i.e. connecting two arbitrary slaves, or recovering from a master failure even as all its slaves are hanging in different positions.

Please read Pseudo GTID and Pseudo GTID, RBR as introduction.

Consider the following case: the master dies unexpectedly, and its three slaves are all hanging, not necessarily at same binary log file/position (network broke down while some slaves managed to salvage more entries into their relay logs than others)

  [Read more...]
Pseudo GTID, Row Based Replication
+0 Vote Up -0Vote Down

This post continues Pseudo GTID, in a series of posts describing an alternative to using MySQL GTIDs.

The solution offered in the last post does not work too well for row based replication. The binary log entries for the INSERT statement look like this:

# at 1020
# at 1074
#141020 12:36:21 server id 1  end_log_pos 1074  Table_map: `test`.`pseudo_gtid` mapped to number 33
#141020 12:36:21 server id 1  end_log_pos 1196  Update_rows: table id 33 flags: STMT_END_F

BINLOG '
lddEVBMBAAAANgAAADIEAAAAACEAAAAAAAEABHRlc3QAC3BzZXVkb19ndGlkAAMDBw8CQAAE
lddEVBgBAAAAegAAAKwEAAAAACEAAAAAAAEAA///+AEAAACL10RUJDg2ZmRhMDk1LTU4M2MtMTFl
NC05NzYyLTNjOTcwZWEzMWVhOPgBAAAAlddEVCQ4Y2YzOWMyYy01ODNjLTExZTQtOTc2Mi0zYzk3
MGVhMzFlYTg=
'/*!*/;

Where's our unique value? Encoded within

  [Read more...]
Pseudo GTID
+0 Vote Up -0Vote Down

Pseudo GTID is a method to implement a GTID-like solution where slaves are easily connected to one another. This blog post and the following ones will describe work in progress (some 80% completed), where simulation of GTID makes for a good enough basis for refactoring replication topologies. I'm coding this in orchestrator, which already provides a substantial infrastructure support for this.

The final goal: orchestrator will allow you to move a slave below another, using only the data available by those two slaves. The usage is obvious:

  • Easy master failover (master dead? Orchestrator will choose the most advanced slave to promote and make it master of its siblings)
  • Slave promotion in complex topologies (with
  [Read more...]
Q&A: Putting MySQL Fabric to use
+1 Vote Up -0Vote Down

Martin Arrieta and I gave an online presentation last week on “Putting MySQL Fabric To Use.” If you missed it, you can find a recording and the slides here, and the vagrant environment we used plus a transcript of the commands we ran here (be sure to check out the ‘sharding’ branch, as that’s what we used during the webinar).

Thank you all for attending and asking interesting questions. We were unable to answer all of them in the scheduled time, so here are our replies

  [Read more...]
MySQL Slave Scaling and more
+3 Vote Up -0Vote Down

Jean-François talks about binlog servers. Take a look here: http://blog.booking.com/mysql_slave_scaling_and_more.html

MariaDB 10.0.11 Overview and Highlights
+5 Vote Up -0Vote Down

MariaDB 10.0.11 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.0.11/

This is the second GA release of MariaDB 10.0, and 12th overall release of MariaDB 10.0.

This is primarily a bug-fix release.

Here are the main items of note:

  • Updated TokuDB engine to version 7.1.6
  • Updated Spider storage engine to version 3.2 (now Gamma)
  • Updated XtraDB storage engine to version 5.6.17-65.0
  • Updated InnoDB storage engine to version 5.6.17
  • Updated
  •   [Read more...]
    Errant transactions: Major hurdle for GTID-based failover in MySQL 5.6
    +1 Vote Up -0Vote Down

    I have previously written about the new replication protocol that comes with GTIDs in MySQL 5.6. Because of this new replication protocol, you can inadvertently create errant transactions that may turn any failover to a nightmare. Let’s see the problems and the potential solutions.

    In short

    • Errant transactions may cause all kinds of data corruption/replication errors when failing over.
    • Detection of errant transactions can be done with the GTID_SUBSET() and
      [Read more...]
    GTIDs in MySQL 5.6: New replication protocol; new ways to break replication
    +1 Vote Up -0Vote Down

    One of the MySQL 5.6 features many people are interested in is Global Transactions IDs (GTIDs). This is for a good reason: Reconnecting a slave to a new master has always been a challenge while it is so trivial when GTIDs are enabled. However, using GTIDs is not only about replacing good old binlog file/position with unique identifiers, it is also using a new replication protocol. And if you are not aware of it, it can bite.

    Replication protocols: old vs new

    The old protocol is pretty straightforward: the slave connects to a given binary log file at a specific offset, and the master sends all the transactions from there.

    The new protocol is slightly different: the slave first sends the range of GTIDs it has

      [Read more...]
    MySQL 5.6 + GTID & MariaDB 10 replication
    +1 Vote Up -0Vote Down

    While at the keynote of Tomas Ulin at Percona Live MySQL Conference & Expo Santa Clara 2014, he asked the audience what they were running, and most of the audience was on MySQL 5.5 while about 15% of the audience was on MySQL 5.6. This number is steadily increasing I’m sure, so one thing that becomes important is that people will probably start turning on Global Transaction Identifiers (GTIDs). 

    As you may already know, MariaDB 10 has a different implementation of Global Transaction ID. To me, this poses a problem in a mixed use environment (or even a migration scenario). Which is why

      [Read more...]
    Cloning a slave using Mysql Enterprise Backup on a GTID enabled server
    Employee +0 Vote Up -0Vote Down

    MySQL 5.6 introduced a new feature called GTID (Global Transaction IDentifier) support in Replication. For every transaction that is committed on to the server, a GTID of the format :

    server_uuid:transaction_id is written into the master's binary log.

    This offers the following advantages:

    • Very helpful to set up a slave and create a replication setup.

    • User need not worry about fetching the master's binlog filename and position in the “CHANGE MASTER TO” command which is used to synchronise the slave with the master.

    • Applying GTIDs on slaves ensures consistency – since GTIDs are unique, it cannot be applied more than once on the server.

    For a gtid enabled server, the following properties

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