I see your point, especially when not being in control of client software. You may be in a hard position.
I assume your did already some research into this so I won't give you the RTFM answer. :-) Adding in your logging code should not be that hard, well, it depends what kind of logging you'd like or need and if you could use some mature C/C++ logging API. In the past I had to add logging to IMAP servers and connectors. The problem you will get into is, unless you manage MySQL AB to accept these patches for good into their product, you in essence will be forking their source and will have to re-apply your patches, and do full regression testing, for each MySQL upgrade/version. Under such loads even the slightest memory leak or resource locking can really mess things up. Good luck. -Daniel. -----Original Message----- From: Michael Loftis [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 3:23 PM To: Daniel Fisla; mysql@lists.mysql.com Subject: RE: mysql *SERVER* error logging --On Tuesday, March 08, 2005 15:03 -0500 Daniel Fisla <[EMAIL PROTECTED]> wrote: > > Under UNIX/linux use syslog, for me /var/log/messages shows login/auth > error > > Mar 6 05:39:11 orion pdns[1865]: gmysql Connection failed: Unable to > connect to database: Access denied for user 'root'@'localhost' (using > password: NO) This is client logging, I need server logging, IE real logging. Yes this suffices for a lot of people but not for anyone doing database hosting like we are. > Now for dropped sockets/connections you need to enable logging for this > kind of thing in your connector and/or pooling software. I don't think > this exists on the server side as it is not so simple to determine the > actual cause. Then something is seriously broken with MySQL if this is the case, a server obviously knows why a client/child disconnected, and should always know this. It should be able to log this, especially in the case of authentication failures. > Let's say your router/switch drops connections, to server this looks like > TCP socket timeouts and eventually will try to close the connection as > such, but was it dropped or was it just left open and not closed properly > by the client. It's not a networking issue, wish it was, that'd be really simple to solve. The web cluster runs identical software (totally completely identical, NFS mounted, or imaged from a central tarball) and it's still intermittent and happening from all the servers. The X-Cart software that a number of people run here can log and email errors as they happen and includes data on where as well. It's pretty randomly distributed. > This is why it makes sense to track these things in your data > connector/pooling, with your kind of load you should have this kind of > connection tracing/logging enabled in the client side and/or middle tier > anyway. Can't, thousands of individual clients and software, everything from PHP X-Cart apps, to perl and C apps. We don't control the connecting software, just like an FTP, SMTP, HTTP, etc. server. Every other piece of server software can log it's authentication issues and disposition, why can't MySQL? Oracle can do this, Postgres, DB2, etc etc etc. I'm beginning to think that I'm going to have to spend my time to code proper logging inside of MySQL which is a major bummer but being as there's no way to track down errors without logs well I'm kinda stuck. No I'm not picking on you personally, but I am picking on MySQL and MySQL AB. I've had this problem with MySQL before and that's why I prefer personally other DBs, I however, don't get to make this choice, it's the thousands of webhosting clients that make it, not me. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] !DSPAM:422e09f281225276021141! -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
