@jkoral although the troubleshooting makes sense, we generally see the "Caused by: com.mysql.cj.exceptions.InvalidConnectionAttributeException: The server time zone value 'CDT' is unrecognized or represents more than one time zone" when there's a timezone conflict between the Cloudera Manager Server host and the MySQL server (not the host, but the MySQL timezone in /etc/my.cnf), is set to the CDT timezone, causing the conflict. To resolve it, we generally ensure both the CM server and the MySQL server have the same timezone. Here's some suggested troubleshooting: Check the timezone setting of the MySQL server in the /etc/my.cnf file. Ensure the MySQL server's timezone matches the server's timezone setting. Modify the timezone setting in the configuration file if it does not match. Restart the MySQL server to apply the changes. Restart the Cloudera Manager Server and verify that it starts up without issues. A product improvement task will be created to update the JDBC driver to use the server's timezone setting when establishing a connection. Now, on the other hand, here's our documentation concerning the JDBC drivers along with the supported versions: https://docs.cloudera.com/cdp-private-cloud-upgrade/latest/upgrade-hdp/topics/amb-install-mysql-jdbc.html  You can choose the operating system version, JDBC Driver and cluster version from the dropdowns. ... View more

@naymar after setting up the replication jobs, they should be visible in the CM UI. In CM version 6.x and 5.15.x, under Backup > Replication Schedules and for CM 7, under  Replication > Replication Policies. They're also stored in the backend DB. You can check them with: SELECT COMMAND_NAME,SERVICE_ID,START_TIME,DISPLAY_NAME,DESCRIPTION FROM COMMAND_SCHEDULES; If you want to check the arguments you set: SELECT COMMAND_NAME,SERVICE_ID,COMMAND_ARGUMENTS,START_TIME,DISPLAY_NAME,DESCRIPTION FROM COMMAND_SCHEDULES;  If you want to check only the HDFS replication schedules: SELECT COMMAND_NAME,SERVICE_ID,COMMAND_ARGUMENTS,START_TIME,DISPLAY_NAME,DESCRIPTION FROM COMMAND_SCHEDULES WHERE COMMAND_NAME='HdfsReplicationCommand';   On the below TSB article, you can refer yourself to some of the API used to fetch the replications from the CM UI (:warning: NOTE: the TSB will prompt you to enter your Cloudera credentials) https://my.cloudera.com/knowledge/TSB-2024-734-The-Replication-Policies-page-of-Replication?id=382627  For instance, using the URL example, the following curl command should return the history of policies:   curl -X GET “http://hostname:7180/api/v49/clusters/Cluster%201/services/HIVE-1/replications?view=summary" -H "accept: application/json"   Also, the below API should give a you a list of all the replications setup in the CM http[s]://hostname[:port]/api/v49/clusters/<clusterName>/services/<serviceName>/replications ... View more

@Deepak_Unravel is the unravel parcel deployed via CSD? It might not be compatible with the CM version you're using and the parcel.json or the manifest.json might not be working as expected. Can you check if you have a "conflicts" entry in your parcel.json file? If so, can you try: 1.) Stopping a CM agent in the cdpvm1.unraveldata.com host 2.) In the same node where you stopped the CM agent, edit the parcel.json file and remove the "conflicts" 3.) Start the agent and check if the parcel is deployed. ... View more

@hanumanth thanks for reaching out Cloudera Community. If the backend postgres database has been compromised, a restore would have to be done to be back in a working state. Without a backup, it won't be possible. I encourage you to please check thoroughly with your team, as most of the time, even when working with support, we create backups of the database - also, some database teams have backup policies. You can also check if backups have been done by checking the bash history. Once a database backup has been located, stop the CM server, restore and start back the CM Server, but without a backup, going back to a working state won't be possible. I hope this helps. ... View more

@sharonsony thanks for the copy/pasting the log excerpt. From the above output, we cannot spot any datanode addition activity. We do see though, that the agent fails to communicate to the supervisord getting connection refused:     [10/Nov/2023 13:52:40 +0000] 8759 MainThread agent ERROR Failed to connect to previous supervisor. Traceback (most recent call last): File "/usr/lib64/cmf/agent/build/env/lib/python2.7/site-packages/cmf-5.16.1-py2.7.egg/cmf/agent.py", line 2146, in find_or_start_supervisor self.get_supervisor_process_info() File "/usr/lib64/cmf/agent/build/env/lib/python2.7/site-packages/cmf-5.16.1-py2.7.egg/cmf/agent.py", line 2290, in get_supervisor_process_info self.identifier = self.supervisor_client.supervisor.getIdentification() File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request verbose=self.__verbose File "/usr/lib64/cmf/agent/build/env/lib/python2.7/site-packages/supervisor-3.0-py2.7.egg/supervisor/xmlrpc.py", line 460, in request self.connection.request('POST', handler, request_body, self.headers) File "/usr/lib64/python2.7/httplib.py", line 1041, in request self._send_request(method, url, body, headers) File "/usr/lib64/python2.7/httplib.py", line 1075, in _send_request self.endheaders(body) File "/usr/lib64/python2.7/httplib.py", line 1037, in endheaders self._send_output(message_body) File "/usr/lib64/python2.7/httplib.py", line 881, in _send_output self.send(msg) File "/usr/lib64/python2.7/httplib.py", line 843, in send self.connect() File "/usr/lib64/python2.7/httplib.py", line 824, in connect self.timeout, self.source_address) File "/usr/lib64/python2.7/socket.py", line 571, in create_connection raise err error: [Errno 111] Connection refused    I think you can try to hard-stop and restart the agents (since you're in CDH 5.16.x): Starting, Stopping, and Restarting Cloudera Manager Agents | 5.16.x | Cloudera Documentation   Warning: The hard_stop and hard_restart commands kill all running managed service processes on the host(s) where the command is run. ... View more

@sharonsony when replying to the messages, you should see a section below where you read "Drag and drop here or brow files to attach", in there, you should attach the full /var/log/cloudera-scm-agent/cloudera-scm-agent.log file for investigation. ... View more

@sharonsony the above log snippet is not relevant.  Please retry the operation (add datanode) and attach /var/log/cloudera-scm-agent/cloudera-scm-agent.log for revision. ... View more

@ManasP this is a known issue in the CM Version you're using. The workaround is to add an "empty" cluster (sort of a placeholder) to be then able to add the services in it.   You can use something like:   curl -v -u admin:admin -X PUT "http://cmServerFQND:7180/api/v49/cm/service" -H "accept: application/json" -H "Content-Type: application/json" -d "{}"   Hope it helps! ... View more

Hi @cloudera-a ,   Since the CM server ships with embedded PostgreSQL DB, our docs point to migrating from PSQL to MySQL or even Oracle, but not the other way around.   For instance, here's our doc to migrate from a PostgreSQL Database Server to a MySQL/Oracle Database Server [0].   You could make use of a 3rd party tool to achieve what you're trying to do, but this won't be encouraged by Cloudera, as this could easily lead to an unstable cluster.   [0] = Migrate from the Cloudera Manager External PostgreSQL Database Server to a MySQL/Oracle Database Server ... View more