Failure Resiliency of RDU Database
The RDU database uses a technique known as write-ahead logging to protect against database corruption that could result from unforeseen problems, such as an application crash, system failure, or power outage.
Write-ahead logging involves writing a description of any database change to a database log file prior to writing the change into the database files. This mechanism allows the repair of any incomplete database writes that can result from system failures.
The RDU server performs an automatic recovery each time it is started. During this recovery process, the database log files are used to synchronize the data with the database files. Database changes that were written into the database log, but not into the database, are written into the database during this automatic recovery.
In this way, write-ahead logging virtually guarantees that the database does not become corrupted when the RDU server crashes because the database is automatically repaired when the RDU server is restarted.
Write-ahead logging requires these conditions to work properly:
-
You must set up the file system and physical storage so that they guarantee that the data is flushed to physical storage when requested. For example, a storage system with volatile memory-only write cache, which loses data during system failure, is not appropriate. However, a disk array with battery-backed write cache which guarantees that the data gets persisted, even in the event of a system failure, is acceptable. A system without battery-backed write cache should flush the data disk when requested instead of performing in-memory data caching.
-
You must set up the file system with an 8192-byte block size to match the RDU database block size.