6 ms·

I think that's rather harsh, MySQL/InnoDB can't handle kill -9. Granted, kill-9'ing a database process is bad karma :)

by chomp 13y ago

icedchai 13y ago
Of course it can. Have you ever tried it?
dwc 13y ago
I think you may have reinforced tptaceks's point, actually. Many DBs can handle abrupt termination.
- hnriot 13y ago
  isn't that the whole point of journaling! Of course database can handle kill -9, they are designed to. That doesn't mean it's friendly to do that because you'll pay a price in redoing journals. also -9 can leave ipc hanging so some ipcs might be needed.
- sp332 13y ago
  Not that the database will get corrupted, but that's a good way to lose data.
  - jeltz 13y ago
    A database should not lose any committed data on `kill -9` in the default configuration. This is why PostgreSQL waits on fsync on the write-ahead log before completing a commit. This can be disabled with synchronous_commit off, in which case you will indeed lose data on a crash.
    - marcosdumay 13y ago
      Normaly, it's not nice to lose uncommited data.
      - zAy0LfpBZLC8mAC 13y ago
        I said it already elsewhere in this thread, but either the writer has other persistent storage, then it should just keep the data and retry later and nothing will be lost, or the writer doesn't have other storage, then you will also lose uncommitted data with a normal shutdown, as you can not even try to commit any data while a data base is down.
protomyth 13y ago
If a database cannot handle kill -9 then it cannot be considered transactional and shouldn't be used.
- scott_karana 13y ago
  Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. It would be far too easy to kill any program mid-write().
  - protomyth 13y ago
    A database should not be corrupt if a kill -9 is issued and it failed mid write. That is a design criteria that cannot be compromised.
  - zAy0LfpBZLC8mAC 13y ago
    That is what journaling is for. A database that corrupts data when you kill -9 it is garbage. A database has to survive without corruption when power fails unexpectedly, and that's even harsher than kill -9 in terms of what can go wrong if your code is sloppy.
  - weland 13y ago
    > Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. Unless you're talking about a database not intended to be used in production, that's really not fair. What if the power comes down? The UPS blows up? There's an earthquake and the ceiling comes down? Is it OK for a DBMS to be corrupt its data then, too?
  - masklinn 13y ago
    > Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. Yes it is. The DB should not unrecoverably corrupt itself in case of hard power loss, and a kill -9 is significanly less traumatic than a hard power loss (which includes PSU melting/explosions or UPS going down).
