hundreds of milliseconds. Asynchronous
replication latency presents two problems
in active/active networks which must be
understood – potential data loss and data
collisions.
Potential Data Loss: Should the source
system fail, any data in the replication
pipeline that represents source database
updates may not make it to the target data-
base. Thus, a subsecond of data may be
lost. Should the source system be recov-
ered, these changes can be resurrected
from the change queue. However, if the
source system is destroyed or its database
is damaged, these changes will be gone
forever.
OpsPlanner™
A Cost-Effective, and Easy-to-Use
Business Continuity Management Solution
Planning Makes Sense...
Prepare for
the Worst
The OpsPlanner™ BCM tool can
help your business prepare for any
type of emergency, including your
worst case scenario. You must
protect your organization from costly
and unnecessary losses due to an
unexpected business disruption.
OpsPlanner is being successfully used
by a wide range of large and small
commercial organizations and mission-critical government agencies to help
prepare for, manage, and recover from
any potential risks.
“Every business should have a plan.”
- U.S. Department of Homeland Security
OpsPlanner is a comprehensive,
web-based, fully integrated tool that
combines state of the art Planning,
Incident Management, and Automated
Notification, with the most advanced
Business Impact Analysis module
available. This powerful Business
Continuity Management Solution has
been chosen by industry and government
to help reduce risks, comply with
regulations, and improve preparedness.
Paradigm Solutions International, Inc.’s
(PSI’s) Certified Business Continuity
Professionals (CBCP) can help assess
your organizational risks and develop a
Plan that is right for your business.
Take steps now to help safeguard your
organization, employees and prevent
a major disruption that could severely
impact your customers and shut down
critical business functions. Planning
makes sense. Prepare Now.
Call for a Free Demonstration.
Visit: OpsPlanner.com, E-mail: Info@ParadigmSi.com, or Call: 800-558-9568
Data Collisions: Because the application is running in multiple nodes and
because there is a delay in updating the
target databases, there is a possibility
that the application instance in two different nodes will update the same data
object at about the same time (within the
replication interval). Neither node knows
that the other node is also updating the
same data object. Therefore, each will
replicate its change to the other node and
will overwrite that node’s change. Now,
the databases are different and both are
wrong.
In some applications, data collisions
are not possible (for instance, an insert-only application) or can be tolerated
(a collision will be corrected by a later
update). Data collisions can be avoided
if the database can be partitioned so that
only one node has permission to update
a given partition. If data collisions can
occur and are not acceptable, they must
be detected and resolved. Many of today’s
replication engines provide data collision
detection and can resolve data collisions
via rules bound into them (for instance,
accept the latest change). If a collision
is detected and cannot be automatically
resolved, it may have to be resolved manually.
Synchronous Replication
The problems of data loss and data collisions are avoided if synchronous replication is used. With synchronous replication,
either changes to all data object copies
within the scope of a transaction are made
or none are. The synchronous replication
engine accomplishes this by first acquiring
locks on all data object copies across the
application network before applying any
changes. It then knows that it can reliably
change all of the copies of the data object
simultaneously.
Because no change is made to a data
object unless all copies of that data object
can be changed, there is no data loss. If the
source system fails, no changes are made
either to the source system or to the remote
target systems. Furthermore, since a data
object cannot be changed unless the replication engine is holding a lock on it, it
is not possible for two applications remote
