load mysql_group_replication_hostgroups from the config file

[chatziko]

mysql_replication_hostgroups are loaded from the config file by LOAD MYSQL SERVERS FROM CONFIG. The same should happen for mysql_group_replication_hostgroups.

[renecannao]

Hi @chatziko . Thank you for the report.
Indeed, mysql_group_replication_hostgroups is not loaded from config file, that is correct.
Unless there is a strong reason to support mysql_group_replication_hostgroups from config file, I would prefer to not prioritize it: configuration on Admin should be preferred, as it allows runtime reconfiguration and input validation.

[awakse]

Hi,
I'm running proxysql in a docker container. I have followed the guidelines on how to setup a mysql replication group. I load it to runtime, and save mysql server to disk (0 rows affected) and save mysql variables to disk (84 rows affected).

My problem is that I want to have this config stored in a docker image (not a container), with the possibility to change the mysql servers from a mounted config file. In this scenario I would benefit from defining mysql replication hostgroups in the config file.

Do you have any ideas on how to solve this some other way?

[awakse]

I ended up installing a mysql client via the Dockerfile and executing a sql file from my init script:

echo "Create replication hostgroup"
mysql -u admin -P 6032 -h 127.0.0.1 -p$PROXYSQL_ADMIN_CREDENTIALS_PASS < create_replication_hostgroup.sql

Where create_replication_hostgroup.sql is as simple as:

INSERT INTO mysql_replication_hostgroups VALUES (1,2,'primary replication group');
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL VARIABLES TO DISK;

[aminet]

Hi @renecannao

I'm used to managing configuration with plain text file as I use tools for configuration management like Salt. Table have no "state", you can't diff in a simple way... so SQL is more complex and then much more difficult to use for configuration than plain text file.
About reconfiguration, it's a common practice to send SIGHUP (7) signal to tell the daemon to reload it's configuration. ( --reload is great)
About input validation, yes with SQL orders (insert ...) you have to match the table columns and with a config file you have to parse and check the values but it's up to the user to set the good configuration (and the application to abort on syntax error).

Actually when a configuration change in proxysql.cnf (it append only at the installation), I remove all in datadir (/var/lib/proxysql) and then start proxysql.

[pondix]

If you are making changes only in the config file you will then you can either stop the ProxySQL service and start it with "--initial" (which essentially deletes and re-creates the configuration database) or alternatively run "LOAD ... FROM CONFIG;" in the admin interface during runtime, without stopping the service at all.

Again, using the configuration database as Rene mentioned is encouraged as the first design goal of ProxySQL is "Maximum Uptime".

[pondix]

Fixed in https://github.com/sysown/proxysql/releases/tag/v1.4.9

[aminet]

@pondix : thank you
(in my setup, proxysql run on application server / php server and those servers have an HAProxy in front of them, so breaking the uptime of one application server or proxysql isn't a problem)