3 ms·
Absolutely. Those are healthy parts of a clean shutdown, which is what SIGTERM was really asking for, isn't it? InnoDB is designed to recover gracefully from
by yebyen 13y ago
Absolutely. Those are healthy parts of a clean shutdown, which is what SIGTERM was really asking for, isn't it?
InnoDB is designed to recover gracefully from a SIGKILL, too. The journal task is "saved" for later. That's why they tell you in DBA school, "don't use MyISAM tables. They're not safe." Because if they received a SIGKILL or power outage at the wrong moment, writes could have been lost. Amiright?
What you don't expect is for a process that receives SIGTERM to fail hard, and require an expensive journal recovery or suffer some unrecoverable data loss as a result.
- Xylakant 13y agoWell, actually: Recovering from a SIGKILL will (or at least used to) take much longer at startup than shutting down with SIGTERM, so it could handle that better. I still agree with you that it's reasonable, but others may hold a different opinion.
- yebyen 13y agoHeh - you're saying that the SIGKILL recovery on start is cheaper than the SIGTERM cleanup on quit. OK. I'll agree, that's strange. One would probably have expected to have to dot and cross the same number of I's and T's either way, and not for SIGKILL recovery to actually be faster. I didn't know that.
- Xylakant 13y agoNo, actually I wanted to say the opposite: Killing the process with SIGKILL and then doing recovery at startup is much more expensive than letting the process shut down properly with SIGTERM.
- jchrisa 13y agoThis paper measures the time difference between clean and unclean reboot across various systems. Another important point is that many servers never shut down intentionally, making unclean shutdown the norm in lots of deployments. https://www.usenix.org/legacy/events/hotos03/tech/full_papers/candea/candea.pdf https://www.usenix.org/legacy/events/hotos03/tech/full_paper...
- yebyen 13y agoThanks for the hard numbers. That also makes sense. It should be easy to rationalize that SIGKILL recovery is slower than SIGTERM shutdown for such a database. If your in-memory cache is empty, it won't be providing any speedups, right? Thus you'll need to go back to disk for everything.