XtremeCloud Data Grid-db

Managing Consistency, Availability, and Partition Tolerance (CAP)

Replication Tiers

The Xtremecloud Data Grid consists of three (3) different tiers of bi-directional replication (BDR) between Cloud Service Providers (CSP) or between a CSP and an on-premise private cloud.

The first tier is the cluster of relational databases that underlies our XtremeCloud applications. We refer to this tier as XtremeCloud Data Grid-db. The supported databases are shown in the XtremeCloud Applications Certification Matrix.

A common trait shared by all of the supported databases is that the replication provides for an eventually-consistent state between the sites containing the database nodes. Although some time lag does occur, there are a number of architectural decisions that can be made, and various implementation optimizations that can be employed, to reduce the time lag.

To further describe the characteristics of eventual consistency, we refer to Werner Vogel’s excellent article and summarize a key point here:

Eventual consistency. This is a specific form of weak consistency; the storage system guarantees that if no new updates are made to the object, eventually all accesses will return the last updated value. If no failures occur, the maximum size of the inconsistency window can be determined based on factors such as communication delays, the load on the system, and the number of replicas involved in the replication scheme. The most popular system that implements eventual consistency is DNS (Domain Name System). Updates to a name are distributed according to a configured pattern and in combination with time-controlled caches; eventually, all clients will see the update.

XtremeCloud applications all share one common trait. Any web client that connects to a specific Cloud Service Provider (CSP), remains on that CSP for the duration of the http session. We handle that through sticky sessions on both Cloudflare global load balancing and F5 Cloud Services DNS (Global Load Balancing Services). Any web (http) clients of XtremeCloud applications, on the same CSP, see immediate and consistent data in the application. If a user did log out and the subsequent ‘https’ connection was to the other CSP, it is possible that the data has not yet been replicated to the second CSP.

Quick Start Installation Guides

Some minimal steps are provided here to give you an idea of the complexity associated with manually installing the various database technologies. As a subscribed customer of Eupraxia Labs, you will be provided with Ansible scripts to install the databases at separate sites with minimal manual intervention. Once virtual machine (VM) or raw iron prerequisites are met for the database hosts, installation will normally complete in less than twenty minutes. This estimate will vary slight based on the number of hosts and the compute power (number of (v)CPUs, RAM, storage types/performance) of the hosts.

Oracle Database Installation

Oracle Installation Documentation

Official Oracle Database installation documentation can be found here.

Oracle DBMS Version

For XtremeCloud applications that require a relational database, a single-instance Oracle Database, RAC or RAC One Node are all supported; however, Oracle Enterprise Edition (EE) is required. The current certified Oracle version for XtremeCloud Single Sign-On (SSO) is Oracle 12c.

Additional Requirements

XtremeCloud multi-cloud applications employs Oracle GoldenGate (OGG) replication software. On top of Oracle 12c, there are the following database requirements:

  • The Oracle database must be in archivelog mode.
  • The database initialization parameter enable_goldengate_replication must be set to TRUE.
  • The parameter streams_pool_size must be set to 256 M or greater.

Oracle GoldenGate

XtremeCloud applications employs Oracle GoldenGate software for replication. GoldenGate is configured using its Classic Integrated Architecture. For XtremeCloud 3.0 applications , the current certified version of GoldenGate is Oracle GoldenGate 12.3.0.1.

GoldenGate software is most often installed directly on the database server. The GoldenGate software will exist in a separate ORACLE_HOME from the database software. Trail files are created both on the source and target database servers; so, additional file storage may be required.

Replication Topology

GoldenGate supports multiple replication topologies:

Oracle GoldenGate Replication (OGG) Topologies - click image to enlarge

The most common XtremeCloud replication configuration topology is bi-directional multi-master: one or more schemas are configured for bi-directional asynchronous replication.

Replication Software Deployment

It is assumed that the customer will already have one or more existing Oracle databases configured. If not, they will be configured using standard methods (e.g. runInstaller, dbca). Once the databases are configured, replication will be configured and started via supplied Ansible Playbooks.

Operational Considerations for Managing the Oracle-based Solutions

Monitoring

Alerting

Recovering from a split-brain scenario….

MySQL Database Installation

High level steps with references to MySQL Docs

Operational Considerations for Managing the MySQL-based Solution

Monitoring

Alerting

Recovering from a split-brain scenario….

MariaDB Database Installation

High level steps with references to MariaDB, Inc. Docs

Operational Considerations for Managing the MariaDB-based Solutions

Monitoring

Alerting

Recovering from a split-brain scenario….

PostgreSQL Database Installation

High level steps with references to 2nd Quadrant Docs

Operational Considerations for Managing the PostgreSQL-based Solutions

Monitoring

Alerting

Recovering from a split-brain scenario….