SSD Devices and Data Corruption
SSD
Database servers ensure that when a transaction is committed, the information is written physically to the storage and cannot be lost any more in case of power failure.
Database servers also use a journal file during operations that modify the data, writing information in it that can be used to recover the original state of the data in case of power failure during the updates, and avoid database corruption.
That’s why the database server must ensure that at specific points in the modification process, data that are still in the device cache are flushed to the SSD cells.
To achieve this, the database server calls frequently the Unix system function fdatasync, that requires the device to flush the data still pending in its internal cache and write them physically to the SSD cells. Unfortunately, physically writing to the SSD cells is a very inefficient and slow process (compared to writes to the internal cache), but this is the only means to ensure durability and avoid file corruption. Alas, performances are degraded so much that other solutions have been found.
SSD devices exist in two kinds: consumer-grade and enterprise-grade.
Consumer-grade SSDs are expected to run 8-10 hours a day.
The writes accumulate in a fast internal buffer (RAM) acting as a cache, before being actually physically written to the cells.
If the power supply of the SSD device goes off abruptly, the pending writes in the cache are lost, as the cache is volatile memory.Enterprise-grade SSDs are meant to be on 24⁄7, and handle more writes than consumer-grade SSDs.
Like consumer-grade SSDs, they contain a fast internal buffer (RAM) to accelerate access to the data.
They also contains large internal capacitors, that store a small amount of energy, like tiny batteries.
If the power supply of the SSD device goes off abruptly, these capacitors will give enough time to safely flush the pending writes in the internal cache to the physical cells. These features make them much more expensive than consumer-grade SSDs.
We must consider these different cases:
Laptop, containing an internal battery, with consumer-grade SSD. If the external supply fails, the internal battery of the laptop takes over and the laptop continues to run normally. The SSD continues to work as usual, flushing its internal cache when it fills up. Consumer-grade SSDs often send a confirmation to the fdatasync requests without actually flushing the buffer, to appear faster. They are lying, but this is safe because the SSD will never shut down abruptly, thanks to the battery of the laptop. For non-lying SSDs, the fdatasync function actually flushes the SSD cache and performs actual writes to the cells, degrading performances a lot.
Server or workstation, without battery, with consumer-grade SSD. If the external supply fails, the pending data in the volatile cache of the SSD will just be lost. This will lead to data corruption. So, never use a consumer-grade SSD in a server.
Server or workstation, without battery, with enterprise-grade SSD. If the external supply fails, the internal capacitors of the SSD will give enough power to allow the SSD to physically write the pending information still in its cache into the cells, before shutting down. No data corruption occurs.
So, even if the internal cache of the SSD is inherently volatile, the laptop makes it safe by using its own battery. And the enterprise-grade SSDs makes the internal cache safe by embedding large capacitors.
For both cases, the operations on the SSD will always use the internal cache, avoiding the sluggish physical writes to the cells. This also has the advantage of reducing the SSD wear out, increasing the life of the device.
Data Corruption
Data corruption can occur when the main power supply fails.
The voltage doesn’t drop instantly, and it will take a little time (a few milliseconds) to drop to 0. Some components of a computer will fails before the others. The RAM is quite vulnerable to voltage drop, more than hard disks or SSDs. The RAM will start to fail and will send garbage to the hard disk or SSD, which will happily write it all.
If you pull the plug of a server during heavy writes, you can end up with a database corruption. So, don’t do that.