Bug #95531 | mysql router fails to connect to cluster | ||
---|---|---|---|
Submitted: | 25 May 2019 9:51 | Modified: | 9 Jul 2019 19:34 |
Reporter: | Crt Zerjal | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Router | Severity: | S1 (Critical) |
Version: | 8.0.16 | OS: | Debian |
Assigned to: | Andrzej Religa | CPU Architecture: | x86 |
[25 May 2019 9:51]
Crt Zerjal
[28 May 2019 6:08]
MySQL Verification Team
Hi, Can you give me your router config file? thanks Bogdan
[28 May 2019 12:56]
Crt Zerjal
mysqlrouter.conf # File automatically generated during MySQL Router bootstrap [DEFAULT] user=mysqlrouter logging_folder=/var/log/mysqlrouter/ runtime_folder=/var/run/mysqlrouter/ data_folder=/etc/mysqlrouter/data keyring_path=/etc/mysqlrouter/data/keyring master_key_path=/etc/mysqlrouter/mysqlrouter.key connect_timeout=15 read_timeout=30 dynamic_state=/etc/mysqlrouter/data/state.json [logger] level = DEBUG [metadata_cache:farm] router_id=1 user=mysql_router1_8je03205g8a4 metadata_cluster=farm ttl=0.5 [routing:farm_default_rw] bind_address=0.0.0.0 bind_port=6446 socket=/var/run/mysqlrouter/mysql.sock destinations=metadata-cache://farm/default?role=PRIMARY routing_strategy=first-available protocol=classic [routing:farm_default_ro] bind_address=0.0.0.0 bind_port=6447 socket=/var/run/mysqlrouter/mysqlro.sock destinations=metadata-cache://farm/default?role=SECONDARY routing_strategy=round-robin-with-fallback protocol=classic [routing:farm_default_x_rw] bind_address=0.0.0.0 bind_port=64460 socket=/var/run/mysqlrouter/mysqlx.sock destinations=metadata-cache://farm/default?role=PRIMARY routing_strategy=first-available protocol=x [routing:farm_default_x_ro] bind_address=0.0.0.0 bind_port=64470 socket=/var/run/mysqlrouter/mysqlxro.sock destinations=metadata-cache://farm/default?role=SECONDARY routing_strategy=round-robin-with-fallback protocol=x
[5 Jun 2019 21:21]
MySQL Verification Team
How did you generate this config? What parameters did you give to mysqlrouter --bootstrap ? I'm having issue reproducing this behavior thanks
[6 Jun 2019 7:08]
Crt Zerjal
hi, this is the comand that generated those configs mysqlrouter --bootstrap localhost:33061 --directory /etc/mysqlrouter --conf-use-sockets --user=mysqlrouter i just changed the configuration of the paths for sockets is it possible to change the cluster config to store ips instead of hostnames? I suspect that mysqrouter thinks that my hostnames are ipv6 addresses thanks
[6 Jun 2019 10:07]
MySQL Verification Team
Hi, Let me check about ip addresses. As for the ipv6, maybe that's why I could not reproduce, I have disabled ipv6 support on my test gear. Lemme retest and get back
[6 Jun 2019 11:28]
MySQL Verification Team
Hi, Bug is verified, I discussed with a dev team and they'll try to push a fix in .17 thanks Bogdan
[5 Jul 2019 14:54]
lionel mazeyrat
is there a workaround for 8.0.16 to use IPV4 adresses instead of host name ?
[6 Jul 2019 8:25]
Crt Zerjal
if you don't use ipv6 disabling it will make the router work
[9 Jul 2019 19:34]
Philip Olson
Posted by developer: Fixed as of the upcoming MySQL Router 8.0.17 release, and here's the changelog entry: Bootstrapping could misclassify a hostname as IPv6 and surround it with square brackets in the state (state.json) file; and this produced a "Configuration error: cluster-metadata-servers is incorrect" error. A workaround was to disable ipv6 support on the system. Thank you for the bug report and detailed information!
[11 Jul 2019 14:27]
lionel mazeyrat
windows server 2016 - Mysql 8.0.16 I've tried the workaround, IPV6 desactivated, but when I stop/restart mysql router, the service don't restart and I need to suppress the backet in state.json. Is it usefull to re-install or re-configure mysqlrouter service ? { "metadata-cache": { "group-replication-id": "7321120a-9cd1-11e9-9bef-000c29fa29be", "cluster-metadata-servers": [ "mysql://TVG-GTCHIS:3306", "mysql://[TVG-GTC01]:3306", "mysql://TVG-GTC02:3306" ] }, "version": "1.0.0" }
[11 Jul 2019 15:09]
MySQL Verification Team
Hi, since the fix is already in .17 please try it as soon as it's out. Thanks Bogdan p.s. according to your test of a workaround looks like windows did not completely disabled ipv6