Comments on: Galera Flow Control in Percona XtraDB Cluster for MySQL https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/ Tue, 13 Feb 2024 18:33:33 +0000 hourly 1 https://wordpress.org/?v=6.5.2 By: Phil Stracchino https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-10799503 Mon, 11 May 2015 17:52:03 +0000 https://www.percona.com/blog/?p=15017#comment-10799503 @Jay,
Server version: 5.6.22-72.0-56-log Percona XtraDB Cluster (GPL), Release rel72.0, Revision 978, WSREP version 25.8, wsrep_25.8.r4150

After further examination, it appears that part of the problem is probably that Cacti is using the NONBLOCKING extension which exists only in MySQL 5.7.0-5.7.5. One would expect that the cluster should just ignore this and return an error to Cacti. instead, it appears to trigger an issue with flow control resolution.

]]> By: Jay Janssen https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-10799030 Mon, 11 May 2015 13:43:57 +0000 https://www.percona.com/blog/?p=15017#comment-10799030 @phil — I’ve seen situations where a backlogged queue (which is why FC happens in the first place) can cause SHOW STATUS to hang, but this was in older PXC. I can imagine a similar situation with SHOW SLAVE STATUS, but it does seem unlikely. What version are you running?

]]> By: Phil Stracchino https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-10788983 Thu, 07 May 2015 16:52:44 +0000 https://www.percona.com/blog/?p=15017#comment-10788983 @Jay, is there any known/documented interaction between flow control in XtraDB Cluster and SHOW SLAVE STATUS that would cause a running SHOW SLAVE STATUS NONBLOCKING to cause a delay in recovery from flow control? A customer is trying to refactor code in his applications that is causing flow control events in a pre-production five-node 5.6 cluster, of which node 1 is an asynchronous replication slave, and he has discovered that if he kills any running SHOW SLAVE STATUS operations when flow control occurs, the flow control condition is recovered nearly instantly.

]]> By: Tim Vaillancourt https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-9065260 Wed, 01 Oct 2014 10:59:13 +0000 https://www.percona.com/blog/?p=15017#comment-9065260 Great, thanks a lot Jay!

]]> By: Jay Janssen https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-9047585 Tue, 30 Sep 2014 14:22:28 +0000 https://www.percona.com/blog/?p=15017#comment-9047585 @Tim: Yes, ‘set global wsrep_provider_options=”gcs.fc_limit=1024″‘, for example. Note that these won’t take effect if the node is IN flow control when you set them — i.e., if the node is stuck and it already has a large wsrep_local_recv_queue, they will apply the *next* time a FC calculation is done.

Note that even the default allows nodes to be at least 16 transactions behind in applying. If you want everything “caught up”, you probably want to check out wsrep_causal_reads (and now its replacement, wsrep_sync_wait https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_sync_wait)

]]> By: Tim Vaillancourt https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-8955025 Thu, 25 Sep 2014 15:22:19 +0000 https://www.percona.com/blog/?p=15017#comment-8955025 Thanks for this great article Jay.

Is it possible to change the gcs.fc_limit and gcs.fc_master_slave variables dynamically?

I was hoping I could write to just 1 node in a cluster (and increase the flow control + set fc_master_slave=YES) but if I were failing over to a different node I could drop back to defaults to ensure the nodes are completely “caught up” ONLY during the fail-over. Is that possible?

Thanks!

Tim

]]> By: Anthony Somerset https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-1737957 Tue, 14 May 2013 11:04:17 +0000 https://www.percona.com/blog/?p=15017#comment-1737957 Thanks the data_backup link was exactly what i needed 🙂 just had to adapt and rename my script and it works

]]> By: Raghavendra https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-1737819 Tue, 14 May 2013 09:36:54 +0000 https://www.percona.com/blog/?p=15017#comment-1737819 Filed https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1179805 for above.

]]> By: Raghavendra https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-1737474 Tue, 14 May 2013 05:40:53 +0000 https://www.percona.com/blog/?p=15017#comment-1737474 @Jay, @Anthony:

There is a variable for this — wsrep_sst_donor_rejects_queries
— from https://www.percona.com/doc/percona-xtradb-cluster/wsrep-system-index.html

However, its value is checked only during SST, I think it
shouldn’t take more work to make it work elsewhere as well.

Is this something which will be useful?

]]> By: Jay Janssen https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-1736718 Mon, 13 May 2013 20:10:48 +0000 https://www.percona.com/blog/?p=15017#comment-1736718 Anthony, that’s an excellent question. The supported method is to use the Galera arbitration daemon and you can find documentation on that here:

http://www.codership.com/wiki/doku.php?id=data_backup

This is a good topic for a followup blog post, stay tuned…

]]> By: Anthony Somerset https://www.percona.com/blog/galera-flow-control-in-percona-xtradb-cluster-for-mysql/#comment-1736303 Mon, 13 May 2013 12:51:22 +0000 https://www.percona.com/blog/?p=15017#comment-1736303 seems i was caught out by this when running a mysqldump on a particularly large database the other day…

is there anyway to manually set Donor/Desynced status and to exit the State so that manual mysqldumps can be run for other reasons – much akin to doing a stop slave/start slave in traditional mysql replication setups?

]]>