MAA Diamond Reference Architecture Overview
The MAA Diamond reference architecture, or Extreme Availability, delivers near-zero Recovery Time Objective(RTO, or downtime incurred by any outage) and potentially zero or near-zero Recovery Point Objective (RPO, or data loss potential).
Description of the illustration maa_overview.png
The MAA Diamond reference architecture ensures:
-
RTO = zero or near-zero for all local failures using the Oracle Exadata Database Machine platform with its inherent Oracle RAC, full-stack redundancy, and failover capabilities. The Exadata platform is essential for achieving the lowest application brownouts and meeting near-zero brownouts for local failures, providing additional data protection, and enabling intelligent sick-failure prevention, detection, and repair. SeeMAA Platinum and MAA Diamond: Oracle RAC and Exadata.
-
RTO = zero or near-zero for disasters such as database, cluster, data center, or regional failures, which is achieved by redirecting the application to an active Oracle GoldenGate source or target.
-
Zero downtime maintenance for software and hardware updates using Oracle RAC and Exadata Database Machine platform.
-
Zero downtime database upgrade or application upgrade by redirecting the application to an upgraded Oracle GoldenGate source or target database.
-
RPO can be zero or near-zero by adjusting Oracle Data Guard protection mode and redo transport (SYNC, FAST SYNC, FAR SYNC, or ASYNC). To achieve zero data loss, use Data Guard Fast-Start Failover (FSFO) with Maximum Availability protection mode. To bound data loss and achieve near zero RPO while eliminating any performance impact on the primary database, use Data Guard Fast-Start Failover with Maximum Performance protection mode and setting
FastStartFailoverLagLimit. With automatic Data Guard failover, GoldenGate replicas resynchronize quickly and consistently after any database failure.
Table 1 MAA Diamond Outage Matrix
| Unplanned Outage | RTO | RPO |
|---|---|---|
| Recoverable node or instance failure | Single digit seconds1 | Zero |
| Disasters, including corruptions and regional failures | Zero2 | Enabling Data Guard Fast-Start Failover (FSFO) is a requirement to achieve low RPO.
|
| Planned Maintenance | RTO | RPO |
| Most common software and hardware updates | Zero1 | Zero |
| Major database upgrade or application upgrade | Zero2 | Zero |
1To achieve zero downtime or lowest impact for online processing, apply Continuous Availability for Applications. For long-running transactions, such as batch operations, it is recommended that you defer them outside the planned maintenance window.
2Application failover is customized or managed with Global Data Services. For long-running transactions, such as batch operations, it is recommended that you defer them outside the planned maintenance window.
Enabling features of the Diamond MAA solution include:
-
Oracle AI Database 26ai Oracle Real Application Clusters and Exadata Database Machine Platform Exadata Database Machine Platform can be on-premises, in Oracle Cloud Infrastructure, or in Oracle’s hyperscale cloud partners, such as the case with Exadata Database Service on Dedicated Infrastructure (ExaDB-D), or Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C) for the source and target databases.
-
Oracle AI Database 26ai Oracle Active Data Guard with Fast-Start Failover to bound data loss and automatic failover to the standby in case of database, cluster, or data center failures. The standby databases are typically in separate Fault Domains (FDs) with separate power supplies, residing in separate data centers, Availability Domains (ADs), or Availability Zones (AZs), with independent power and network. The standby databases can also reside in different regions if regional fault isolation is required.
-
Oracle GoldenGate 26ai enables two active read-write database systems that applications can fail over to immediately after database, cluster, or regional failures, or during planned outages such as database or application upgrades. The source and target databases on which Oracle GoldenGate replication is occurring can reside in the same region, across ADs, or across regions.
-
Oracle 26ai provides AI capabilities and MAA optimizations for higher availability, disaster recovery, data protection and automation.
The MAA Diamond architecture is illustrated in the image below, where two “active read-write” primary databases, or source or target databases, reside in separate regions. Oracle GoldenGate replication occurs between the source and target databases between primary and remote regions. A standby database protects each primary database in another AD within the same region or across regions.
With Data Guard Fast-Start Failover (FSFO), the standby database automatically becomes the new primary after a primary database, cluster, or AD failure. With MAA Oracle GoldenGate configuration best practices implemented, replication resumes automatically between the source and target databases after any Data Guard role transition. Each database resides on an Exadata platform with its built-in Real Application Cluster, system and storage redundancy, and the lowest possible brownout failover capabilities.
Figure 1: MAA Diamond Reference Architecture
Description of the illustration platinum-architecture-general.png
MAA GoldenGate Hub
When setting up a Diamond MAA architecture, the administrator can install Oracle GoldenGate 26ai on each potential source or target database, or create an Oracle GoldenGate hub independent of the database servers.
The MAA Oracle GoldenGate hub, shown in the following image, provides the following advantages:
-
Offloads and simplifies Oracle GoldenGate software installation, configuration, and life cycle management from source and target Exadata database systems.
-
Reduces Oracle GoldenGate resource impact on the source and target database systems.
-
Provides high availability by configuring a 2-node cluster server for fast and simple failover, and disaster recovery by leveraging ACFS replication to another identical GoldenGate hub server on a separate 2-node cluster server.
-
Consolidates Oracle GoldenGate configurations and software deployment for multiple independent MAA Diamond or Oracle GoldenGate architectures. Figure 2: MAA Oracle GoldenGate Hub
Description of the illustration maa-ogg-hub-b.png
An example of an MAA Oracle GoldenGate hub with MAA Diamond architecture is shown in the image below. Each hub is a 2-node cluster providing local high availability and, for additional protection, uses ACFS replication to another hub, typically deployed across Availability Domains (ADs) or across regions.
Figure 3: MAA Diamond with Oracle GoldenGate Hub
Description of the illustration platinum-architecture-ogghub.png
How to Implement the MAA Diamond Solution
To achieve an MAA Diamond solution, review and leverage the technical papers and documentation referenced in the following steps.
Step 1 - Choose Oracle GoldenGate Deployment
Decide between implementing the recommended MAA Oracle GoldenGate Hub solution, or setting up Oracle GoldenGate directly on Exadata database servers.
| GoldenGate Deployment | Guidance |
|---|---|
| MAA Oracle GoldenGate Hub | This is the recommended deployment configuration Deploy MAA Oracle GoldenGate Hub on Exadata Database Service in Oracle Cloud
Deploy MAA Oracle GoldenGate Hub on Exadata On-Premises |
| Oracle GoldenGate 26ai | Deploy Oracle GoldenGate on Exadata Database Service in Oracle Cloud or Oracle Multi-Cloud
Deploy Oracle GoldenGate on Exadata On-Premises |
Step 2 - Configure Automatic Conflict Detection and Resolution
Bidirectional replication requires conflict detection and resolution. Oracle MAA guides developers and administrators when designing an active-active distributed database architecture using Oracle GoldenGate, where data conflicts may occur between GoldenGate replicas. See Oracle GoldenGate Active-Active Guidance for Developers and Administrators for additional details.
Step 3 - Implement Application Failover
Oracle Global Data Services enables fault-tolerant database services to be deployed and centrally managed across a set of replicated databases, supporting seamless inter-database service failover across any data center and providing higher application availability. See Oracle Global Data Services Best Practices for additional details.
Alternatively, use your own custom application routing to redirect after database or site failure.