Databases on storage area networks, network-attached storage, or running in virtualized environments
Several considerations exist when using network-based storage or storage abstracted by virtualization that are not issues when databases are stored on local disks.
A data durability problem occurs when remote storage or the virtualization environment experiences service interruptions, ranging from connectivity loss to total failure from power loss. Data corruption can occur when the storage layer accepts data for writing that is not made durable before a crash occurs. In these cases, a database property can be set that reduces the likelihood of data loss and data corruption. The database property database-on-virtualized-or-network-storage
can be set on a per-backend environment basis to request all database writes to be written durably to the underlying storage.
There is a performance penalty when enabling this property and, in most cases, is not recommended except where network storage is unreliable. For network file systems, the benefits of faster recovery and less likelihood of data loss from unplanned events might outweigh the penalty. The exact overhead of enabling database-on-virtualized-or-network-storage
depends on the characteristics of the database, the host file system, storage array configuration, and network and virtualization input and output parameters. The write overhead penalty might be substantial for SAN environments. A full backup strategy should be used instead if performance is unacceptable.
To enable database-on-virtualized-or-network-storage
for each applicable backend, use the following command as an example, which references the configuration for the userRoot backend.
$ bin/dsconfig set-global-configuration-prop \
--set database-on-virtualized-or-network-storage:true
This should be set to false
if the database is on a local disk.