Community Articles
Find and share helpful community-sourced technical articles
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.
Labels (1)
New Contributor

In case of a Blueprint based deployment Ambari stores deployment tasks in topology tables: topology_request, topology_logical_request, topology_host_request, topology_host_task, topology_logical_task.

In case of some errors during deployment task creation these tables could be left in an inconsistent state, which has been fixed in 2.5.0 (AMBARI-19929).

Ambari 2.5.0 introduced (removed in 2.5.2) two DB consistency checks related to topology tables:

1. Check topology_request, topology_logical_request tables are consistent, by comparing the row counts returned:

select count(tpr.id) from topology_request tpr;
select count(DISTINCT tpr.id) from topology_request tpr join topology_logical_request tlr on tpr.id = tlr.request_id; 
In case row counts are different it means there’s a missing row in topology_logical_request table.
To fix this a new row has to be inserted in topology_logical_request table:
  • get next available: next_topology_logical_request_id = select max(id) + 1 from topology_logical_request;
  • insert new row:
insert into topology_logical_request select <next_topology_logical_request_id>, id, 'Logical Request: ' || description from topology_request where id not in (select request_id from topology_logical_request); 
2. Check topology_host_request, topology_host_task, topology_logical_task tables are consistent by comparing the row count returned:

select count(thr.id) from topology_host_request thr;
select count(DISTINCT thr.id) from topology_host_request thr join topology_host_task tht on thr.id = tht.host_request_id join topology_logical_task tlt on tht.id = tlt.host_task_id;
In case row counts are different it means there are missing rows in topology_host_task and/or topology_logical_task tables for a given topology_host_request row.
To fix this problem the easiest way is to delete that all related rows from all related tables. Since these are already finished / failed requests you can delete these safely:

 

delete from topology_host_task where not id in (select host_task_id from topology_logical_task);delete from topology_host_request where not id  in (select host_request_id from topology_host_task); 
Once you are finished you can rerun check select statements to be sure everything is fine.
359 Views
Don't have an account?
Coming from Hortonworks? Activate your account here
Version history
Revision #:
1 of 1
Last update:
‎08-17-2017 05:57 PM
Updated by:
 
Contributors
Top Kudoed Authors