Making Session Keys of SQL instances Identical in SQL Availability Group We recently added a master key encrypted database on a two-nodes SQL Server AlwaysOn Availability Group. Whenever there is a failover, the master key gets dropped and we have to manually add the master key back to the database on a new primary node. 

I would think the databases is fully synchronized and there won’t be any loss of configuration after a failover. I talked to my vendor and they said during a failover, the client will be using the signed Master Key from the previous instance, on a database with a differently signed Master Key. They said that Session Keys are different between the SQL instances running as part of the group and that we need to make sure that the session keys are identical. 

I am not sure of what to make of that:


Is there anything such as session keys in HA group?
If so, can I make them identical for each node (SQL instances) in the
cluster?
When you restore a database that has encrypted data to a different instance, with a different Service Master Key (SMK), the data won't decrypt properly because of SQL Server's Encryption Hierarchy.  The "restore" of the master key you mention is really decrpyting the data using the Database Master Key (DMK) password and then re-ecrypting the data with the new instance's SMK:

OPEN Master Key Decryption By Password = N'&lt;redacted&gt;'-- Password used when creating DMK
ALTER Master Key ADD encryption by Service Master KEY


There are a number of ways around having to do this after every failover, but the way I prefer in this scenario is to backup a SMK from the current primary node in your Availability Group (AG), and restore that to all other Instances in said AG so your SMKs match throughout.  Once this is done, you may need to run the above statement against each db that's not sitting in a read-only state on any Secondary Replicas so that any encrypted data will be readable after any future listener failover events.  The whole point of having an AG is the ability to perform a quick and transparent failover, so a shared SMK shouldn't be considered a risk in my opinion.

This article goes over this and walks you through things in much more detail, but take some time to set this up so you can take full advantage of Availability Groups.