[MDEV-20045] Galera MariaDB cluster is missing "bind-address" system variable? (UPDATE: No, that system var is not available until 10.3.3 ) Created: 2019-07-11  Updated: 2019-07-21  Resolved: 2019-07-21

Status: Closed
Project: MariaDB Server
Component/s: Variables
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Trivial
Reporter: brianr Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

6 node cluster mix of Ubuntu/Centos7, mariadb 10.2.24 (all in Vbox 5.30 on a WIndows 10 machine, Testenvironment)

Attachments: Text File bind-adress_missing.txt    

 Description   

I have been trying to reinstall ClusterControl(CC) (Severalnines) and discovered that when CC is asked to re-import the clusterinformation, it will try to find the "bind-.address" from the nodes. It fails, because bind-address is not found.

I can verify, loggging on to any of the Ubuntu servers, and "show global variables like '%bind% will return nothing?

I have tried entering wrong info deliberately into the .cnf file, and when doing so, mariadb refuse to start. When setting bind-address=[correct IP address], mariadb starts up fine and joins cluster. But it will not show any variables called bind-address/bind_address.
It does show the wsrep_node_address, though. are those two by any chance "mutually exclusive", with wsrep replacing the bind-address?

I hope someone can suggest where I can check to see what I might have done wrong...



 Comments   
Comment by brianr [ 2019-07-17 ]

Oops.

I think this can be safely closed again.
The software I used, which made me suggest that this system variable is missing, apparently was unaware (as was I), that this bind_address was not introduced as system variable until MariaDB 10.3.3.
I'm using 10.2.24 (and their software), so bind-.address is just not available to me (or them) and they must find the information elsewhere.

Case closed

Comment by brianr [ 2019-07-17 ]

I give up, trying to decipher how this is closed again ...

Generated at Thu Feb 08 08:56:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.