If the cloudera EDH was setup using the embedded Postgresql DB on the cluster, it is desired and often required to migrate to an external DB, especially for production environment. It is possible to migrate the cloudera management services databases (activity monitor, service monitor, report manager, host monitor) on an external Postgresql/MySQL DB from the cloudera manager console, but the scm-db would still use the embedded Postgresql.
The scm-db contains all the information about the services configured, their role assignments, configuration history, commands, users, and running processes. This is a relatively small database (<100 MB), and is the most important to back up and migrate. A monitoring database contains monitoring information about service and host status. In large clusters, this database can grow large.
The following steps guide through the process of migrating the scm-db from the embedded postgres to external mysql instance.
Helpful Vantage Point
1. Stop all cluster services including the Cloudera Manager monitoring services using the Cloudera Manager UIStop all CM agents by ssh-ing to the hosts and issuing `$ sudo service cloudera-scm-agent stop`
2. Backup the Cloudera Manager configuration by invoking the API call: /api/<version>/cm/deployment.
$ curl -v -u admin:admin http://manager_host:7180/api/<version>/cm/deployment > /home/user/deployment
Note: It is critical this file be retained and protected as it will be needed to re-import the functional configuration into the new database.
Obtain version with: http://manager_host:7180/api/version
3. Take a backup from the embedded postgres database or make a tarball of the /var/lib/cloudera-scm-server-db/ directory to a safe location. Either will accomplish the needed outcome. Also backup the contents of the directory /etc/cloudera-scm-server/*
#tar -cvf /home/user/cloudera-scm-server-db.tar .
#tar -cvf /home/user/cloudera-scm-server.tar .
4. On the server where the Cloudera Manager embedded database is running:
$ sudo service cloudera-scm-server stop
$ sudo service cloudera-scm-server-db stop
$ sudo chkconfig cloudera-scm-server-db off
5. Ensure the MYSQL JDBC connector is installed and in the correct location 
6. Install, configure, and start a new external MySQL database 
7. Create “temp” db and grants for “temp” db as documented in this “Example 1: Running the script when MySQL is installed on another host” 
#mysql -h mysql_hostname -u user -p
mysql> create database temp;
mysql> grant all on *.* to 'temp'@'%' identified by 'temp' with grant option;
$/usr/share/cmf/schema/scm_prepare_database.sh mysql -h mysql_hostname -u user -p --scm-host manager_host <scm_db_name> <scm_user> <scm_password>Note: run
$ /usr/share/cmf/schema/scm_prepare_database.shwith no arguments to get syntax assistance
9. When complete, start the Cloudera Manager server service:
$ sudo service cloudera-scm-server start
10. Log in to the Cloudera Manager web user interface and upload the enterprise license key.
11. Restart the scm-server
$ sudo service cloudera-scm-server restart
12. Restore the Cloudera Manager configuration by invoking the API call, from the command line of the manager node (from step 2), issue:
$ curl --upload-file /home/user/deployment -u admin:admin http://manager_host:7180/api/<version>/cm/deployment?deleteCurrentDeployment=true//add http header option
-H "Content-Type: application/json"if required
//verify that there are no errors, the command prints the api even on connection failure.
13. Log in to Cloudera Manager and verify configuration options are now all present, all services should now be available but stopped.
$ yum erase cloudera-manager-server-db
Note: Ensure the file /etc/cloudera-scm-server/db.propertiesis updated with new established database
15. If cloudera-scm-agents fail to communicate to the manager you will have to delete or move the cm_guid from /var/lib/cloudera-scm-agent/ and restart the agent.