XtraDB cluster doesn't check the parameters of wsrep_provider_options

Bug #1260193 reported by Miguel Angel Nieto on 2013-12-12
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Galera
Status tracked in 3.x
2.x
High
Alex Yurchenko
3.x
High
Alex Yurchenko
Percona XtraDB Cluster
Status tracked in 5.6
5.5
Undecided
Unassigned
5.6
Undecided
Unassigned

Bug Description

You can configure any value you want on wsrep_provider_options, even values that don't exist or are not documented and PXC won't try to check it. That could cause confusion or even problems if there is some mistake on that parameter. Tested with latest 5.5 PXC:

wsrep_provider_options = "wathever=1"

| wsrep_provider_options | base_host = 10.0.2.15; base_port = 4567; cert.log_conflicts = no; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT15S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 1; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 0; evs.view_forget_timeout = PT5M; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; gmcast.listen_addr = tcp://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.time_wait = PT5S; gmcast.version = 0; ist.recv_addr = 10.0.2.15; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.version = 0; pc.weight = 1; protonet.backend = asio; protonet.version = 0; replicator.causal_read_timeout = PT30S; replicator.commit_order = 3; wathever = 1 |

Related branches

lp:galera
David Bennett: Pending requested 2014-07-25
tags: added: i37640
Alex Yurchenko (ayurchen) wrote :

This requires some investigation. Galera is supposed to return an error on an unrecognised parameter. Technically in this case provider should fail to initialize.

If the parameter is set at runtime, Galera returns 'Unknown
parameter' to stderr and also "ERROR 1210 (HY000): Incorrect
arguments to SET" to client.

However, this checking is not done at init.

wsrep_set_params called in galera_init has checking for unknown
parameters. However,

galera::ReplicatorSMM::param_set:

    try
    {
        if (config_.get(key) == value) return;
    }
    catch (gu::NotFound&) {}

applies to all provided options (even base_host). So, rest of the
function is bypassed.

This is because they (the config_ map) are initialised earlier in
gu::Config::parse where there is no checking of keys.

Since gu::Config::parse itself doesn't know about parameters to
distinguish between in/valid parameters, right step here would
be to initialise map with compile-time values (as is done in
galera::ReplicatorSMM::ReplicatorSMM for others), and not to add any
new keys in gu::Config::parse but to throw exception when there is a
new key. , ie. move gu::Config::parse to a latter stage after initialisation of config_ map with compile time values.

Alex Yurchenko (ayurchen) wrote :

Heh, looks like that. Which effectively complicates the configuration code by a factor of two. Needs more thinking.

Alex Yurchenko (ayurchen) wrote :

Question to all concerned:
Currently wsrep_provider_options only shows options that are in use. E.g. if SSL is not configured, available SSL-related options won't be displayed. Should it stay this way or display ALL options (which might be close to 50) ?

On Dec 15, 2013, at 8:45 PM, Alex Yurchenko <email address hidden> wrote:

> Currently wsrep_provider_options only shows options that are in use. E.g. if SSL is not configured, available SSL-related options won't be displayed. Should it stay this way or display ALL options (which might be close to 50) ?

I often use SHOW GLOBAL VARIABLES as a way to see *what* to tune (or at least to remind me what I *could* tune). Hiding variables means that the authoritative list of variables must be in the documentation.

wsrep_provider_options is already unwieldy, I’m not sure turning off hiding will make it any worse really. I guess I vote they all be shown.

Jay Janssen, MySQL Consulting Lead, Percona
http://about.me/jay.janssen

Since all wsrep-provider-options are logged to error log as:

131230 21:10:54 [Note] WSREP: Passing config to GCS: base_host = 127.0.0.1; base_port = 4567; cert.log_conflicts = no; gcache.dir = /pxc/datadir/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /pxc/datadir//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; gmcast.listen_addr = tcp://127.0.0.1:4010; replicator.causal_read_timeout = PT30S; replicator.commit_order = 3

I think it should be fine to show only the options explicitly set
(either at startup or runtime).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers