Hello everyone, hope you all had a good year, despite the Corona thingy,
We’re thinking about adding a maxscale server (possibly multiple in the future) in our infrastructure.
We have a lot of mariadb servers (all configured in pairs : master and slave).
We have automated the configuration of mariadb servers with Ansible, and we would like to do the same with MaxScale.
Thing is… there’s no reload option for maxscale (I’m using maxscale 2.4.14)? If I add a new pair of mariadb servers, and configure them (along with Monitor, Services, and Listeners) in maxscale.cnf or etc/maxscale.cnf.d/,
I’m forced to do a restart? Isn’t there an alternative?
I guess I can use commands like “maxctrl create XXXXX”, “maxctrl alter XXXXX”, “maxctrl destroy XXXXX” to change the configuration without shutting down maxscale, but this is hardly automatable.
Also, there’s no way to alter a listener? I’m forced to destroy and then create one?
Regards,
--
Erwin
Hi,
Currently runtime changes to MaxScale are done via maxctrl,
similar to how runtime changes are done in MariaDB via the SQL
interface. If you could expand on your use-case a little bit,
perhaps we can find a solution for it with the tools that are
currently available or come up with a new feature that would solve
it in the future. If you want the reload functionality to be added
as a feature, you can file a new feature request on the MariaDB Jira
under the MaxScale project.
Alteration of listeners is going to be in MaxScale 2.6 as
implementing it required some fundamental changes in the listener
configuration implementation. You should be able to configure most
everything without having to destroy and recreate the listener.
The current limitations for what cannot be changed are found here
(an end-user facing document should be
written for this)
Markus
--
You received this message because you are subscribed to the Google Groups "MaxScale" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maxscale+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/CANDQcQ2BSXxbzZYUgi5mfVwX%2B28gZ0Qewve7uHxqsLaKnMby8g%40mail.gmail.com.
-- Markus Mäkelä, Senior Software Engineer MariaDB Corporation
Hi,
Thanks for explaining your use case, this clarifies what you're attempting to do with MaxScale. Currently there's no way to have MaxScale re-read the configuration files which means the only way to achieve what you want is to use either MaxCtrl or the REST API directly.
Markus
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/6a6ddf26-c59e-4c0d-b5f1-9ee788817b83n%40googlegroups.com.
Hi,
I think people haven't actively requested in the recent years now that the runtime modification of MaxScale is doable with MaxCtrl.
As for whether it'll be considered for a new feature, I can't really say. We need to evaluate whether this is a feature that's truly needed and that it meshes with existing features. Having multiple ways of doing the same thing is not efficient nor is it maintainable.
New major features won't be added to any GA releases of MaxScale
and this would count as one. I wouldn't expect to see a new
MaxScale major release in the next few months.
Markus
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/e7bca091-ad5f-4692-b9e2-b9a376ede15an%40googlegroups.com.
31 дек. 2020 г., в 15:15, Markus Mäkelä <markus...@mariadb.com> написал(а):
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/74b56274-fb3c-db62-1cdb-6541b9aaa062%40mariadb.com.
Hi,
2) Notice the "type=listener" appears twice? This doesn't seem to bother maxscale however
That looks like it might be a double addition of the type parameter at the time the listener is serialized. Based on the fact that it works, it's most likely ignored by the configuration parsing code.
I'll look into fixing this even if it works correctly now. It
looks like a thing that's bound to cause problems in the future.
3) "authenticator_options" is empty, I tried multiple things to make "lower_case_table_names=true" appear, but nothings ever happens, what am I doing wrong?I can fill the void, so that the line becomes :authenticator_options=lower_case_table_names=trueAnd then restart the service. This works, but then again... I'm restarting the service, and I need to avoid that, I'm obligated to use this options or else some of our tools don't work...
This does seem like it's a bug and I took a look at the 2.4 maxctrl code and it does indeed seem to be a bug in it. I've filed MXS-3360 for this and it should be fixed in the next releases of MaxScale.
Thanks for reporting these problems!
Markus
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/9E2B227C-1FAE-4441-BB2B-AF1310E39ED5%40gmail.com.
--
Wagner Bianchi, MariaDB RDBA Team Email: bia...@mariadb.com
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/CA%2B%2Boe7TGrQRTywKGpUVL-mOoMeQofOz22h8dz_UjVNJF4qBobQ%40mail.gmail.com.
Thing is… there’s no reload option for maxscale (I’m using maxscale 2.4.14)? If I add a new pair of mariadb servers, and configure them (along with Monitor, Services, and Listeners) in maxscale.cnf or etc/maxscale.cnf.d/, I’m forced to do a restart? Isn’t there an alternative?
[maxscale]
threads = auto
log_augmentation = 1
ms_timestamp = 1
syslog = 1
writeq_high_water = 32M
writeq_low_water = 512K
[rwsplit-service]
type = service
router = readwritesplit
user = maxusr
password = <add your encrypted maxusr password here>
max_sescmd_history = 500
prune_sescmd_history = true
master_reconnection = true
master_failure_mode = fail_on_write
Also, there’s no way to alter a listener? I’m forced to destroy and then create one?
--
Wagner Bianchi, MariaDB RDBA Team Email: bia...@mariadb.com
To view this discussion on the web, visit https://groups.google.com/d/msgid/maxscale/acb00b65-fe56-493f-a564-50d8066fb186n%40googlegroups.com.