Support Questions
Find answers, ask questions, and share your expertise

Ambari settings after database restore


I had to restore an Ambari database backup, which was a bit behind the current cluster status. Will the Ambari restore "rollback" config changes upon cluster startup, and if so is there a way to "refresh" Ambari with what's current in the cluster. Thank you.


Accepted Solutions


Thank you both for your help. Support case was escalated and received excellent guidance for getting Ambari back in sync. The primary resolution for the sync issue raised here was executing $ ambari-server upgradestack HDP-2.3

View solution in original post


@Brenden Cobb

Make sure you backup existing db before the restore

Restore the old db

Restore the backup done in step 1 in different instance and try to match the content


You can export the blueprint of existing cluster and restore , export the blueprint after restore and match the differences

Change the configs as per the differences


Thanks. For 1) This sounds like Ambari will overwrite existing component configs when using a database restore? For 2) is the blueprint created from Ambari's settings or the cluster's configs? I'm just not clear whether Ambari will overwrite what's in the cluster or pull, and if there's an option to control this behavior.

@Brenden Cobb

1) Yes

2) If you restore db then ambari will push configs based on configs in db. We need to be creative to find the delta.

3) curl -u admin:admin -i -H 'X-Requested-By: ambari' -X GET http://ambariserver:8080/api/v1/clusters/clustername?format=blueprint

This will give you configs from the existing cluster and then run again after db restore


Ah, ok. So execute before starting cluster services to get what's there, execute again after starting services and basically do a diff between the 2? This is good.

@Brenden Cobb Yes. I believe you have restore the old db ..if you have not then I would run the blueprint statement now and save it ...then restore db , run blueprint command ..

@Brenden Cobb Let's connect on linkedin and we can discuss this in detail.


Thanks Neeraj, look forward to connecting.

@Brenden Cobb Did you try the above solution? I am looking forward to see the final outcome.


As suggested, I have the blueprint which reflects all the current information for our stack (2.3.2). When attempting to start services on the cluster Ambari favors 2.2, the previously installed version. My assumption is the Ambari database needs some adjusting to properly recognize 2.3.2. I've tried a few updates to set the installed stack to 2.3.2, but Ambari is unsuccessful at starting the cluster components.