我们正尝试通过MS Release Management Studio将DACPAC部署到新服务器。在数据层升级之前,我们已使用相同的DACPAC成功部署到具有现有还原数据库的其他新服务器。证明DACPAC和部署过程正在发挥作用。
唯一的区别是此服务器具有Always On Availability Groups(AOAG),我们正在部署的目标是组侦听器。遵循here的建议:
您必须将其部署到侦听器,而侦听器实际上会将您的连接重定向到AlwaysOn可用性组的主副本。 更改也将转移到辅助副本。 侦听器使客户端能够连接到可用性副本,而无需知道客户端连接到的SQL Server的物理实例的名称。 因此,通常您可以在Release Management Studio中使用此侦听器名称,就像另一个SQL Server实例一样。
尝试使用侦听器手动升级数据层应用程序时,它指出目标服务器无法访问。
有没有人有这个过程,或者有过一些经验可以分享为什么会发生这种情况以及我能做些什么来克服它?
更新(已解决):
看起来我们的服务器已修补,导致发生故障转移。辅助副本没有为我们的Release Management Studio用户设置帐户。
此外,我们的DBA终于插入了我们的副本被设置为只读。
因此,我们已经做了一些发现,例如DACPAC会将数据库升级到数据层应用程序,即使它们没有注册。
虽然您可以将DACPAC作为DAC部署到主副本,但除非您手动升级/注册,否则不会将辅助数据注册为DAC。知道很有用。
感谢所有提出问题的人:)
答案 0 :(得分:0)
看起来我们的服务器已修补,导致发生故障转移。辅助副本没有为我们的Release Management Studio用户设置帐户。
此外,我们的DBA终于插入了我们的副本被设置为只读。
因此,我们已经做了一些发现,例如DACPAC会将数据库升级到数据层应用程序,即使它们没有注册。
虽然您可以将DACPAC作为DAC部署到主副本,但除非您手动升级/注册它们,否则辅助副本将不会注册为DAC。知道很有用。
感谢所有提出问题的人:)
答案 1 :(得分:0)
因为您的数据库恢复设置将很简单,所以也会发生这种情况。在“可用性”组或镜像的情况下,它应该已满