@Sandeep R It seems to be an SSL issue can you validate your LDAP, the port 636 is LDAPS and 389 is for LDAP. To enable LDAPS, you must install a certificate that meets the following requirements: The LDAPS certificate is located in the Local Computer's Personal certificate store (programmatically known as the computer's MY certificate store). A private key that matches the certificate is present in the Local Computer's store and is correctly associated with the certificate. The private key must not have strong private key protection enabled. The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as OID). The Active Directory fully qualified domain name of the domain controller (for example, DC01.DOMAIN.COM) must appear in one of the following places: The Common Name (CN) in the Subject field. DNS entry in the Subject Alternative Name extension. The certificate was issued by a CA that the domain controller and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the root CA to which the issuing CA chains. You must use the Schannel cryptographic service provider (CSP) to generate the key. Hope that helps ... View more

@harish Prerequisite: MUST DO If you want to copy a hive table across to another REALM you need to setup cross-realm trust between two MIT KDC's.This will enable the destination REALM user to have a valid Kerberos ticket to run operations on the source Cluster. Having said that, you should forget to revise your ranger policies to reflect the new REALM access privilege if the Ranger plugin has been enabled in the source cluster which I assume is the case to leverage the Ranger authorization. Here is a link to an HCC document that could help you set up the REALM trust PROCEDURE Follow the steps below to migrate a Hive database from one cluster to another: 1. Install Hive on the new cluster and make sure both the source and destination clusters are identical. 2. Transfer the data present in the Hive warehouse directory (/user/hive/warehouse) to the new Hadoop cluster. hadoop distcp <src> <dst>  3. Take a backup of the Hive Metastore. mysqldump hive > /tmp/mydir/backup_hive.sql 4. Install MySQL on the new Hadoop cluster. 5. Open the Hive MySQL-Metastore dump file and replace the source NameNode hostname with the destination hostname.  hdfs://ip-address-old-namenode:port  ---> hdfs://ip-address-new-namenode:port  6. Restore the edited MySQL dump into the MySQL of new the Hadoop cluster. mysql hive < /tmp/mydir/backup_hive.sql 7. Configure Hive as normal and perform the Hive schema upgrade if needed Impact Hive metadata contains the information about the database objects, and the contents are stored in the Hadoop Distributed File System (HDFS). Metadata contains HDFS URI and other details. Therefore, if you migrate Hive from one cluster to another cluster, you have to point the metadata to the HDFS of the new cluster. If you don't do this, it will point to the HDFS of the older cluster and the migration will fail. In case of any failure, initialize the Hive Metastore of the destination cluster and resume the migration following the correct steps. /bin/schematool -initSchema -dbType mysql  On CDH If you are on Cloudera then you can proceed using Backup and Disaster recovery procedure HTH ... View more

@Michael Bronson HWX doesn't recommend upgrading an individual HDP component because one never knows the incompatibilities that could impact the other components and component selective upgrades tend to be a nightmare during a version upgrade The lastest HDP Kafka version is 11-2.1.x delivered by HDP 3.1 but ASF has its own rollout version and naming convention HTH ... View more