[BUG] Can't connect to MySQL server using host and port.

[speller]

Mydumper doens't respect --host and --port settings and always tries to connect by MySQL socket:

$ mydumper --host localhost --port 3306

** (mydumper:29656): CRITICAL **: 12:03:25.362: Error connecting to database: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

[davidducos]

Hi @speller, did you try with 127.0.0.1 ??

[peterquiel]

Same issue and worked with local ip address.

Would be cool to support localhost or to add a hint to the error message.

[davidducos]

Hi @peterquiel, this is not a MyDumper issue, this is related to MySQL library which use the socket when localhost is used. I think that the error message is clear: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) and the (2) means:

➜ perror 2
OS error code   2:  No such file or directory

[speller]

@davidducos I would disagree here. The user intended to connect to localhost but they see an irrelevant (from the user's perspective) misleading error message. The user did not ask the tool to connect by sockets. If I pass a network address I want it to connect by TCP. If the tool internally decides to ignore this intention and use sockets, it's the tool's problem, not mine. And I as a user don't care why it happens and what underlying libraries are responsible for this.

[davidducos]

Hi @speller ,
A small correction of your previous message, you say that you "pass a network address" but "localhost" it is not a network address, it is a hostname. If you use any network address, then MySQL will activate the TCP protocol.
On my previous message, I had the intention of explain the root cause of the issue. Again, but with more context, it's not MyDumper faults to use the vendors library, neither that the library has a way of doings thing for more than 15 years and that they didn't acknowledge there is a problem to fix: https://bugs.mysql.com/bug.php?id=31577.
I understand that you consider this as a problem, but you should address it to MySQL, as the solution on MyDumper side would be to check if -h is an ip, if not resolve it, and then connect. This might end up in performance issues to other users as they will stop using socket and start using tcp.
BTW, if you are connecting to localhost, why don't you use the socket? You get better performance: https://www.percona.com/blog/need-to-connect-to-a-local-mysql-server-use-unix-domain-socket/

[peterquiel]

@speller Agree, on a high level, and a perfect world ;-)

Seriously, if this was a tool I have to pay for, I would expect this to be handled .. let's say better.
But this is a free tool. It's a gift, and it helps me very much.

Dumped a 12GB database yesterday within minutes and the constraint was bandwidth. Fast, reliable, works, helps!

[speller]

@davidducos sorry, wrong wording. As from the user perspective, hostname and network address are very close in the meaning, almost synonyms. At the same time, when I write the host parameter, I expect it will accept the localhost as the hostname.

I understand the root cause, but what if adding a simple workaroung and substitute the localhost with 127.0.0.1? If this is the only case when the issue happens, then this is a legitimate fix. A warning can be printed to catch user's attention to this.

The reason why I need localhost is because I'm running databases in a docker container and exposing ports to the localhost, so no sockets available. I also may setup an ssh tunnel to a remote database that has no public network access. It will also open a port on the local machine with no sockets available.

Anyways, I'm not trying to say that something wrong with the tool. Sorry if I was rude. I'm appreciated a lot for it. This is a great tool essential for dealing with large datasets. It does its work perfectly! Just wanted a small fix that will not drop a tint on it when you just start using it and is not aware of this issue. The issue is counter-intuitive and the error message doesn't clarify why it doesn't work with localhost.

[davidducos]

Hi @speller,
Ah, you have a use case! ok, so you have, let say a "global variable" that is HOST, which is always localhost in your container and it is used everywhere, even when you configure MyDumper. I'm assuming that having HOST and HOST_ADDRESS is not an option here to configure the apps that doesn't allow hostnames.
Ok, on the other side, what will happen if we change it? By default it will use the defaults on the MySQL library, which has a default socket filename and localhost as --host. So, we do the translation localhost->127.0.0.1 users that based on default configuration, are going to complain. So, we are going to start breaking things...
However, I knew that mysql client has a workaround, which is using --protocol=TCP but MyDumper hasn't implemented. Do you think that adding --protocol option to MyDumper will help you to configure it for your use case?

You weren't rude, you were complaining, and it is ok, sometimes it is frustrating. The good thing here, is that you were able to explain what was YOUR problem! now, we can work in a solution.

[speller]

@davidducos I think it will be good to implement the --protocol parameter. But still, this is a workaround.

Imagine if a user has a locally installed database with a socket AND an ssh tunnel to a remote database. And they try to connect to the remote one. Mydumper will effectively ignore host and port settings and connect to a completely different database with no hints or warnings about why it happened. Which is unacceptable from the user's perspective. THIS will break things, not localhost to ip substitution. And this is much worse than some users complaining that the tool stopped connecting to the socket when configured to connect to localhost. There's no issue to document this fix. People should not configure the tool to connect to localhost when they need a socket.

Maybe it is worth forcing the protocol=TCP parameter when the host is configured? Because when users pass the host parameter, they expect a TCP connection.

Not sure what's the default behavior, but does it connect to the socket if the host parameter is not set? Does the socket connection require the localhost value in the host parameter?

[davidducos]

@speller
#1172 updated. We are going to inform the connection protocol that is going to be used to help users to debug this kind of connection issues.

About defaults, according to https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect.html:

The value of host may be either a host name or an IP address. The client attempts to connect as follows:

* If host is NULL or the string "localhost", a connection to the local host is assumed:

  * On Windows, the client connects using a shared-memory connection, if the server has shared-memory connections enabled.

  * On Unix, the client connects using a Unix socket file. The unix_socket argument or the MYSQL_UNIX_PORT environment variable may be used to specify the socket name.

* On Windows, if host is ".", or TCP/IP is not enabled and no unix_socket is specified or the host is empty, the client connects using a named pipe, if the server has named-pipe connections enabled. If named-pipe connections are not enabled, an error occurs.

* Otherwise, TCP/IP is used.

You can also influence the type of connection to use with the MYSQL_OPT_PROTOCOL or MYSQL_OPT_NAMED_PIPE options to [mysql_options()](https://dev.mysql.com/doc/c-api/8.0/en/mysql-options.html). The type of connection must be supported by the server.

That is why I'm not going to change MyDumper default behavior, as I stated on my previous messages.