AlwaysOn 故障转移，辅助节点作业失败

Posted 2023-03-23

【中文标题】AlwaysOn 故障转移，辅助节点作业失败

【英文标题】：AlwaysOn Failover, secondary node jobs fails

【发布时间】：2019-06-26 10:36:54

【问题描述】：

在测试故障转移功能时，辅助节点无法运行任何访问 TDE 数据库的作业，失败并出现以下错误 请在数据库中创建主密钥或在会话中打开主密钥，然后再执行此操作。

我试过了

通过密码打开主密钥解密 = '密码' --now 通过 SMK 设置加密 ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY

重新启动服务并禁用加密。

我对加密功能了解不多，只是按照步骤将其打开。 没想到故障转移机制如此垃圾，更糟糕的是，网上关于它的信息如此之少。 任何帮助，将不胜感激。 谢谢 乔恩

【参考方案1】：

结果证明 SSISDB 是问题所在。 我设法使用以下命令停止错误

EXEC sp_control_dbmasterkey_password @db_name=N'SSISDB', @password=N'', @action=N'add'

然后它开始抛出可信度错误 然后修复了以下内容： ALTER DATABASE [SSISDB] 设置可信

此后工作开始运行。

【参考方案2】：

此错误是由 AG 上的节点之间的服务主密钥 (SMK) 不匹配引起的。您的数据库有一个数据库主密钥 (DMK)，该密钥在创建时由本地服务器的 SMK 加密。如果您在 AG 中只有两个节点，则修复相对简单 - 从 辅助 节点备份 SMK，使用密码在主节点上打开 DMK，将 SMK 恢复到主节点，然后重新使用新的 SMK 加密 DMK。为什么是那个方向（而不是主要→次要）？更改 DMK 是一种写入操作，在辅助节点上是不可能的！

【参考方案3】：

数据库主密钥 (DMK) 使用服务主密钥 (SMK) 加密，该密钥对每个 SQL 服务实例都是唯一的，您希望以这种方式使用。

SQL Server 有另一种解密 DMK 的方法。如果 DMK 无法使用 SMK 解密，它会在凭证存储中搜索与相同系列 GUID 匹配的密码。如果它找到与您的数据库匹配的家庭 GUID，它将尝试使用存储的密码解密 DMK。如果成功，那么它将使用 DMK 加密或解密数据库中的凭据或密钥。

因此，使用 sp_control_dbmasterkey_password 将根据数据库名称和解密主数据库中的 DMK 的密码存储系列 GUID。

为确保当 AG 从主节点到辅助节点失败时 DMK 正常工作，请在辅助节点上运行 sp_control_dbmasterkey_password 作为将数据库加入 AG 的过程的一部分。

在 SSMS 2016+ 的 AG 向导中，有一个提示让您为具有 DMK 的数据库添加密码。添加此密码时，向导将在辅助笔记上自动运行 sp_control_dbmasterkey_password。 （但是，如果您使用自动播种，则会出现一个已知错误）。

查看此链接了解更多信息：sp_control_dbmasterkey_password