Xylakant 13y ago
Actually, it can. Killing it with -9 prevents the process from writing the buffer pool etc. to disk, so that the the server needs to recover that state from the journal/log files. No data will be lost though. So you're basically trading time at shutdown vs. time at start-up.
- craigching 13y ago
  > So you're basically trading time at shutdown vs. time at start-up. I'm being a bit pedantic, but trading time at shutdown vs. time at start-up + potential data loss (if the journal was in the middle of being written while the -9 was sent, you probably lose the last journal entry).
  - zAy0LfpBZLC8mAC 13y ago
    If that counts as data loss, then a "normal shutdown" also causes data loss. When the journal write gets interrupted, the database client won't get a success return, so it should not delete the data it was trying to commit, and retry the transaction at a later time, so nothing is lost at all. When the client is some entity without reliable persistent state that can not store the data in order to commit it later, that entity will be unable to connect to the database once the "normal shutdown" is completed, and thus will face the exact same problem, as the journal entry is "lost" before the write even starts.
    - craigching 13y ago
      > If that counts as data loss, then a "normal shutdown" also causes data loss. I disagree. If a journal write was in progress on SIGTERM, you either fail or complete the write, returning the result to the client. In either event, you should end up with a clean journal on SIGTERM, assuming your implementation was sane (i.e. how I'd write it). If the client chooses to ignore the failure, that's not on the server and that's the whole point. A normal shutdown should never require data loss. Somehow you're conflating SIGTERM with SIGKILL and I'm not understanding why.
      - 13y ago

I think that's rather harsh, MySQL/InnoDB can't handle kill -9. Granted, kill-9'ing a database process is bad karma :)

by chomp 13y ago

I think that's rather harsh, MySQL/InnoDB can't handle kill -9. Granted, kill-9'ing a database process is bad karma :)

icedchai 13y ago

Of course it can. Have you ever tried it?

dwc 13y ago

I think you may have reinforced tptaceks's point, actually. Many DBs can handle abrupt termination.

hnriot 13y ago
isn't that the whole point of journaling! Of course database can handle kill -9, they are designed to. That doesn't mean it's friendly to do that because you'll pay a price in redoing journals. also -9 can leave ipc hanging so some ipcs might be needed.
sp332 13y ago
Not that the database will get corrupted, but that's a good way to lose data.
- jeltz 13y ago
  A database should not lose any committed data on `kill -9` in the default configuration. This is why PostgreSQL waits on fsync on the write-ahead log before completing a commit. This can be disabled with synchronous_commit off, in which case you will indeed lose data on a crash.
  - marcosdumay 13y ago
    Normaly, it's not nice to lose uncommited data.
    - zAy0LfpBZLC8mAC 13y ago
      I said it already elsewhere in this thread, but either the writer has other persistent storage, then it should just keep the data and retry later and nothing will be lost, or the writer doesn't have other storage, then you will also lose uncommitted data with a normal shutdown, as you can not even try to commit any data while a data base is down.

protomyth 13y ago

If a database cannot handle kill -9 then it cannot be considered transactional and shouldn't be used.

scott_karana 13y ago
Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. It would be far too easy to kill any program mid-write().
- protomyth 13y ago
  A database should not be corrupt if a kill -9 is issued and it failed mid write. That is a design criteria that cannot be compromised.
- zAy0LfpBZLC8mAC 13y ago
  That is what journaling is for. A database that corrupts data when you kill -9 it is garbage. A database has to survive without corruption when power fails unexpectedly, and that's even harsher than kill -9 in terms of what can go wrong if your code is sloppy.
- weland 13y ago
  > Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. Unless you're talking about a database not intended to be used in production, that's really not fair. What if the power comes down? The UPS blows up? There's an earthquake and the ceiling comes down? Is it OK for a DBMS to be corrupt its data then, too?
- masklinn 13y ago
  > Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. Yes it is. The DB should not unrecoverably corrupt itself in case of hard power loss, and a kill -9 is significanly less traumatic than a hard power loss (which includes PSU melting/explosions or UPS going down).

Xylakant 13y ago

Actually, it can. Killing it with -9 prevents the process from writing the buffer pool etc. to disk, so that the the server needs to recover that state from the journal/log files. No data will be lost though. So you're basically trading time at shutdown vs. time at start-up.

craigching 13y ago
> So you're basically trading time at shutdown vs. time at start-up. I'm being a bit pedantic, but trading time at shutdown vs. time at start-up + potential data loss (if the journal was in the middle of being written while the -9 was sent, you probably lose the last journal entry).
- zAy0LfpBZLC8mAC 13y ago
  If that counts as data loss, then a "normal shutdown" also causes data loss. When the journal write gets interrupted, the database client won't get a success return, so it should not delete the data it was trying to commit, and retry the transaction at a later time, so nothing is lost at all. When the client is some entity without reliable persistent state that can not store the data in order to commit it later, that entity will be unable to connect to the database once the "normal shutdown" is completed, and thus will face the exact same problem, as the journal entry is "lost" before the write even starts.
  - craigching 13y ago
    > If that counts as data loss, then a "normal shutdown" also causes data loss. I disagree. If a journal write was in progress on SIGTERM, you either fail or complete the write, returning the result to the client. In either event, you should end up with a clean journal on SIGTERM, assuming your implementation was sane (i.e. how I'd write it). If the client chooses to ignore the failure, that's not on the server and that's the whole point. A normal shutdown should never require data loss. Somehow you're conflating SIGTERM with SIGKILL and I'm not understanding why.
    - 13y ago