Thank you. This is a very promising answer. I don't know that we want to
drop the table if we don't have to, but knowing that we can restart the DB
without the rollback operation is a boon! We could certainly do a mysqldump
of just that table (which works fine, we continue to run nightly backups
Hello.
Here is described the possible way of how to force the rollback
(you can kill the mysqld process and set innodb_force_recovery to 3 to
bring the database up without the rollback, then DROP the table that is
causing the runaway rollback):
http://dev.mysql.com/doc/mysql/en/forci
Thanks for the questions, hopefully this will help: InnoDB, yes. It's
version 4.1.11, not replicated.
I am familiar with KILL. It is definitely something I CAN do, but not
necessarily something I SHOULD do at this point in time. Usually when you
kill a process while it's running, it will roll b
INNODB I assume?
Replicated environment?
What version of mysql?
See KILL in the SQL manual.. if you do a show processlist you can get the
pid and you might be able to kill it.
I believe that it's safe to do a KILL on an DELETE but any decision you make
her is your own...
That's a LOT of data
Here's the situation. I have a table of about 900 million rows, consisting
of a bigint and an int in each row. There's an index on the bigint. The
table is referenced in a SELECT in other DB operations roughly 15 or 20
times per day.
We're under tight deadlines and some operations on the table
nuary 25, 2001 9:24 AM
Subject: What now?
> Hi,
>
>
> I followed the instructions in the manual for installing the MySQL source
> distribution. I used mysql-3.23.32.tar.gz under CLOS 1.2 and everything
> seems to have gone smoothly - there were no error messages.
>
> If I run
Hi,
I followed the instructions in the manual for installing the MySQL source
distribution. I used mysql-3.23.32.tar.gz under CLOS 1.2 and everything
seems to have gone smoothly - there were no error messages.
If I run ps I see that something called safe_mysqld is running.
However, no matter i
