Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-10971

Server accepts invalid wsrep_cluster_address

    XMLWordPrintable

    Details

      Description

      Let's say that I have the following wsrep_cluster_address value in my configuration file:

      wsrep_cluster_address="gcomm://node1,gcomm://node2"
      

      The above is incorrect syntax. With wsrep_cluster_syntax, this would probably be interpreted as the following 2 addresses:

      1.) node 1 with the default port

      2.) gcomm with //node2 as the port.

      "//node2" is obviously an invalid port number, but MariaDB and Galera seem to ignore it and use the default. Does the server perform any validation of wsrep_cluster_address? It might be helpful to log an error or warning if the syntax of wsrep_cluster_address is not correct.

      Here is a log of MariaDB 10.1 trying to use the invalid wsrep_cluster_address:

      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Read nil XID from storage engines, skipping position init
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so'
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: wsrep_load(): Galera 25.3.17(r3619) by Codership Oy <info@codership.com> loaded successfully.
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: CRC-32C: using hardware acceleration.
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Found saved state: 85986e28-751b-11e6-9463-a6e1d8fbecf5:-1
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 172.31.19.192; base_port = 4567; cert.log_conflicts = no; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; 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; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; 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.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false
      2016-10-06 16:30:56 140029143308032 [Note] WSREP: Service thread queue flushed.
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: wsrep_sst_grab()
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Start replication
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: protonet asio version 0
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: Using CRC-32C for message checksums.
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: backend: asio
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: gcomm thread scheduling priority set to other:0
      2016-10-06 16:30:56 140029375895680 [Warning] WSREP: access file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory)
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: restore pc from disk failed
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: GMCast version 0
      2016-10-06 16:30:56 140029375895680 [Warning] WSREP: Failed to resolve tcp://node1:4567
      2016-10-06 16:30:56 140029375895680 [Warning] WSREP: Failed to resolve tcp://gcomm:4567
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: (c8de7e3c, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: (c8de7e3c, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: EVS version 0
      2016-10-06 16:30:56 140029375895680 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer 'node1:,gcomm:'
      2016-10-06 16:30:56 140029375895680 [ERROR] WSREP: failed to open gcomm backend connection: 131: No address to connect (FATAL)
               at gcomm/src/gmcast.cpp:connect_precheck():282
      2016-10-06 16:30:56 140029375895680 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():208: Failed to open backend connection: -131 (State not recoverable)
      2016-10-06 16:30:56 140029375895680 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1380: Failed to open channel 'my_wsrep_cluster' at 'gcomm://node1,gcomm://node2': -131 (State not recoverable)
      2016-10-06 16:30:56 140029375895680 [ERROR] WSREP: gcs connect failed: State not recoverable
      2016-10-06 16:30:56 140029375895680 [ERROR] WSREP: wsrep::connect(gcomm://node1,gcomm://node2) failed: 7
      2016-10-06 16:30:56 140029375895680 [ERROR] Aborting
      

        Attachments

          Activity

            People

            Assignee:
            jplindst Jan Lindström
            Reporter:
            GeoffMontee Geoff Montee
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: