[MXS-3001] maxctrl does not persists dynamic changes for writeq_high_water and writeq_low_water Created: 2020-05-20  Updated: 2020-05-21  Due: 2020-05-20  Resolved: 2020-05-21

Status: Closed
Project: MariaDB MaxScale
Component/s: maxctrl
Affects Version/s: 2.4.8
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Wagner Bianchi (Inactive) Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: maxctrl
Environment:

CentOS Linux release 7.6.1810 (Core)


Issue Links:
Duplicate
duplicates MXS-3000 Not all global parameters are serialized Closed

 Description   

I'm updating the global maxscale configurations writeq_high_water and writeq_low_water with maxctrl dynamic commands, expecting to have new values configured for those both variables persisted at the --persistdir. I already have a global-options.cnf file there.

[BIANCHI LABS] root@opmxs01: ~ # systemctl restart maxscale.service
[BIANCHI LABS] root@opmxs01: ~ # maxscale --version
MaxScale 2.4.8
[BIANCHI LABS] root@opmxs01: ~ # maxctrl show maxscale | grep "writeq"
│              │     "writeq_high_water": 0,                                  │
│              │     "writeq_low_water": 0,                                   │
And then, I issued below commands:
[BIANCHI LABS] root@opmxs01: ~ # maxctrl alter maxscale writeq_high_water 32Mi
OK
[BIANCHI LABS] root@opmxs01: ~ # maxctrl alter maxscale writeq_low_water 512Ki
OK

Ok, checking maxscale global configurations:

[BIANCHI LABS] root@opmxs01: ~ # maxctrl show maxscale | grep "writeq"
│              │     "writeq_high_water": 33554432,                           │
│              │     "writeq_low_water": 524288,                              │

Checking the --persistdir :

[BIANCHI LABS] root@opmxs01: ~ # ls -lh /var/lib/maxscale/maxscale.cnf.d/*
-rw-r--r--. 1 maxscale maxscale 101 May 19 18:28 /var/lib/maxscale/maxscale.cnf.d/global-options.cnf
[BIANCHI LABS] root@opmxs01: ~ # cat /var/lib/maxscale/maxscale.cnf.d/global-options.cnf
[maxscale]
auth_connect_timeout=3
auth_read_timeout=1
auth_write_timeout=2
admin_auth=true
passive=0

Is it expected to not persist those configurations? More interesting yet is that if I change the passive mode from false to true , it persists it:

[BIANCHI LABS] root@opmxs01: ~ # maxctrl alter maxscale passive true
OK
[BIANCHI LABS] root@opmxs01: ~ # cat /var/lib/maxscale/maxscale.cnf.d/global-options.cnf
[maxscale]
auth_connect_timeout=3
auth_read_timeout=1
auth_write_timeout=2
admin_auth=true
passive=1

It is, maybe, something to take a look?

[BIANCHI LABS] root@opmxs01: ~ # ls -lh /var/lib/maxscale/maxscale.cnf.d/
total 4.0K
-rw-r--r--. 1 maxscale maxscale 101 May 19 18:37 global-options.cnf
[BIANCHI LABS] root@opmxs01: ~ # cat /var/lib/maxscale/maxscale.cnf.d/global-options.cnf
[maxscale]
auth_connect_timeout=3
auth_read_timeout=1
auth_write_timeout=2
admin_auth=true
passive=1
[BIANCHI LABS] root@opmxs01: ~ # maxctrl show maxscale | grep "writeq"
│              │     "writeq_high_water": 32000000,                           │
│              │     "writeq_low_water": 512000,                              │
[BIANCHI LABS] root@opmxs01: ~ # systemctl restart maxscale.service
[BIANCHI LABS] root@opmxs01: ~ # maxctrl show maxscale | grep "writeq"
│              │     "writeq_high_water": 0,                                  │
│              │     "writeq_low_water": 0,                                   │

Thanks, folks!



 Comments   
Comment by markus makela [ 2020-05-21 ]

I'll close this as a duplicate, I happened to already file MXS-3000 for the issue. I'll list all affected parameters there.

Generated at Thu Feb 08 04:18:13 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.