Resources added to the configuration file are neither being loaded to runtime nor saved to disk

[tullis]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10.9 (PC1)
• Ruby: 2.1.5p273
• Distribution: Debian Jessie (amd64)
• Module version: 2.0.0

How to reproduce (e.g Puppet code you use)

Apply the module via profile, with resources defined in hiera.

class profile::proxysql (

  $proxysql_admin_password = lookup(proxysql::admin_password),
  $proxysql_monitor_password = lookup(proxysql::monitor_password)
)
{

  class { '::proxysql':
    admin_password   => Sensitive($proxysql_admin_password),
    monitor_password => Sensitive($proxysql_monitor_password),
  }
}

Sample of hiera data:

proxysql::admin_password: ReallySecretPassword
proxysql::monitor_password: MumsTheWord
proxysql::override_config_settings:
  mysql_servers:
    sql1:
      address: 10.0.0.1
      port: 3306
      hostgroup: 0
    sql2:
      address: 10.0.0.2
      port: 3306
      hostgroup: 0
proxysql::package_ensure:  1.4.10

I have not specified the proxysql::load_to_runtime parameter in hiera, because it defaults to true.

What are you seeing

The config file /etc/proxysql.cnf is correctly written.

The in-memory database is not updated.

The runtime database is not updated.

In order to effect any change, I have to execute the following in the ProxySQL admin console:

Admin> load mysql servers from config;
Admin> load mysql servers to runtime;

The observation is the same with other resources such as the scheduler, mysql users, mysql query rules and so on.

What behaviour did you expect instead

I expected to see the resources being saved to the configuration file and then immediately loaded to runtime during the puppet run.

[tullis]

I have also that the resources are not being saved to disk either, so after making a change to the configuration, not only do I have to run:

Admin> load mysql servers from config;
Admin> load mysql servers to runtime;

...but I also have to run:

Admin> save mysql servers to disk;

[tullis]

I see that the problem here is my using the proxysql::override_config_settings: hash to define the resources in the configuration file.

If I create the resources directly, using either the defined types or in hiera using the syntax:

proxysql::mysql_servers:
  sql1:
    address: 10.0.0.1
    port: 3306
    hostgroup: 0
  sql2:
    address: 10.0.0.2
    port: 3306
    hostgroup: 0

...then the resources are created, loaded to runtime, saved to the sqlite database, but they do not appear in the configuration file /etc/proxysql.cnf.

Would it not be beneficial to keep the configuration file in sync with the resources, and vice versa?

[amateo]

I'm not completely sure if this is the same problem, but I have a similar issue.

I have this hiera:

proxysql::admin_listen_socket: ''
proxysql::listen_socket: ''

which creates this /etc/proxysql.conf:

admin_variables = {
    ...
    mysql_ifaces = "127.0.0.1:6032;"
}

mysql_variables = {
    interfaces = "0.0.0.0:6033;"
    ...
}

This config is running, but now I want to add support for IPv6. As listen_ip does not support IPv6 configuration (the interfaces options is created with interfaces => "${listen_ip}:${listen_port};${listen_socket}") I have added the IPv6 in the listen_socket parameter, as this in hiera:

proxysql::listen_socket: '[::]:6033'

With this hiera, then /etc/proxysql.conf is correctly created:

admin_variables = {
    ...
    mysql_ifaces = "127.0.0.1:6032;"
}

mysql_variables = {
    interfaces = "0.0.0.0:6033;[::]:6033"
    ...
}

The problem is that this config is not propagated to runtime.
I have checked the code at proxysql::reload_config which run:

LOAD ADMIN VARIABLES FROM CONFIG; \
LOAD ADMIN VARIABLES TO RUNTIME; \
SAVE ADMIN VARIABLES TO DISK; \
LOAD MYSQL VARIABLES FROM CONFIG; \
LOAD MYSQL VARIABLES TO RUNTIME; \
SAVE MYSQL VARIABLES TO DISK; \"

and manually run it. What I have checked is that when you run LOAD MYSQL VARIABLES FROM CONFIG; then the interfaces option is correctly updated in global_variables table (but not runtime table runtime_global_variables), but when you run LOAD MYSQL VARIABLES TU RUNTIME; then, instead of loading configuration to runtime_global_variables then global_variables is reset to configuration without IPv6 configuration.

So this new config is never loaded in runtime.

Any help? Is this a bug of the module? Or a bug in proxysql?

[alexjfisher]

@amateo - mysql-interfaces is one of only 3 variables that can't be updated at runtime. See here.

If you need to change this configuration value, you need to restart proxysql. You can use restart => true for this.

[bassonj]

We are also experiencing this problem

A Puppetrun output shows us that the file is being changed on disk and the reload_config is being triggered

Info: /Stage[main]/Proxysql::Config/File[proxysql-config-file]: Scheduling refresh of Exec[reload-config]
Notice: /Stage[main]/Proxysql::Reload_config/Exec[reload-config]: Triggered 'refresh' from 1 event
Info: Stage[main]: Unscheduling all events on Stage[main]
Notice: Applied catalog in 24.61 seconds

However before any of the settings are applied we have to use the ProxySQL Admin interface and issue the following commands
before the running process is aware of the change.

load mysql servers from config;
save mysql servers to disk;
load mysql servers to runtime;

the same is true for mysql query rules and I suspect users.

It would appear that the problem is that proxysql::reload_config only processes MYSQL and ADMIN variables
where the documentation states:

Moving config between layers

In order to persist configuration to disk or load configuration to runtime there is a set of different admin commands available which can be executed via the admin interface for each configuration item e.g. mysql servers, mysql users, mysql query rules.