Member since
01-08-2019
52
Posts
8
Kudos Received
2
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
3264 | 05-12-2019 06:21 PM | |
2429 | 05-12-2019 06:11 PM |
12-01-2020
03:20 AM
Hi @ManjuN , NoClassDefFoundError Is usually seen when required jar is missing. In this case atlas migration script is looking for a jar which contains class "com/tinkerpop/blueprints/Graph". This class definition is available in blueprints-core-2.6.0.jar which is available on HDP-2.6.x. # jar -tf /usr/hdp/2.6.<version>/atlas/server/webapp/atlas/WEB-INF/lib/blueprints-core-2.6.0.jar | grep -i "com/tinkerpop/blueprints/Graph"
com/tinkerpop/blueprints/Graph.class
com/tinkerpop/blueprints/GraphFactory.class
com/tinkerpop/blueprints/GraphQuery.class In your case, you are running a migration script from "3.1.0.0-78" directory and that is the reason you are getting NoClassDefFoundError. python /usr/hdp/3.1.0.0-78/atlas/tools/migration-exporter/atlas_migration_export.py -d /atlas_metadata Steps in the document needs to be performed only if you are upgrading your cluster from 2.6.x to 3.0+ version, because In HDP-3.0+, Apache Atlas uses the JanusGraph graph database to store metadata objects whereas in earlier versions, Atlas used the Titan graph database for metadata storage. The document says, "Before upgrading HDP and Atlas, perform the following steps on the HDP-2.x cluster". If you are performing this step during a major upgrade (from HDP-2.6.x to HDP3.0+ or 2.6.5 to HDP-7.x), kindly run atlas_migration_export.py script from 2.6.x path. For minor versions, this step is not required.
... View more
10-06-2020
10:46 AM
Following KB can be used to delete users/groups in bulk https://community.cloudera.com/t5/Community-Articles/Remove-AD-LDAP-accounts-from-Ambari-using-REST-API/tac-p/244196
... View more
09-10-2020
11:32 AM
In case ambari API doesn't help. You can use following SQL queries to abort hung/queued/pending operations directly from ambari database. 1) Stop Ambari-Server ambari-server stop 2) Take backup of ambari database before making any changes to ambari db 3) Check IN_PROGRESS, QUEUED and PENDING operations. ambari=> select task_id,role,role_command from host_role_command where status='IN_PROGRESS';
ambari=> select task_id,role,role_command from host_role_command where status='QUEUED' limit 100;
ambari=> select task_id,role,role_command from host_role_command where status='PENDING'; 4) Abort Operations ambari=> update host_role_command set status='ABORTED' where status='QUEUED';
ambari=> update host_role_command set status='ABORTED' where status='PENDING';
ambari=> update host_role_command set status='ABORTED' where status='IN_PROGRESS'; 5) Start ambari-server ambari-server start
... View more
07-31-2020
07:10 AM
For secured/kerberized cluster, we may need to push kdc admin credentials by creating a temp credential store before deleting Ranger Admin component ADD KDC CREDENTIALS: # curl -ivk -H "X-Requested-By: ambari" -u $AMBARI_USER:$AMBARI_PASSWD -X POST -d '{ "Credential" : { "principal" : "admin/admin@REALM", "key" : "hadoop", "type" : "temporary" } }' "$AMBARI_URL/api/v1/clusters/$CLUSTER_NAME/credentials/kdc.admin.credential" GET CREDENTIALS # curl -ivk -H "X-Requested-By: ambari" -u $AMBARI_USER:$AMBARI_PASSWD -X GET "$AMBARI_URL/api/v1/clusters/$CLUSTER_NAME/credentials/kdc.admin.credential"
... View more
05-13-2019
07:07 PM
1 Kudo
@Yan Liu this isn't an issue to worry about. Ambari keeps checking the NN status until it detects that the NN is out of safemode. It usually takes sometime because of the reasons mentioned above.
... View more
05-12-2019
06:30 PM
Because Ambari keeps trying to get the safe mode status of namenode. And when it detects that the safe mode is OFF (grep 'Safe mode is OFF'), it shows Namenode started. Namenode usually takes some time to come out of safemode, Because: During Namenode startup, the NameNode must complete certain actions before it can serve client requests: Read file system metadata from the fsimage file. Read edit logs and apply logged operations to the file system metadata. Write a new checkpoint (a new fsimage consisting of the prior fsimage plus the application of all operations from the edit logs). Remain in safe mode until a sufficient number of blocks have been reported by datanodes. In some situations, these actions can take a long time to complete.
... View more
05-12-2019
06:21 PM
1 Kudo
You must provide read and execute (r-x) permissions to others. Try this $ chmod 705 /home/maria_dev
$ sudo su hive
$ ls -l /home/maria_dev
... View more
05-12-2019
06:11 PM
1 Kudo
Remove entry from ranger db and restart ranger admin process to resolve this. # select * from x_db_version_h where version = 'J10001';
# delete from x_db_version_h where version = 'J10001'; This is usually seen during fresh install. After installation during first start of ranger admin process, ambari start applying patches and if this operation is aborted due to any reason, you may see this error when you restart ranger admin process.
... View more
05-12-2019
05:54 PM
1 Kudo
This issue is usually seen when user wan't removed properly from Ranger db and some information is still available in user tables. For example in above situation it might be possible that 'user1' is not available in x_user table but its still part of other user tables such as x_portal_user, x_portal_user_role, x_user_module_perm, x_auth_sess etc. Perform below steps to resolve this issue. Verify whether problematic user is available in other tables MariaDB [ranger]> select * from x_user where user_name = 'user1';
MariaDB [ranger]> select id from x_portal_user where login_id = 'user1';
+----+
| id |
+----+
| 44 |
+----+
MariaDB [ranger]> delete from x_portal_user_role where id = 44;
MariaDB [ranger]> delete from x_user_module_perm where user_id = 44;
MariaDB [ranger]> delete from x_auth_sess where user_id = 44;
MariaDB [ranger]> delete from x_portal_user where id = 44; To get all such user's MariaDB [ranger]> select * from x_portal_user_role where id not in (select id from x_user);
MariaDB [ranger]> select * from x_user_module_perm where user_id not in (select id from x_user);
MariaDB [ranger]> select * from x_auth_sess where user_id not in (select id from x_user);
MariaDB [ranger]> select * from x_portal_user where id not in (select id from x_user); Remove users which are not part of x_user table but available in other tables MariaDB [ranger]> delete from x_portal_user_role where id not in (select id from x_user);
MariaDB [ranger]> delete from x_user_module_perm where user_id not in (select id from x_user);
MariaDB [ranger]> delete from x_auth_sess where user_id not in (select id from x_user);
MariaDB [ranger]> delete from x_portal_user where id not in (select id from x_user); Restart usersync process
... View more