Home |  MySQL Buzz |  FAQ |  Feeds |  Submit your blog feed |  Feedback |  Archive |  Aggregate feed RSS 2.0 English Deutsch Español Français Italiano 日本語 Русский Português 中文
Showing entries 1 to 14

Displaying posts with tag: Jay Janssen (reset)

Galera data on Percona Cloud Tools (and other MySQL monitoring tools)
+0 Vote Up -0Vote Down

I was talking with a Percona Support customer earlier this week who was looking for Galera data on Percona Cloud Tools. (Percona Cloud Tools, now in free beta, is a hosted service providing access to query performance insights for all MySQL uses.)

The customer mentioned they were already keeping track of some Galera stats on Cacti, and given they were inclined to use Percona Cloud Tools more and more, they wanted to know if it was already supporting Percona XtraDB Cluster. My answer was: “No, not yet: you can install

  [Read more...]
Galera data on Percona Cloud Tools (and other MySQL monitoring tools)
+0 Vote Up -0Vote Down

I was talking with a Percona Support customer earlier this week who was looking for Galera data on Percona Cloud Tools. (Percona Cloud Tools, now in free beta, is a hosted service providing access to query performance insights for all MySQL uses.)

The customer mentioned they were already keeping track of some Galera stats on Cacti, and given they were inclined to use Percona Cloud Tools more and more, they wanted to know if it was already supporting Percona XtraDB Cluster. My answer was: “No, not yet: you can install agents in

  [Read more...]
Semi-Sync replication performance in MySQL 5.7.4 DMR
+2 Vote Up -0Vote Down

I was interested to hear about semi-sync replication improvements in MySQL’s 5.7.4 DMR release and decided to check it out.  I previously blogged about poor semi-sync performance and was pretty disappointed from semi-sync’s performance across WAN distances back then, particularly with many client threads.

The Test

The basic environment of these tests was:

  • AWS EC2 m3.medium instances
  • Master in us-east-1, slave in us-west-1 (~78ms ping RTT)
  • CentOS 6.5
  • innodb_flush_log_at_trx_commit=1
  • sync_binlog=1
  • Semi-sync replication plugin installed and enabled.
  • GTID’s enabled (except on 5.5)
  • sysbench 0.5 update_index.lua test, 60 seconds,
  [Read more...]
MySQL High Availability With Percona XtraDB Cluster (Percona MySQL Training)
+1 Vote Up -0Vote Down

I’ve had the opportunity to train lots of people on Percona XtraDB Cluster (PXC) over the last few years the product has existed.  This has taken the form of phone calls, emails, blog posts, webinars, and consulting engagements. This doesn’t count all the time I’ve spent grilling Codership on how things actually work.  But it has culminated in the PXC tutorial I have given annually at Percona Live MySQL Conference and Expo in Santa Clara, California for the last two years.  

  [Read more...]
Doing a rolling upgrade of Percona XtraDB Cluster from 5.5 to 5.6
+0 Vote Up -0Vote Down

Overview

Percona XtraDB Cluster 5.6 has been GA for several months now and people are thinking more and more about moving from 5.5 to 5.6. Most people don’t want to upgrade all at once, but would prefer a rolling upgrade to avoid downtime and ensure 5.6 is behaving in a stable fashion before putting all of production on it. The official guide to a rolling upgrade can be found in the PXC 5.6 manual. This blog post will attempt to summarize the basic process.

