I just saw your mail address - you're one of the gurus who runs PlanetMirror, aren't you? All hail he who provides my Mandrake ISOs! Huzzah! :-)
Hmm....personally, I don't see how you can do "something wrong" during a DELETE. This is one of those non-descript problems that give me sleepless nights. As you said, the RPMs aren't an option - may I ask why? I deploy MySQL AB supplied RPMs on all of my production servers (running a mixture of Mandrake and Redhat) and seem to cope. I'm not having a go, just hoping we can see something about your specific needs that might help with this problem. Additionally, there is a MySQL AB RPM available that has both the 4.0.x and 3.23.x client libraries included. Regards, Chris On Tue, 28 Oct 2003 02:21 pm, Dan Goodes wrote: > Hi Chris, > > Yeah - we're using MyISAM for it. We've never had a problem before, which > is why I am getting to think that something I did during the delete has > caused problems. > > The database has two tables, one for the main "apache" data, and one for > some supplimental data for each request. We had to go in and delete some > rows, but of course MySQL (3.23) can't delete from multiple tables, and > can't delete from one table using the other table as a reference. So we > upgraded our MySQL to 4.0.15 and successfully broke just about everything > (so many things were dependent on libmysqlclient.so). > > Anyway, we deleted the rows we needed to, and then went thru dependency > hell trying to go back to the old version of mysql. Now though, we're > finding that we need to delete some more again, but this time i wasn't > able to upgrade to delete data from both tables, so I simply deleted from > one. > > Complicated? yeah it is. :( Thanks for your suggestions so far. > > -dan > > On Tue, 28 Oct 2003, Chris Nolan wrote: > > Hmm.... > > > > MyISAM should stand up under really heavy load without too much of a > > problem. Are you using MyISAM for this? Have you thought about either > > InnoDB or BDB? > > > > Regards, > > > > Chris > > > > On Tue, 28 Oct 2003 02:02 pm, you wrote: > > > Using Redhat linux 7.3 with an ext3 FS. > > > > > > Incidentally, I've just manually restarted mysql (which drops all > > > in-progress processes), and it seems that the problem "takes a while to > > > show" (i.e. there's a period after a restart that things seem to go > > > along fine, then it all comes undone). I also should note that the > > > database is being written to almost-constantly (it's being used as an > > > apache logger process via mod_log_sql). > > > > > > -dan > > > > > > On Tue, 28 Oct 2003, Chris Nolan wrote: > > > > Which platform are you using? Which FS? > > > > > > > > Regards, > > > > > > > > Chris > > > > > > > > On Tue, 28 Oct 2003 01:14 pm, Dan Goodes wrote: > > > > > Hi folks, > > > > > > > > > > I have a bit of a problem. I'm running 3.23.53 which I've compiled > > > > > up from source (because the RPMs are not an option for me). > > > > > > > > > > I have a process that does a fairly large select statement every 10 > > > > > minutes - up until a few days ago it was all find and dandy. > > > > > > > > > > A few days ago I did a massive delete from one of the tables > > > > > (getting rid of a lot of old records), and since then things have > > > > > gone awry. The select statement seems to get "stuck" in the "COPY > > > > > TO tmp table" stage, and starts to back up fairly heavily. Each of > > > > > the cron-run processes gets to this "COPY TO TMP TABLE" stage and > > > > > locks up, which consumes all available slots on the server and the > > > > > whole things comes to a grinding halt. > > > > > > > > > > I've already run an optimize table on the table, and that got rid > > > > > of all the "empty space" freed up by the delete. > > > > > > > > > > Any ideas why, after the massive delete, things have started > > > > > slowing right down (or locking up entirely)? > > > > > > > > > > THanks for help. > > > > > > > > > > -Dan -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
