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.
Related
From time to time it happens that some indexes in our tables get broken and the DB start consuming 100% CPU load and in some time it gets completely stuck. Even simple queries won't finish and restarts don't help.
What I found is to either drop and recreate indexes one by one (which might take a loooong time and lot of investigation) or just calling alter table mytable engine=innodb; on suspicious table. This works actually quite well, it fixes everything and everything gets back to normal. But I have no idea what actually happens in background and why it helps. Also – would it help to do this manually once a month? Is it a good idea to automatize this? Is there some way to do some DB health check?
A guess...
You have an older version of MySQL/Percona, one that either does not have "persistent statistics" or does not have it enabled.
And you have a nasty query that sometimes leads the Optimizer to pick the wrong query plan.
The quick fix (that may or may not work) is to run ANALYZE TABLE of the table(s) in the slow query.
A better fix may be to upgrade the version.
Meanwhile, let's see the query, its EXPLAIN, and SHOW CREATE TABLE for each table involved. The may be a way to reformulate it to be less flaky.
I've recently been thrust into the position of db admin for our server so I'm having to learn as I go. We recently found that one of our tables had maxed out the id column and needs to be migrated to bigint.
This is for an INNODB table with roughly roughly 301GB of data. We are running mysql version 5.5.38. The command I'm running to migrate the table is
ALTER TABLE tb_name CHANGE id id BIGINT NOT NULL;
I kicked off the migration and we are now 18 hours into the migration, but I'm not seeing our disk space on the server change at all which makes me think nothing is happening. We have plenty of memory so no concern there, but it still shows the following message state when I run "show processlist;"
copy to tmp table
Does anyone have any ideas or know what I'm doing incorrectly? Please ask if you need more information.
Yes, it will take a looooong time. The disks are probably spinning as fast as they can. (SSDs employ faster hamsters.)
You can kill the ALTER, since all it is doing is, as it says, "copying to tmp table", after which it will rename the tmp table to be the real table and drop the old copy.
I hope you had innodb_file_per_table = ON when you started the ALTER. Else it will be expanding ibdata1, which won't shrink afterwards.
pt-online-schema-change is an alternative. It will still take a loooooong time (with one extra 'o' because it will be slightly slower). It will do the job without blocking other activity.
This might have been a good time to check all the columns and indexes in the table:
Could some INTs be turned into MEDIUMINT or something smaller?
Are some of the INDEXes unused?
How about normalizing some of the VARCHARs?
Maybe even PARTITIONing (but not without a good reason)? Time-series is a typical use for Data Warehousing.
Summarize the data, and toss at least the older data?
If you would like further guidance, please provide SHOW CREATE TABLE.
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.
What happens if you kill a long-running alter query? Will the alter query simply revert? How long could that take (as a proportion of the time it has already been running)?
What if that query is being replicated onto another server? Will killing the process on the other server revert the original server's alter query?
We're running mysql
It depends what you're doing. If you're running an alter table...add index command on an InnoDB table (not so sure about MyISAM), then it will just run and run as it copies the whole darn table lock-stock-and-barrel first: if it's in the middle of "copy to temp table" then it's pretty much unstoppable.
See here:
In most cases, ALTER TABLE works by
making a temporary copy of the
original table. The alteration is
performed on the copy, and then the
original table is deleted and the new
one is renamed. While ALTER TABLE is
executing, the original table is
readable by other sessions. Updates
and writes to the table are stalled
until the new table is ready, and then
are automatically redirected to the
new table without any failed updates.
What if that query is being replicated onto another server?
The ALTER will be executed on that server as well, with the associated impacts.
Will killing the process on the other server revert the original server's alter query?
Nope. The original server has no back channel to learn about what occurred (or didn't) on the slave. If you kill the ALTER on the slave, then you will wind up in the situation where the master has the new constraint or index, and the slave doesn't. This is rarely a recipe for happiness :)
Once an ALTER enters the replication log, you either have to let it run everywhere, or kill it everywhere.
I have a long-running process in MySQL. It has been running for a week. There is one other connection, to a replication master, but I have halted slave processing so there's effectively nothing else going on.
How can I tell if this process is still working? I knew it would take a long time which is why I put it on its own database instance, but this is longer than I anticipated. Obviously, if it is still doing work, I don't want to kill it. If it is zombied, then I don't know how to get the work done that it's supposed to be doing.
It's in the "Sending data" state. The table is an InnoDB one but without any FK references that are used by the query. The InnoDB status shows no errors or locks since the query started.
Any thoughts are appreciated.
Try "SHOW PROCESSLIST" to see what's active.
Of course if you kill it, it may then want to take just as much time rolling it back.
You need to kill it and come up with better indices.
I did a job for a guy. Had a table with about 35 million rows. His batch process, like yours, had been running a week, with no end in sight. I added some indexes, made some changes to the order and methods of his batch process, and got the whole thing down to about two and a half hours. On a slower machine.
Given what you've said, it's not stuck. However, the is absolutely no guarantee that it will actually finish in anything resembling a reasonable amount of time. Adding indicies will almost certainly help, and depending on the type of query refactoring it into a series of queries that use temp tables could possibly give you a huge performance boost. I wouldn't suggest waiting around for it to maybe finish.
For better performance on a database that size, you may want to look at a document based database such as mongoDB. It will take more hard drive space to store the database, but depending on your current schema, you may get much better performance.