However, there are a few caveats to trying to do a rolling 5.6 upgrade from 5.5:

  • If you mix Galera 2 and Galera 3 nodes, you must set
  •   [Read more...]
    Row-based replication, MySQL 5.6 upgrades and temporal data types
    +0 Vote Up -0Vote Down

    Whither your rollback plan?

    MySQL 5.6 upgrades are in full swing these days and knowing how to safely upgrade from MySQL 5.5 to 5.6 is important. When upgrading a replication environment, it’s important that you can build a migration plan that safely allows for your upgrade with minimal risk — rollback is often a very important component to this.

    For many people this means upgrading slaves first and then the master.  The strategy of an older master replicating to a newer slave is well known and has been supported in MySQL replication for a very long time.  To be specific:  you can have a MySQL 5.6 slave of a 5.5 master and this should work fine until you upgrade your master and/or promote one of the slaves to be the

      [Read more...]
    Followup questions to ‘What’s new in Percona XtraDB Cluster 5.6′ webinar
    +1 Vote Up -0Vote Down

    Thanks to all who attended my webinar yesterday.  The slides and recording are available on the webinar’s page.  I was a bit overwhelmed with the amount of questions that came in and I’ll try to answer them the best I can here.

    Q: Does Percona XtraDB Cluster support writing to multiple master?

    Yes, it does.  However, locks are not held on all nodes while a transaction is in progress, so there is a possibility for conflicts between simultaneous writes on different nodes.  Certification is the process that Galera uses to protect your data integrity, and the problem is pushed back to the application to handle in the form of deadlock errors.   As long as you understand this and the conditions where you may see more

      [Read more...]
    Upcoming Webinar: What’s new in Percona XtraDB Cluster 5.6
    +1 Vote Up -0Vote Down

    I’ve been blogging a lot about some of the new things you can expect with 

      [Read more...]
    Finding a good IST donor in Percona XtraDB Cluster 5.6
    +0 Vote Up -0Vote Down
    Gcache and IST

    The Gcache is a memory-based cache of recent Galera transactions that is local to each node in a cluster.  If a node leaves and rejoins the cluster, it can use the gcache from another node that stayed in the cluster (i.e., its donor node) to fetch the transactions it missed (IST) as opposed to doing a full state snapshot transfer (SST).  However, there are a few nuances that are not obvious to the beginner:

    • The Gcache is lost when a node restarts
    • The Gcache is fixed size and implemented as a LRU.  Once it is full, older transactions roll off.
    • Donor selection is made irregardless of the gcache state
    • If the given donor for a restarting node doesn’t have all transactions needed, a full SST (read: full backup) is done instead
    • Until recent developments, there was no way to tell what,
      [Read more...]
    Automatic replication relaying in Galera 3.x (available with PXC 5.6)
    +1 Vote Up -0Vote Down

    A decade ago MySQL folks were in love with the concept of a relay slave for MySQL high availability across data centers.  A relay is a single slave in a remote data center that receives replication from the global master and, in turn, replicates to all the other local slaves in that data center.  This saved a lot of bandwidth, especially back in the days before memcached when scaling reads meant lots of slaves.  Sending 20 copies of your replication stream cross-WAN gets expensive.

    In Galera and Percona XtraDB Cluster (PXC), by default when a transaction commits on a given node it is sent to every other node in the cluster from that node.  That is, the actual writeset payload (the RBR events) are sent over the network to every other node, so the bandwidth to

      [Read more...]
    New wsrep_provider_options in Galera 3.x and Percona XtraDB Cluster 5.6
    +1 Vote Up -0Vote Down

    Now that Percona XtraDB Cluster 5.6 is out in beta, I wanted to start a series talking about new features in Galera 3 and PXC 5.6.  On the surface, Galera 3 doesn’t reveal a lot of new features yet, but there has been a lot of refactoring of the system in preparation for great new features in the future.

    Galera vs MySQL options

    wsrep_provider_options is a semi-colon separated list of key => value configurations that set low-level Galera library configuration.  These tweak the actual cluster communication and replication in the group communication system.  By contrast, other PXC global variables (like ‘wsrep%’)

      [Read more...]
    Measuring Max Replication Throughput on Percona XtraDB Cluster with wsrep_desync
    +1 Vote Up -0Vote Down
    Checking throughput with async MySQL replication

    Replication throughput is the measure of just how fast the slaves can apply replication (at least by my definition).  In MySQL async replication this is important to know because the single-threaded apply nature of async replication can be a write performance bottleneck.  In a production system, we can tell how fast the slave is currently running (applying writes), and we might have historical data to check for the most throughput ever seen, but that doesn’t give us a solid way of determining where we stand right NOW().

    An old consulting trick to answer this question is to simply stop replicating on your slave for a minute, (usually just the SQL_THREAD), restart it and watch how long it takes to catch up.  We can also watch the slave thread apply rate during this interval

      [Read more...]
    Changing an async slave of a PXC cluster to a new Master
    +1 Vote Up -0Vote Down
    Async and PXC

    A common question I get about Percona XtraDB Cluster is if you can mix it with asynchronous replication, and the answer is yes!  You can pick any node in your cluster and it can either be either a slave or a master just like any other regular MySQL standalone server (Just be sure to use log-slave-updates in both cases on the node in question!).  Consider this architecture:

    However, there are some caveats to be aware of.  If you slave from a cluster node, there is no built in mechanism to fail that slave over automatically to another master node in your cluster.  You cannot assume that the binary log positions are the same on all nodes in

      [Read more...]
    Is Synchronous Replication right for your app?
    +5 Vote Up -0Vote Down

    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

    There’s a lot of different facts about Galera that come into play here, and it isn’t always obvious how they will affect your database workload.  For example:

    • Transaction commit takes approximately the worst packet round trip time (RTT) between any two nodes in your cluster.
    • Transaction apply on slave nodes is still asynchronous from client commit (except on the original node where the transaction is
      [Read more...]
    Showing entries 1 to 14

    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.