# wsrep\_max\_ws\_rows exceeded errors **URL:** \ **Category:** Percona XtraDB Cluster 5.x\ **Created:** [October 5, 2016, 2:13pm UTC](https://forums.percona.com/t/wsrep-max-ws-rows-exceeded-errors/5129 "2016-10-05T14:13:29Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Philio](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/philio/32/1000_2.png) [@Philio](https://forums.percona.com/u/Philio)\ **Post date:** [October 5, 2016, 2:13pm UTC](https://forums.percona.com/t/wsrep-max-ws-rows-exceeded-errors/5129/1 "2016-10-05T14:13:29Z")
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 [https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html](https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html) > [@](#): > > variable wsrep\_max\_ws\_rows > > This variable has no effect! > > By design, it was supposed to control the maximum number of rows each writeset can contain. However, it is hard to predict the number of rows because of the writeset size limit enforced by [wsrep\_max\_ws\_size](https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_max_ws_size). > > Codership decided to not implement the limit by rows for now. Correct behavior may be implemented in a future release. There is a discussion open at [https://github.com/codership/mysql-wsrep/issues/257](https://github.com/codership/mysql-wsrep/issues/257) How is a variable that is supposed to control rows in a writeset but actually doesn’t do anything affect SELECT queries? ---
**Author:** ![Philio](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/philio/32/1000_2.png) [@Philio](https://forums.percona.com/u/Philio)\ **Post date:** [October 6, 2016, 4:38pm UTC](https://forums.percona.com/t/wsrep-max-ws-rows-exceeded-errors/5129/2 "2016-10-06T16:38:04Z")
We upgraded to the new 5.7 release today, same issue. ---
**Author:** ![plentyza](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/plentyza/32/1144_2.png) [@plentyza](https://forums.percona.com/u/plentyza)\ **Post date:** [October 10, 2016, 3:35am UTC](https://forums.percona.com/t/wsrep-max-ws-rows-exceeded-errors/5129/3 "2016-10-10T03:35:04Z")
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 [URL=“[Announcing Galera Cluster 5.5.50 and 5.6.31 with Galera 3.17 | Galera Cluster for MySQL](http://galeracluster.com/2016/08/announcing-galera-cluster-5-5-50-and-5-6-31-with-galera-3-17/)”][http://galeracluster.com/2016/08/ann...h-galera-3-17/[/URL]](http://galeracluster.com/2016/08/ann...h-galera-3-17/%5B/URL%5D) ---
**Author:** ![Philio](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/philio/32/1000_2.png) [@Philio](https://forums.percona.com/u/Philio)\ **Post date:** [October 14, 2016, 8:06pm UTC](https://forums.percona.com/t/wsrep-max-ws-rows-exceeded-errors/5129/4 "2016-10-14T20:06:24Z")
I set my my.cnf to the defaults as specified on that page and it seems to work fine now. [LIST] [_]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. [/LIST]