1. Getting Started With Solaris Volume Manager
2. Storage Management Concepts
3. Solaris Volume Manager Overview
4. Solaris Volume Manager for Sun Cluster (Overview)
5. Configuring and Using Solaris Volume Manager (Scenario)
Understanding the Majority Consensus Algorithm
Administering State Database Replicas
Handling State Database Replica Errors
Scenario--State Database Replicas
8. RAID-0 (Stripe and Concatenation) Volumes (Overview)
9. RAID-0 (Stripe and Concatenation) Volumes (Tasks)
10. RAID-1 (Mirror) Volumes (Overview)
11. RAID-1 (Mirror) Volumes (Tasks)
12. Soft Partitions (Overview)
16. Hot Spare Pools (Overview)
20. Maintaining Solaris Volume Manager (Tasks)
21. Best Practices for Solaris Volume Manager
22. Top-Down Volume Creation (Overview)
23. Top-Down Volume Creation (Tasks)
24. Monitoring and Error Reporting (Tasks)
25. Troubleshooting Solaris Volume Manager (Tasks)
A. Important Solaris Volume Manager Files
B. Solaris Volume Manager Quick Reference
The Solaris Volume Manager state database contains configuration and status information for all volumes, hot spares, and disk sets. Solaris Volume Manager maintains multiple copies (replicas) of the state database to provide redundancy and to prevent the database from being corrupted during a system crash (at most, only one database copy will be corrupted).
The state database replicas ensure that the data in the state database is always valid. When the state database is updated, each state database replica is also updated. The updates occur one at a time (to protect against corrupting all updates if the system crashes).
If your system loses a state database replica, Solaris Volume Manager must figure out which state database replicas still contain valid data. Solaris Volume Manager determines this information by using a majority consensus algorithm. This algorithm requires that a majority (half + 1) of the state database replicas be available and in agreement before any of them are considered valid. Because of the requirements of the majority consensus algorithm, you must create at least three state database replicas when you set up your disk configuration. A consensus can be reached as long as at least two of the three state database replicas are available.
During booting, Solaris Volume Manager ignores corrupted state database replicas. In some cases, Solaris Volume Manager tries to rewrite state database replicas that are corrupted. Otherwise, they are ignored until you repair them. If a state database replica becomes corrupted because its underlying slice encountered an error, you need to repair or replace the slice and then enable the replica.
![]() | Caution - Do not place state database replicas on fabric-attached storage, SANs, or other storage that is not directly attached to the system. You might not be able to boot Solaris Volume Manager. Replicas must be on storage devices that are available at the same point in the boot process as traditional SCSI or IDE drives. |
If all state database replicas are lost, you could, in theory, lose all data that is stored on your Solaris Volume Manager volumes. For this reason, it is good practice to create enough state database replicas on separate drives and across controllers to prevent catastrophic failure. It is also wise to save your initial Solaris Volume Manager configuration information, as well as your disk partition information.
See Chapter 7, State Database (Tasks) for information on adding additional state database replicas to the system. See Recovering From State Database Replica Failures for information on recovering when state database replicas are lost.
State database replicas are also used for RAID-1 volume resynchronization regions. Too few state database replicas relative to the number of mirrors might cause replica I/O to impact RAID-1 volume performance. That is, if you have a large number of mirrors, make sure that you have at least two state database replicas per RAID-1 volume, up to the maximum of 50 replicas per disk set.
By default each state database replica for volumes, the local set and for disk sets occupies 4 Mbytes (8192 disk sectors) of disk storage. The default size of a state database replica for a multi-owner disk set is 16 Mbytes.
Replicas can be stored on the following devices:
A dedicated local disk partition
A local partition that will be part of a volume
A local partition that will be part of a UFS logging device
Replicas cannot be stored on the root (/), swap, or /usr slices. Nor can replicas be stored on slices that contain existing file systems or data. After the replicas have been stored, volumes or file systems can be placed on the same slice.