Apologize but I really don't have much information for the question.
I have a single MySQL MySIAM engine table that's holding around 80K records (continually increase).
Today it's suddenly stop responding.
I can't even do a single query (e.g. SELECT * FROM table LIMIT 1), the server just spend time executing and look like will never stop.
I can't dump table to make backup.
However, another tables in the same database, same engine (MySIAM) are working just fine.
I'm not sure where to go from here. Not sure if it's DEADLOCK or anything.
All data in that table is really important. You direction pointing to help me identify the problem would be really appreciated. For example, are there any command to check table if it's corrupt by what reasons, etc.
UPDATE:::::
I can't use CHECK TABLE neither, it also take forever execution time.
UPDATE ::::
I did research and come up with something about REPAIR TABLE.
However, it's suggested that I should do the backup first.
As I can't do the back for this table, would it be OK to use the REPAIR command anyway?
::::::::::::: SOLVED :::::::::::
Follow Cristian's help, use SHOW PROCESSLIST; command. I see that there is a process with state 'Copying to tmp table' that hold another process.
So I use KILL <process id> to kill that process and everything released to normal.
Cheers
Chanon
Sorry but I can't comment your question... :)
Exactly which version of MySQL you run, 5.1.xx?
Can you post you SHOW PROCESSLIST; status?
UPDATE: Chanon, after this event, and to prevent this problem, you have to review and optimize the query that send MySQL in "Copying to tmp table" state, in order to avoid slowness and a risk of "disk full" for your temporary partition.
Related
I've executed the copy table operation from PhpMyAdmin and it is taking too long (big table), and now the original and new table are not responding (I can browse the other tables in PhpMyAdmin)
I think because maybe there is a read lock or something worst, is possible to cancel the operation or see at least what's happening?
Two possible things - first, you could restart the webserver to stop any running PHP scripts. That might help if PHPMyAdmin copies the data in batches.
Second, you can execute show full processlist query to see all running queries. Identifying the hung query should not be too hard. Then use kill <pid> query (replace the with the actual process ID) to kill that query.
On phpMyAdmin's main page, go to Status > Processes. You should be seeing one process with a large value under Time; use the Kill link to stop it.
We currently have following problem that caused our application to go down. All queries we do go into a "waiting for table" state and stay there, causing the MySQL servers connections to be used up.
We investigated the Issue and learned what it means, according to the MySQL manual
Waiting for tables, Waiting for table
The thread got a notification that the underlying structure for a
table has changed and it needs to reopen the table to get the new
structure. However, to reopen the table, it must wait until all other
threads have closed the table in question.
This notification takes place if another thread has used FLUSH TABLES
or one of the following statements on the table in question: FLUSH
TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE
TABLE, or OPTIMIZE TABLE.
I inspected our running processes with SHOW PROCESSLIST and found no Data Definition Language statements, or any statements that where in the list above.
What else could cause this?
We did not really find an answer to what caused the problem, but it seems like the automatic backup feature of amazon was the culprit. We are now up and running again after contacting Amazon support.
I have the same problem today. At last, I found it is caused by the concurrency of a big query and the backup process. Mysqldump with –master-data may cause flush table command.
See this
http://bugs.mysql.com/bug.php?id=35157.
My situation is:
The flush command was waiting for the big query;
Other querys were waiting for the flush table command became completed, so they were blocked.
When the big query completed, things went right.
So I guess you might have a big query at that time.
On our primary MySQL server, it took 40 minutes to insert rows and re-enable keys on a particular table. On the slave, the ALTER TABLE ... ENABLE KEYS command has been running now for just over 100 minutes, which is very unusual. I'd like to kill it, but that will annoy the slave. Is there any way whatsoever to get a glimpse at how much longer this will take?
There is no way to determine how much longer this will take. The command will copy all data to a temporary table, make the changes and then rename the copy to replace the original. You may well see 'Copy into temporary table' in the ProcessList, but this doesn't give any indication as to how much is left.
I also suggest that you do not kill the process and let it finish the operation.
Patience!
No way to tell. Just have to wait it out.
I'm experiencing this weird problem reading data from a table called nodes. Any select query is taking forever to execute. I don't even know if its going to return eventually but it doesn't seem like that. It used to return quickly before. Nothing has changed as far as I know. No new records are inserted and none are deleted too. Couple of queries that I tried.
select count(1) from nodes;
select node_id, type from nodes where node_id='abc';
node_id is a primary key in nodes table if that helps. The previous day all of select queries used to return in no time like in 0.01ms etc.
My guess is that somehow a lock is placed on the table preventing my queries from proceeding.
I appreciate if someone can let me know or give a pointer to how to find locks on a particular table in MYSQL 5.0.90-log FreeBSD.
What could be other possibilities?
Thanks a bunch.
I escalated this problem to a senior staff in our group. He figured that when mysqld tried to log, file system has become full. This is solved by stopping mysqld and creating a symbolic link to a file on a different file system that has lots of free space. started mysqld and all select queries are running without blocking.
Try to look at processes on you server, maybe you have to kill someone of them to free the table.
Here is an interesting link about that:
http://mysqlpreacher.com/wordpress/2009/07/mysql-processlist-showkill-processes/
First try to restart the sql service if that doesn't help, rebuild the indexes .
May be indexes got curropted. Try rebuilding all indexes.
How much time does MySQL need to build an index of a table with 30,000,000 entries that are strings of length 256?
At the moment it seems to take hours and I don't know how long I should wait till I conclude that MySql simply failed at building an index.
You may run SHOW PROCESSLIST \G in mysql console to watch its state. I had a similar problem just a couple of hours ago, but my table was much smaller.
Here a list of thread states you will definitely need. After an hour of waiting I realized that ALTER TABLE CREATE INDEX is in Locked state, I needed to restart mysqld and run the statement once again. That time I had index built in 15 minutes.
By the way, I recommend to run index creation from mysql console, GUI tools may add some spices to the process.
it could easily take hours. it all depends on the machine specs, load, etc etc. to see whether it's failed, check something like top or watch your hard drives - if they're going mad it's still indexing.
Depending on your OS you may check for disk activity (i.e. does it reads/writes DB files) to find out if it failed or not.