Member since
10-17-2019
505
Posts
4
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1314 | 11-14-2023 08:53 AM |
03-05-2024
05:56 AM
1 Kudo
@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
12-28-2023
01:21 PM
@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
12-14-2023
06:51 AM
@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
11-20-2023
07:27 AM
@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
11-16-2023
07:25 AM
@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
11-15-2023
09:23 AM
@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
11-14-2023
08:53 AM
@truonghongminh the issue your having is a known bug in the Cloudera Manager server. The workaround is basically running an API call against the CM server to create an empty Mgmt Cluster to then install the Mgmt Services. Please run the below API call to create an empty Cloudera Management Service cluster: curl -X PUT -u admin:admin_pwd "http://your-cm-server.com:7180/api/v49/cm/service" -H "Content-Type: application/json" -d "{\"displayName\": \"Cloudera Management Service\"}" Right after, please install the desired Mgmt services in it.
... View more
08-03-2023
11:30 AM
1 Kudo
@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
10-06-2021
07:07 AM
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
02-09-2021
10:18 AM
Hi @Entraux34, This is not currently possible in Ranger. In Ranger Admin UI, you could sort the results and that way you could get only the Denied, but auditing only the Denied won't be possible. I hope this helps.
... View more