Database Requirements

This topic describes the database requirements for CDP Private Cloud Base.

Please see the Cloudera Support Matrix for detailed information about supported databases based on the CDP and Cloudera Manager versions.

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.

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:

CDP does not support Percona for MySQL as a backend database for the Hive Metastore (HMS).
Use the appropriate UTF8 encoding for Metastore, Oozie, Hive, and Hue.
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.

Upgrading Cloudera Manager and the Cloudera Manager database

When upgrading Cloudera Manager, there may be a minimum version requirement for the database server.

Ensure that the Cloudera Manager database server is upgraded to at least this minimum requirement prior to starting the new version of Cloudera Manager for the first time.

Stop Cloudera Manager Server service.
Upgrade the Cloudera Manager RPMs.
Upgrade the Cloudera Manager database server version.
Start the Cloudera Manager.

Upgrading CDP and the CDP Services databases

When upgrading CDP to a new version, the new version of CDP may have a minimum version requirement for the database server which holds services metadata.

If the database server needs to be upgraded, follow this process:

Stop CDP services which depend on the database server, or alternatively, stop the entire cluster.
Upgrade the database server version.
Upgrade CDP using Cloudera Manager.
Start the stopped services, or the entire cluster.
When a database server upgrade is required, it is not possible to perform a rolling upgrade of the cluster.

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.