About the Solaris Volume Manager State
Database and Replicas

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 take place 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. It is because of this
majority consensus algorithm that 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 will 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. 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, and 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 a total of at least
two state database replicas per RAID 1 volume, up to the maximum of 50 replicas
per disk set.

Each state database replica occupies 4 Mbytes (8192 disk sectors) of
disk storage by default. 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

Note –

Replicas cannot be stored on the root (/), swap, or /usr slices, or 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.

Note –

Replicas cannot be stored on fabric-attached storage, SANs, or
other storage that is not directly attached to the system. Replicas must be
on storage devices that are available at the same point in the boot process
as traditional SCSI or IDE drives.