Continuent Community

Hips,

I have been trying to figure out how to get small amount www-nodes to get good access to mysql databases. Tungsten seems to provide all needed tools, but this one piece isn't looking as clear as I would hope.

When using replicator + router + connector, connector seems to need user.map file containing user&pass&database combinations it can provide connections. That seems quite ok, when you have only few databases. However my situation is that there are dozens of databases, and they come and go quite frequently... meaning there would be quite burden to maintain user.map on each connector node. Also problem is generating this file initialy, I don't have list of user/pass/db's at hand.

So am I out of luck with connector? Either I have to figure way to create & admistrate that file, or then I need find other solution for my problem? Perhaps running without connector, as it seems to be so that router for example can pass connection directly to mysql without pre-auth checking.

Hi Joonas,
Good news: thanks to the router, you are not forced to define one tuple per database.
Just specify one user/map/dummy db entry per user and you will be able to connect to any database accessible by this user
Don't hesitate to let me know if this works
Cheers,
Gilles.

Didn't quite understand how I do what you suggested. I'm also a bit uncertain I was understood correctly, so I'll try to illustrate my situation.

Currently I have one server which has several sites. Same machine also hosts mysql, each site has own database there, and each have own user&pass. There is also dedicated db machine which hosts few bigger databases, and those are served from same www-server.

I'm now trying to find way to expand this setup so that I can have few www-servers, and so that they can access databases like they used this far. Each www-server would host slave database, and master being on either currently dedicated db machine or one of these www-nodes act as master database.

Now that dummy user you suggest, what kind entry that should be in situation like this? I haven't seen any mention about such dummy user in any documentation what I have read this far, so if it is somewhere, could you please point it out? I would appreciate if you can give me some simple example/explanation what kind of dummy user is needed in user.map, and is there need to add it somewhere else too.

If this works out I'm pretty sure this solves all of my troubles with mysql this far, for quite long time.

I'm actually talking about a dummy database name. This would work if you had the same user/pass pair on all database servers: any database you connect to with this given user would user the same provided password. Would that work for you?

Let's see if I got that right.

I for example have like this currently:
dbuser: site1, pass: site1pass, db: site1
dbuser: site2, pass: site2pass, db: site2
dbuser: siteN, pass: siteNpass, db: siteN

and in user.map there would be

dummy dummypass dummydb default

I have understood that user.map must have user&pass used to connect that connector. So what I put above wouldn't work, it should be like:
site1 site1pass dummydb default
site2 site2pass dummydb default

Which I don't see how that would help my situation.

All databases which this one connector would be connecting (via router or directly, whichever works) could be identical, so user&pass would be the same.

Or have I read implementation documents wrong? I have in mind this kind of flow:

php applications (webpages ->
tungsten connector ->
tungsten router ->
mysql server(s)

Each mysql server would then be keeped in sync with tungsten replicator.

Am I making any sense here, or do I try to achieve something what isn't ment to be possible? Hopefully not.

My point was that, despite what's written in the doc, you don't have to specify:
user/pass/db1
user/pass/db2
user/pass/db3
..

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:

When a native-protocol client connects to the connector, it
sends a "scrambled" password that cannot be re-used for further
connection (this prevents man-in-the-middle attacks). The only
way for the connector to then "really" connect to the underlying
database server is to know and send the plain password. This is
the reason why we need to store these user/password pairs in the
user.map file.

Just to answer your concern, the view you have of the Tungsten stack is exactly correct!

Cheers,
Gilles.