Continuent Community

Gilles Rayrat wrote:

QUOTE:

Now that I understand your issue better, I don't think there is an easy solution in the connector. Just FYI, here is a snippet of the new version of the doc (not released yet) that explains this user.map problem:

I was a bit afraid it might be something like this. So easiest thing I can do is in user.map like this:
site1/site1pass/dummydb
site2/site2pass/dummydb

And when each database server has same user&passwords, this will work, even if dummydb doesn't exists at target, and native connectors has own database specified? This helps a tiny bit (when same user/pass combo has several databases) I think.

I'll have to rethink my implementation strategy. Bad thing is that there are so many places which has db connector specified, I had hoped tungsten connector to work drop on replacement of mysql in port 3306, catching traffic from there and directing it to right place.

I'm doing great sin doubleposting, but I figured one weird thing about this.

When I have tungsten set up, and even if I haven't done anything to user.map, I can connect from localhost, to local DB.

But it works only if I don't specify host for mysql client:
mysql -u root -p -P 9999 # this works
mysql -u root -p -h localhost -P 9999 # this doesn't work, it tells no entry in user.map
mysql -u root -p -h 127.0.0.1 -P 9999 # this doesn't work, it tells no entry in user.map
mysql -u root -p -h 10.0.x.x -P 9999 # this doesn't work, it tells no entry in user.map (ip being local private interface)

When using that first command, and after that checking netstat, I see that there is connection:

tcp 0 0 0.0.0.0:9999 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:52055 127.0.0.1:9999 TIME_WAIT

It is time_wait as I stopped mysql console to get netstat, but it works fine.

So at first glance this looks pretty much what I was actually hoping for, if it would work with local ip's as well.

Also did short test with php & pear DB, and looks like that works too. (connecting with localhost:9999 there).

So looks like that this kind of chain works at least:
php app (website) ->
(localhost) tungsten connector ->
(localhost) mysql

That of course leaves me with problem of replication I think, if I want to have one server as master, and other being just slave.

Question now is why that works for localhost (when it isn't specified), but not for other connections?

Hi Joonas,
I have observed the same behavior, which seems to be a mysql specific feature:
From this page: http://dev.mysql.com/doc/refman/5.1/en/can-not-connect-to-server.html "A Unix socket file is used if you don't specify a host name or if you specify the special host name localhost."
So your connection is most probably a unix socket (thus a local) one, which would explain the behavior you observe
However, I don't get why netstat reports a tcp/ip connection...
In any case, using a slave directly with tungsten is dangerous, so you might want to disallow unix socket connections to prevent any misuse of the stack
Cheers,
Gilles.