Database Requirements

Table 1. Database Support for CDP Private Cloud Base 7.1.3
Database Type	Supported Version
MySQL	5.7 Not supported for DAS.
MariaDB	10.2 Not supported for DAS.
PostgreSQL	10 For use with DAS only: 9.6, 10, or 12
Oracle DB	12.2.0.1 (Oracle 12c Release 2) Not supported for DAS. Not supported for HDP to CDP Private Cloud Base 7.1 upgrades. 19.3.0.0 (Oracle 19c) Supported only for upgrades from Cloudera Manager 6.3 to Cloudera Manager 7.1.3 in deployments where only CDH 5 clusters are managed by Cloudera Manager. You cannot upgrade CDH 5 to Cloudera Runtime 7.1.3 if the cluster is using Oracle 19.

Table 2. Database Support for CDP Private Cloud Base 7.1.2
Database Type	Supported Version
MySQL	5.7 Not supported for DAS.
MariaDB	10.2 Not supported for DAS.
PostgreSQL	10 For use with DAS only: 9.6, 10, or 12
Oracle DB	12.2.0.1 (Oracle 12c Release 2) Not supported for DAS. Not supported for HDP to CDP Private Cloud Base 7.1 upgrades. 19.3.0.0 (Oracle 19c) Supported only for upgrades from Cloudera Manager 6.3 to Cloudera Manager 7.12 in deployments where only CDH 5 clusters are managed by Cloudera Manager. You cannot upgrade CDH 5 to Cloudera Runtime 7.1.2 if the cluster is using Oracle 19.

Table 3. Database Support for CDP Private Cloud Base 7.1.1
Database Type	Supported Version
MySQL	5.7 Not supported for DAS.
MariaDB	10.2 Not supported for DAS.
PostgreSQL	10 For use with DAS only: 9.6, 10, or 12 CDSW requires PostgreSQL 9.2
Oracle DB	12.2.0.1 (Oracle 12c Release 2) Supported for upgrades to Cloudera Manager 7.1.1 and higher, when Cloudera Manager is managing a CDH 5 cluster. Supported for new installations. Not supported for upgrades from CDH 5. Not supported for DAS. 19.3.0.0 (Oracle 19c) Supported only for upgrades from Cloudera Manager 6.3 to Cloudera Manager 7.1.1 or 7.12 in deployments where only CDH 5 clusters are managed by Cloudera Manager. You cannot upgrade CDH 5 to Cloudera Runtime 7.1.1 or 7.1.2 if the cluster is using Oracle 19.

Table 4. Database Support for CDP Private Cloud Base 7.0.3
Database Type	Supported Version
PostgreSQL	10 For use with DAS only: 9.6, 10, or 12

Cloudera Manager and Runtime come packaged with an embedded PostgreSQL database for use in non-production environments. The embedded PostgreSQL database is not supported in production environments. For production environments, you must configure your cluster to use dedicated external databases. You must ensure latency between Cloudera Manager server and the database is < 10 ms. You can verify the latency with a simple SQL command from your Cloudera Manager server host to the database. Start your database's command line client tool and connect to the Cloudera Manager database. Run the follwoing SQL command:

SELECT 1;

After installing a database, upgrade to the latest patch and apply appropriate updates. Available updates may be specific to the operating system on which it is installed.

Notes:

Cloudera recommends that for most purposes you use the default versions of databases that correspond to the operating system of your cluster nodes. Refer to the operating system's documentation to verify support if you choose to use a database other than the default. Note that Hue requires the default MySQL/MariaDB version (if used) of the operating system on which it is installed.
Data Analytics Studio requires PostgreSQL version 9.6, while RHEL 7.6 provides PostgreSQL 9.2.
Cloudera does not support using Derby database with Oozie. You can use it for testing or debugging purposes, but Cloudera does not recommend using it in production environments. This could cause failures while upgrading from CDH to CDP.
Use UTF8 encoding for all custom databases.
Oozie also supports UTF8MB4 character encoding out of box without any configuration change when the Oozie custom database is created with the encoding of UTF8MB4.
MySQL and MariaDB must use the MySQL utf8 encoding, not utf8mb4.
Ranger only supports the InnoDB engine for MySQL and MariaDB databases.
For MySQL 5.7, you must install the MySQL-shared-compat or MySQL-shared package. This is required for the Cloudera Manager Agent installation.
MySQL GTID-based replication is not supported.
Both the Community and Enterprise versions of MySQL are supported, as well as MySQL configured by the AWS RDS service.
Before upgrading from CDH 5 to CDH 6, check the value of the COMPATIBLE initialization parameter in the Oracle Database using the following SQL query:
```
SELECT name, value FROM v$parameter WHERE name = 'compatible'
```
The default value is 12.2.0. If the parameter has a different value, you can set it to the default as shown in the Oracle Database Upgrade Guide.
note
Before resetting the COMPATIBLE initialization parameter to its default value, make sure you consider the effects of this change can have on your system.

RDBMS High Availability Support🔗

Various Cloudera components rely on backing RDBMS services as critical infrastructure. You may require Cloudera components to support deployment in environments where RDBMS services are made highly-available. High availability (HA) solutions for RDBMS are implementation-specific, and can create constraints or behavioral changes in Cloudera components.

This section clarifies the support state and identifies known issues and limitations for HA deployments.

High Availability vs. Load Balancing🔗

Understanding the difference between HA and load balancing is important for Cloudera components, which are designed to assume services are provided by a single RDBMS instance. Load balancing distributes operations across multiple RDBMS services in parallel, while HA focuses on service continuity. Load balanced deployments are often used as part of HA strategies to overcome demands of monitoring and failover management in an HA environment. While less easier to implement, load-balanced deployments require applications tailored to the behavior and limitations of the particular technology.

Support Statement: Cloudera components are not designed for and do not support load balanced deployments of any kind. Any HA strategy involving multiple active RDBMS services must ensure all connections are routed to a single RDBMS service at any given time, regardless of vendor or HA implementation/technology.

General High Availability Support🔗

Cloudera supports various RDBMS options, each of which have multiple possible strategies to implement HA. Cloudera cannot reasonably test and certify on each strategy for each RDBMS. Cloudera expects HA solutions for RDBMS to be transparent to Cloudera software, and therefore are not supported and debugged by Cloudera. It is the responsibility of the customer to provision, configure, and manage the RDBMS HA deployment, so that Cloudera software behaves as it would when interfacing with a single, non-HA service. Cloudera will support and help customers troubleshoot issues when a cluster has HA enabled. While diagnosing database-related problems in Cloudera components, customers may be required to temporarily disable or bypass HA mechanisms for troubleshooting purposes. If an HA-related issue is found, it is the responsibility of the customer to engage with the database vendor so that a solution to that issue can be found.

Support Statement: Cloudera Support may require customers to temporarily bypass HA layers and connect directly to supported RDBMS back-ends to troubleshoot issues. Issues observed only when connected through HA layers are the responsibility of the customer DBA staff to resolve.