Database auto updates, separate MySQL host

Here’s a bit of an odd question regarding database auto-updates:

I host my MySQL database on a separate server as I got tired of having multiple VMs with each having their own local MySQL install. This has been working out great as I host a couple of 3.3.5a servers and a 6.x server along with a few different web servers. Is there any way possible to specify a database host for the auto updater? I don’t have a problem with applying the updates manually, but in the past it was pretty nice to git pull > recompile > launch program with updates auto applying.

If this doesn’t exist, I’m not sure it would receive enough use to merit any development work, but if it does exist, I’d love to know about it!

Thanks in advance.

The auto updater uses your worldserver config - it will only work on databases that worldserver is actually using (I see no reason for it to update world database Y when worldserver itself reads data from X)

(none of this was wholly accurate looking back, just reference post below it)

Alright, didn’t work this time. Here is the console output:

Updating Auth database…

Applying update “2015_07_02_00_auth.sql” ‘E5EE384’…
ERROR 1049 (42000): Unknown database ‘WoD_auth’
Applying of file ‘/home//TrinityCore/sql/updates/auth/2015_07_02_00_auth.sql’ to database ‘WoD_auth’ failed! If you are an user pull the latest revision from the repository. If you are a developer fix your sql query.
Could not update the Login database, see log for details.

MySQL server is installed on the machine, but the service is stopped (I assume it has to be there to compile the server properly?). I have to start the service not to get a socket error when I want to try the updates. Here’s the error without server started:

Updating Auth database…

Applying update “2015_07_02_00_auth.sql” ‘E5EE384’…
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
Applying of file ‘/home//TrinityCore/sql/updates/auth/2015_07_02_00_auth.sql’ to database ‘WoD_auth’ failed! If you are an user pull the latest revision from the repository. If you are a developer fix your sql query.
Could not update the Login database, see log for details.

I see in the code where it looks like this should work, and an old thread back in April where the commit got pushed to fix this very thing - I just can’t make it work. The string in the worldserver.conf is as follows: “192.168.0.30;3306;;;WoD_auth”

If I go on my server and do a “mysql -u -p -h 192.168.0.30” it connects up without a hitch.

I can do the updates manually, it was just nice not having to! /emoticons/default_smile.png

What happens if you try to connect through ip instead of sockets?

My assumption all along is that I am just connecting via IP, but when the MySQL server isn’t running on the local machine, I do get a sockets error? This is where it doesn’t make sense in my head - I’m not 100% positive that in doing the update query, the updater is even connecting to the remote MySQL server.

I did a bit of research on sockets as I’ve never dealt with them before, but none of the nomenclature I could feed into the connection string got me any further. I’ll describe my setup below if it will help any:

Trinity 6.x server = Debian 8.0 x64 (192.168.0.62)

Trinity 3.3.5a server = Debian 8.0 x64 (192.168.0.35)

MySQL server = FreeBSD 10.1-RELEASE-p10 x64 (192.168.0.30)

All three are running on an ESXi 5.5 host with networks on the same subnet (not doing any weird VLAN stuff, all default), both Debian boxes can authenticate from the MySQL cli fine to the FreeBSD database host. I have a prefix for each required Trinity table in the DB corresponding to the version I’m running (i.e. - WoD_auth/characters/hotfixes/world, WotLK_auth/characters/hotfixes/world)

My connection string in worldserver.,conf is: “192.168.0.30;3306;root;;WoD_auth”

I’ve tried weird things that probably actually don’t make any sense such as “192.168.0.30:/tmp/mysql.sock;3306;root;;WoD_auth” and

“192.168.0.30;3306;root;;192.168.0.30\WoD_auth” I’ve dreamed those up following long posts on stackexchange, but if I’m honest I have no clue how to properly deal with a socket.

I’m open to any and all suggestions - the 6.x one is merely just an initial test box, so I can break it and blow it away as many times as needed!

Theoretically there is no reason why it shouldn’t work if you host the mysql server on a different machine.

Could you give it a try and revert the following commits locally according to your branch: https://github.com/TrinityCore/TrinityCore/commit/c1bd3282f8149890003bb353186131afe4708172 https://github.com/TrinityCore/TrinityCore/commit/fd660d725d62f56ab20e5bd170dc2614e202d050

Removed all of the additions from that commit and recompiled, same issue. I’m probably hung up on the wrong thing here, but when I have the local mysql server running, it appears to be attempting to connect to the local instance - when I do not have it running, I get the socket error. It’s my assumption based on what little bit of the code I can understand that unless I am throwing the connection string like this:

".;/tmp/mysql.sock;root;password;WoD_auth"The server will attempt to connect via TCP instead of via sockets - yet the error is telling me it can’t find the socket.

Banging my head on the wall on this one, not sure where to go from here… maybe back to a setup I understand, hah!

Minor update: I went into /etc/mysql/my.cnf and told the client to only use TCP as a test. The error I get with that is

Applying update “2015_07_02_00_auth.sql” ‘E5EE384’…
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘localhost’ (111)Same error I get if I just run “mysql” with no arguments from the terminal. I know 111 is connection refused, but there’s no mysql server running, so I guess not existing can be a method of refusal.

So I got it to work… sort of. I went to /etc/mysql/my.cnf and under the [client] section added

host=192.168.0.30
protocol=tcpNot a very elegant solution, but it does what I need it to do!

could you try it with the protocol and without the host entry?

Tried that, takes me back to the old errors… trying to connect to localhost again. I know with git, it’s highly unlikely that I have a botched install, but since I’ve already got the dbc/maps/vmaps/mmaps, I may just try to rebuild it from scratch to see if I’ve messed anything up.