My mysql database gets deleted automatically
when I checked the error log I found this error
ec4 InnoDB: FTS Optimize Removing table noisepollution/#sql2-186c-1e
Anyone know how to resolve this?
#sql... is a temp table built for supporting ALTER or some other action. Normally it would be automatically removed (or renamed). But if there is a system crash, or certain other errors (maybe: out of disk space), the file is left around. The message you gave sounds as if it came from a Cloud service that is trying to clean up the mess.
In any case, please provide the actions that happens just before the problem
Related
On several occasions, I've tried to do a query on Google Cloud SQL that involves an order by statement, only to have the query fail with the error
Incorrect key file for table '/cloudsqltmp/#sql_44f4_1.MYI'; try to repair it
This sounds like the /cloudsqltmp/ partition is filling up with my temporary table. The result set isn't that big, however, and the program doing that query has done so on several other occasions, so I suspect that the space is actually filling up with someone else's temporary table. I was able to clear this by restarting the instance several times (I assume it finally gave me a new machine, or the space cleared up), but this seems very inelegant.
Is there a better way to handle this if it happens again?
Is there a better way to prevent this from happening?
If my assumption of what happened is wrong - what actually happened?
What I would recommend doing is:
Creating a Google Compute Engine instance and run MySQL on it. This way if you run into this problem again, you can use the follow solution below.
1) Modify the /tmp partition to have more space. There is a very useful link here on how to do it.
2) Create a CronJob to clear the /tmp. If you are not comfortable with CronJob, I found another tool called tmpreaper. To install it, run sudo apt-get install tmpreaper. Also use InnoDB instead of MyISIAM. Google recommends using it.
3) You are correct to assume that /tmp is getting full since restarting the instance resolves the issue
I hope my recommendations were helpful.
I'm running PHPBB (most up-to-date non-beta version) and in the last 3 months, the error appears during a search every few days:
'phpbb_search_wordmatch' is marked as crashed and last (automatic?) repair failed
To fix it, I then just run a repair on the table. I am still working on a way to figure out why this keeps crashing. The host was not helpful and it could be that the table is too large for the server (700 mb or so)
My Question: Could I create a trigger in PHPMyAdmin in the meantime to automatically repair the table whenever this error happens? You see it on the table in PMA when you go to access it, so there must be some entry that I can use to create the trigger.
Unfortunately this issue is difficult to fix for me being on a shared server, and all resources online say to contact the host, so as long as I can at least get it to fix itself when it happens.
You may be better off setting up a scheduled task. I'm not aware of how you could create a trigger that detects when the table needs repair; I don't believe there are hooks for the logic to detect that situation and cause a procedure to run.
From the database, there's an Events tab where you can enable the MySQL event scheduler and create an event which would run, say, once per week and run the SQL statement to repair the table. It's still not ideal, but I think it's better than using a trigger in this case.
Is it possible to restore table to last time with data if all data was deleted accidentally.
There is another solution, if you have binary logs active on your server you can use mysqlbinlog
generate a sql file with it
mysqlbinlog binary_log_file > query_log.sql
then search for your missing rows.
If you don't have it active, no other solution. Make backups next time.
Sort of. Using phpMyAdmin I just deleted one row too many. But I caught it before I proceeded and had most of the data from the delete confirmation message. I was able to rebuild the record. But the confirmation message truncated some of a text comment.
Someone more knowledgeable than I regarding phpMyAdmin may know of a setting so that you can get a more complete echo of the delete confirmation message. With a complete delete message available, if you slow down and catch your error, you can restore the whole record.
(PS This app also sends an email of the submission that creates the record. If the client has a copy, I will be able to restore the record completely)
As Mitch mentioned, backing data up is the best method.
However, it maybe possible to extract the lost data partially depending on the situation or DB server used. For most part, you are out of luck if you don't have any backup.
I'm sorry, bu it's not posible, unless you made a backup file earlier.
EDIT: Actually it is possible, but it gets very tricky and you shouldn't think about it if data wasn't really, really important. You see: when data get's deleted from a computer it still remains in the same place on the disk, only its sectors are marked as empty. So data remains intact, except if it gets overwritten by new data. There are several programs designed for this purpose and there are companies who specialize in data recovery, though they are rather expensive.
For InnoDB tables, Percona has a recovery tool which may help. It is far from fail-safe or perfect, and how fast you stopped your MySQL server after the accidental deletes has a major impact. If you're quick enough, changes are you can recover quite a bit of data, but recovering all data is nigh impossible.
Of cours, proper daily backups, binlogs, and possibly a replication slave (which won't help for accidental deletes but does help in case of hardware failure) are the way to go, but this tool could enable you to save as much data as possible when you did not have those yet.
No this is not possible. The only solution will be to have regular backups. This is very important.
Unfortunately, no. If you were running the server in default config, go get your backups (you have backups, right?) - generally, a database doesn't keep previous versions of your data, or a revision of changes: only the current state.
(Alternately, if you have deleted the data through a custom frontend, it is quite possible that the frontend doesn't actually issue a DELETE: many tables have a is_deleted field or similar, and this is simply toggled by the frontend. Note that this is a "soft delete" implemented in the frontend app - the data is not actually deleted in such cases; if you actually issued a DELETE, TRUNCATE or a similar SQL command, this is not applicable.)
If you use MyISAM tables, then you can recover any data you deleted, just
open file: mysql/data/[your_db]/[your_table].MYD
with any text editor
Out of blue moon, all of sudden, 1 of my database is crashed. This is not the first time, last time I use the "repair table" command and was lucky able to fix it. But it happens again, same table, same error, same solution.
Error:
1194: Table 'users' is marked as crashed and should be repaired
Do I need to repair my tables every day/week/month? Is there a permanent solution for "table-crashing" problem? Its really scary!!! Please help
This shouldn't happen normally, if your tables are crashing it means something is wrong with your system. Likely a bad disk or bad DRAM (or one of lots of unlikely things, like bad pci->sata bridge, etc...). If you have another system around, try migrating to that system and see if your errors continue.
You do have another equivalent system around, right? In case the primary DB crashes hard, and you need to restore a backup ASAP?
I suppose it could also be a bug in mysql, make sure the version you are using doesn't have known bugs.
To debug this problem, let alone just about any other problem, start looking in your logs. If you MySQL server runs on Windows, there are event logs for application and system, and I would look at those. If your MySQL server runs on Linux, logs are usually found under /var/log, and you usually have to be root to view them. A good way to view on linux is
tail (where is replaced by the real name of the file).
As you have been advised in another answer, you might have disk issues. Run a hardware diagnostic on the disks.
Whatever you decide to do, please do not depend on repairing a table; because you soon might not be able to. Using an Informix SE database, I had to rebuild a table, and there was nothing apparently wrong with the data in the table. It was a nightmare, and took the better part of a weekend. I could not export the database, on which our test and development systems depend.
Every so often I get an error saying one of my tables "is marked as crashed and should be repaired". I then do a REPAIR TABLE and repair it. What causes them to be marked as crashed and how can I prevent it? I am using MyISAM tables with MySQL 5.0.45.
There can be a few reasons tables get corrupted, it is discussed in detail in the manual.
To combat it, the following things work best:
Make sure you always MySQL shutdown properly
Consider using --myisam-recover option to automatically check/repair your tables in the event that shutdown wasn't done properly
Make sure you are on the most recent versions as known corruption bugs are normally fixed ASAP
Double check your hardware with a test to see if it is causing problems. Tools like sysbench and memtest86 can often help verify if things are working as they should.
Make sure nothing is touching the data directory externally, such as virus checkers, backup programs, etc...
Usually, it happens when the database is not shut down properly, like a system crash, or hardware problem.
I used to get errors from mysql just like you.
I solved my problems in this way
Convert to all myisam tables to InnoDB (you can search "myisam vs InnoDB" in stackoverflow.com and search engines to find out why)
For getting best performance from MySQL, use a third-party program MONyog
(MySQL Monitor and Advisor) and check performance tips
These two steps saved me. I hope these also help you lot.
It could be many things, but MySQL Performance Blog mentions bad memory, OS or MySQL bugs that could cause hidden corruption. Also, that and another article mention several things to keep in mind when doing crash recovery.