Re: [Maria-developers] 0752333: MDEV-10161: wsrep_sync_wait not enabled when set to 1 in config file
Hi, Nirbhay! On Jun 08, Nirbhay Choubey wrote:
revision-id: 075233312cc5bc6c242f4629f8293d4c67937f02 (mariadb-10.1.14-10-g0752333) parent(s): c9f05974e618a869563f2360ef1ca910974a4f1c author: Nirbhay Choubey committer: Nirbhay Choubey timestamp: 2016-06-08 16:03:01 -0400 message:
MDEV-10161: wsrep_sync_wait not enabled when set to 1 in config file
Since wsrep_sync_wait & wsrep_causal_reads variables are related, they are always kept in sync whenever one of them changes. Same is tried on server start, where wsrep_sync_wait get updated based on wsrep_causal_reads' value. But, since wsrep_causal_reads is OFF by default, wsrep_sync_wait's value gets modified and loses its WSREP_SYNC_WAIT_BEFORE_READ bit.
Fixed by giving higher precedence to one that's explicitly set to a non-default value and later to wsrep_sync_wait in case both are set.
diff --git a/sql/wsrep_mysqld.cc b/sql/wsrep_mysqld.cc index d0798ef..fffb0cc 100644 --- a/sql/wsrep_mysqld.cc +++ b/sql/wsrep_mysqld.cc @@ -567,7 +567,39 @@ int wsrep_init()
wsrep_sst_auth_init(wsrep_sst_auth);
- wsrep_causal_reads_update(&global_system_variables); + /* + On server start, there is no way to detect whether the default value + for a system variable was set explicitly by the user. + Now, since wsrep_causal_reads & wsrep_sync_wait are used for same + purpose, a rule of precedence must be defined to keep their values + in sync. It goes as following:
This is wrong. First, in 10.1 there is a way to detect whether the value was set by a user. I_S.SYSTEM_VARIABLES can show that. But even if you'd detected that, it won't help you do distinguish between mysqld --wsrep-sync-wait=1 --wsrep-causal-reads=0 mysqld --wsrep-sync-wait=0 --wsrep-causal-reads=1 The only correct solution is to handle this in the mysqld_get_one_option switch, updating the dependent option when one of these two is set. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Serg,
On Mon, Jun 27, 2016 at 7:38 AM, Sergei Golubchik
Hi, Nirbhay!
On Jun 08, Nirbhay Choubey wrote:
revision-id: 075233312cc5bc6c242f4629f8293d4c67937f02 (mariadb-10.1.14-10-g0752333) parent(s): c9f05974e618a869563f2360ef1ca910974a4f1c author: Nirbhay Choubey committer: Nirbhay Choubey timestamp: 2016-06-08 16:03:01 -0400 message:
MDEV-10161: wsrep_sync_wait not enabled when set to 1 in config file
Since wsrep_sync_wait & wsrep_causal_reads variables are related, they are always kept in sync whenever one of them changes. Same is tried on server start, where wsrep_sync_wait get updated based on wsrep_causal_reads' value. But, since wsrep_causal_reads is OFF by default, wsrep_sync_wait's value gets modified and loses its WSREP_SYNC_WAIT_BEFORE_READ bit.
Fixed by giving higher precedence to one that's explicitly set to a non-default value and later to wsrep_sync_wait in case both are set.
diff --git a/sql/wsrep_mysqld.cc b/sql/wsrep_mysqld.cc index d0798ef..fffb0cc 100644 --- a/sql/wsrep_mysqld.cc +++ b/sql/wsrep_mysqld.cc @@ -567,7 +567,39 @@ int wsrep_init()
wsrep_sst_auth_init(wsrep_sst_auth);
- wsrep_causal_reads_update(&global_system_variables); + /* + On server start, there is no way to detect whether the default value + for a system variable was set explicitly by the user. + Now, since wsrep_causal_reads & wsrep_sync_wait are used for same + purpose, a rule of precedence must be defined to keep their values + in sync. It goes as following:
This is wrong. First, in 10.1 there is a way to detect whether the value was set by a user. I_S.SYSTEM_VARIABLES can show that.
sys_var::value_origin == CONFIG. I wasn't aware of that.
But even if you'd detected that, it won't help you do distinguish between
mysqld --wsrep-sync-wait=1 --wsrep-causal-reads=0 mysqld --wsrep-sync-wait=0 --wsrep-causal-reads=1
The only correct solution is to handle this in the mysqld_get_one_option switch, updating the dependent option when one of these two is set.
Correct. I have committed another one using this approach. http://lists.askmonty.org/pipermail/commits/2016-June/009503.html Thank you. - Nirbhay
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Nirbhay Choubey -
Sergei Golubchik