Filter
Top Products
Disaster Tolerance and Recovery in a Serviceguard Cluster
Disaster Tolerant Architecture Guidelines
Chapter 144
• If the primary database fails and is corrupt, which results in the
replica taking over, then the process for restoring the primary
database so that it can be used as the replica is complex. This often
involves recreating the database and doing a database dump from
the replica.
• Applications often have to be modified to work in an environment
that uses a logical replication database. Logic errors in applications
or in the RDBMS code itself that cause database corruption will be
replicated to remote sites. This is also an issue with physical
replication.
• Most logical replication methods do not support personality
swapping, which is the ability after a failure to allow the secondary
site to become the primary and the original primary to become the
new secondary site. This capability can provide increased up time.
Ideal Data Replication
The ideal disaster tolerant architecture, if budgets allow, is the following
combination:
• For performance and data currency—physical data replication.
• For data consistency—either a second physical data replication as a
point-in-time snapshot or logical data replication, which would only
be used in the cases where the primary physical replica was corrupt.
Using Alternative Power Sources
In a high-availability cluster, redundancy is applied to cluster
components, such as multiple paths to storage, redundant network cards,
power supplies, and disks. In disaster tolerant architectures another
level of protection is required for these redundancies.
Each data center that houses part of a disaster tolerant cluster should be
supplied with power from a different circuit. In addition to a standard
UPS (uninterrupted power supply), each node in a disaster tolerant
cluster should be on a separate power circuit; see Figure 1-9.