Community Articles
Find and share helpful community-sourced technical articles
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( from topology_request tpr;
select count(DISTINCT from topology_request tpr join topology_logical_request tlr on = 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( from topology_host_request thr;
select count(DISTINCT from topology_host_request thr join topology_host_task tht on = tht.host_request_id join topology_logical_task tlt on = 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.
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:
Top Kudoed Authors