Ambari settings after database restore

[#1]

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.

[#2]

@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

Or

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

[#3]

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.

[#4]

@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

[#5]

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.

[#6]

@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 ..

[#7]

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

[#8]

Thanks Neeraj, look forward to connecting.

[#9]

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

[#10]

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.