XtraDB cluster doesn't check the parameters of wsrep_provider_options

Bug #1260193 reported by Miguel Angel Nieto
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Galera
Status tracked in 3.x
2.x
Fix Released
High
Alex Yurchenko
3.x
Fix Released
High
Alex Yurchenko
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Status tracked in 5.6
5.5
Fix Released
Undecided
Unassigned
5.6
Fix Released
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 |

Tags: i37640
tags: added: i37640
Revision history for this message
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.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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.

Revision history for this message
Alex Yurchenko (ayurchen) wrote :

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

Revision history for this message
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) ?

Revision history for this message
Jay Janssen (jay-janssen) wrote : Re: [Bug 1260193] XtraDB cluster doesn't check the parameters of wsrep_provider_options

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

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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).

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1551

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.