wsrep_max_ws_rows exceeded errors

Our cluster appears to have auto-updated last night and since then we’re getting errors relating to wsrep_max_ws_rows.

The odd thing is that they seem to be related to SELECT queries.

Here is an example (it’s an auto-generated query executed by Apigility):

SELECT COUNT(1) AS C FROM (SELECT sms_log.* FROM sms_log) AS original_select

Error Code: 1180. wsrep_max_ws_rows exceeded

The table has about 20 million rows, we have the default 128k value for wsrep_max_ws_rows.

Increasing the value of wsrep_max_ws_rows to an incredibly big number solves the problem.

However, according to

How is a variable that is supposed to control rows in a writeset but actually doesn’t do anything affect SELECT queries?

We upgraded to the new 5.7 release today, same issue.

After upgrading our cluster this weekend we are having the same issue.

Increasing the value of wsrep_max_ws_rows to an incredibly big number solves it for us too.

Cant find any reference to this var in any of the change logs to date.

we went from Percona 5.6.26-74.0 to Percona 5.6.32-78.1
And the latest Galera replicator from the repo’s

mysqld Ver 5.6.32-78.1-56 for debian-linux-gnu on x86_64 (Percona XtraDB Cluster (GPL), Release rel78.1, Revision 979409a, WSREP version 25.17, wsrep_25.17)

I have traced this issue down to this recent release of Galera…h-galera-3-17/

I set my my.cnf to the defaults as specified on that page and it seems to work fine now.
[]The wsrep_max_ws_rows variable has been fixed and can be used to set the maximum number of rows a transaction can update, delete or insert. The new default value is 0, meaning no limit.
]The wsrep_max_ws_size variable and the repl.max_ws_size wsrep provider option have been linked together. The new wsrep_max_ws_size default is 2Gb.