Overview of HA for
GoldenGate
The objective of this chapter
is to use Oracle GoldenGate 12c two-node configuration for
building high availability infrastructure to support
business applications maximum availability by minimizing
disruption due to system failure. Oracle customers have been
implementing Oracle real application clusters (RAC) for high
availability and Oracle Data Guard (DG) for disaster
recovery.
The two solutions co-exist
for the best continuity. RAC and DG require an advanced
level of skills to implement and manage together. RAC and DG
are the major components of Oracle Maximum Availability
Architecture (MAA) for sites running mission critical
systems and requiring a maximum level of scalability, data
availability, and data protection. For applications that may
compromise RAC embedded scalability and DG fast start
failover, Oracle GoldenGate achieves the requirements for
business continuity with a sustainable budget, operational
cost, and reasonable infrastructure complexity.
The flexibility of Oracle
GoldenGate advanced configuration enables the software to provide business
continuity similar to RAC and DG combined using
active-passive and active-active bi-directional topology
architecture. However, this specific implementation is not
out-of-the-box and requires a considerable level of Oracle
GoldenGate and database experience in respect to the
database design and applications coding.
This chapter implements
Oracle GoldenGate for business continuity using similarly
designed architecture for deploying:
§
Active-Passive Model for
Disaster Recovery (DR)
§
Active-Active Model for High
Availability (HA)
Unlike Oracle Real
Application Clusters (RAC) in terms of
scalability,
Oracle GoldenGate does not promote the built-in scalability
provided by RAC, which is
the core function of RAC to
support linearly increasing transactions volume. When
scalability is an important
element of the application, sufficient evaluation is
necessary before deploying Oracle GoldenGate for high
availability. Also, with Oracle Real Application Clusters
(RAC), increasing the number of nodes delivers higher
scalability. However, Oracle GoldenGate encourages the use
of two-node architecture only for high-availability. This is
recommended to avoid complex data conflict detection and
resolutions in an active-active bi-directional topology.
For an enterprise, Oracle GoldenGate does
not replace RAC or DG, rather it is implemented to
complement and integrate with the Oracle clusterware and
Oracle physical standby database. Refer to Chapter 12 to
learn more about integrating Oracle GoldenGate with RAC and
DG.
For sites running the Oracle
Database Standard Edition, Oracle GoldenGate is an
attractive option for implementing high availability (HA)
and disaster recovery (DR). The option is cost-effective and
highly suitable for in-house developed applications,
but needs to be developed
from the group-up so that the applications are
replication-aware. In deploying Oracle GoldenGate on
bi-directional active-active topology, the challenge is to handle
data conflicts which are discussed using the following:
§
Data and Applications
Segmentation
§
Oracle GoldenGate Built-In
Conflict Detection and Resolution (CDR)
§
Custom Conflict Detection and
Resolution using PL/SQL Sub-Programs Development
§
Oracle Virtual Private
Database (VPD)
Summary
The use of Oracle GoldenGate
12c for business continuity has advantages and disadvantages
in using the same bi-directional topology architecture to
build the foundation for a disaster recovery site and high
availability on supported platforms.
When using Oracle GoldenGate
for disaster recovery (DR), the major point of discussion is
unsupported data types. For applications not using any of
the unsupported data types, Oracle GoldenGate is an option
for disaster recovery solutions. Switchover and failover
from the primary system to the live standby system and vice
versa is an interactive process and requires manual
execution of commands or scripts.
The downtime associated with
switchover and failover is very low and varies from site-to-site. The chapter has
illustrated the following:
§
Planned moving of users from
primary to live standby system for switchover
§
Planned moving of users back
from live standby to primary system for switchover
§
Unplanned moving of users
from primary to live standby system for failover
§
Unplanned moving of users
back from live standby to primary system for failover
When using Oracle GoldenGate
for high availability (HA), detailed analysis is carried out
to evaluate Oracle GoldenGate capability of achieving the
level of scalability for low-high transactions volume. When
Oracle GoldenGate is deployed from the ground up, the
applications become replication-aware (transparent
replication) which promote Oracle GoldenGate for a high
availability platform. However, deploying Oracle GoldenGate
at a later stage results in the challenge of handling data
conflict.
This chapter has discussed
and illustrated techniques of handling data conflicts using:
§
Data and Applications
Segmentation
§
Oracle GoldenGate Built-In
Conflict Detection and Resolution (CDR)
§
Develop PL/SQL Sub-Programs
and implement callout using SQLEXEC
§
Oracle Virtual Private
Database (VPD) for total segmentation
Throughout the chapter, a
two-node bi-directional topology architecture is
demonstrated. A three-node topology architecture,
multi-master brings challenges and should be
carefully qualified for
disaster recovery and high availability solutions. Oracle
GoldenGate considerations, in respect of disaster recovery
and high availability, are discussed to lead to a sound decision and
minimize the impact of post-deployment changes.
The chapter also compared
Oracle GoldenGate with Oracle Real Application Clusters
(RAC) and Oracle Data Guard (DG). It was made clear, for an
enterprise, Oracle GoldenGate complements RAC and DG rather
than replaces them.
GoldenGate High Availability
Oracle High Availability has
been always associated with Oracle Real Application Clusters
(RAC), where within the same data center, multiple tightly
coupled servers (nodes) access the same database. Another
advanced architecture of RAC is Extended RAC, where nodes
are loosely coupled and spread across two or more data
centers. Figure 5-12 compares the high availability of
Oracle GoldenGate and Extended RAC.
The upper part of Figure 5-12
is Oracle GoldenGate configured using an active-active
bi-directional topology
model. Over the TCP/IP network, data flows from the site A
(node-1) to site B (node-2) and vice versa. The self-evident
advantage of this solution is the unlimited distance between
node-1 and node-2. The drawback is the chance of scalability
and data conflict handling.
However, because the data is
delivered in canonical format for a well-developed
application, node-1 and node-2 may use different platforms.
For example node-1 is Oracle Database 11g on Oracle Solaris
while node-2 is Oracle Database 11g on Oracle Linux. Avoid
heterogeneous database architecture for a high availability
solution, unless the applications developed to support all
database types transparently.
The lower part of Figure 5-12
shows Oracle Extended RAC. The databases are mirrored using
dense wavelength division multiplexing (DWDM) over a dark
fiber link. This enables always in-sync copies of the
database. The self-evident advantage is out-of-box
scalability and high availability. The drawback is the
distance limitation between site A and site B for up to 100
kilometers and cost-factor.
Figure 5-12: Comparison of 2-Node Oracle
GoldenGate and Extended RAC
When using Oracle GoldenGate
to implement a high availability platform, it is configured
as an
active-active bi-directional topology model. The
source system
(node-1) and target system
(node-2) are available for user connections. Users may
explicitly connect to either system based on predetermined
attributes such as location, range of TCP/IP address,
built-in application context, etc.
Implicit connections will be
based on database and/or system workload. Users requests are
routed to the system with minimal workload. This provides
connection time workload evaluation to distribute database
sessions across both systems. Figure 5-12 shows an implicit
form of handling users connections. The database load
balancer evaluates the preferred database, which is the
database with lesser workload. Then, send the request to the
application server which has its own HTTP load balancer. For
more details regarding a high availability load balancer,
refer to Figure 5-2.
Figure
5-13: Load Balancing on Bi-Directional Topology
Applications running on Windows such as Oracle for .NET
employ Oracle SQLNET to connect to the database. Whereas
Java desktop applications employs JDBC drivers to connect to
the database. For this type of applications, HTTP Servers
are eliminated, the client applications establish stateful
types of database connections.
|
|
 |
|
Oracle GoldenGate 12c
The above is an excerpt from the upcoming
12c book
Oracle GoldenGate 12c: A Hands-on Guide to Data
Replication & Integration using Oracle & SQL Server.
|
|
|
| |
|
Burleson is the American Team
Note:
This Oracle
documentation was created as a support and Oracle training reference for use by our
DBA performance tuning consulting professionals.
Feel free to ask questions on our
Oracle forum.
Verify
experience!
Anyone
considering using the services of an Oracle support expert should
independently investigate their credentials and experience, and not rely on
advertisements and self-proclaimed expertise. All legitimate Oracle experts
publish
their Oracle
qualifications.
Errata?
Oracle technology is changing and we
strive to update our BC Oracle support information. If you find an error
or have a suggestion for improving our content, we would appreciate your
feedback. Just
e-mail:
 and include the URL for the page.
Copyright © 1996 - 2020
All rights reserved by
Burleson
Oracle ®
is the registered trademark of Oracle Corporation.
|
|
