如何解决 Azure Always On listener 无法访问的问题

小提示：您能找到这篇{如何解决 Azure Always On listener 无法访问的问题}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的如何解决 Azure Always On listener 无法访问的问题内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">本文旨在解决Always On无法从secondary replica通过listener连接集群，时而出现不能访问的常见问题。

< ">Always On介绍

< ">Always on是SQL Server on VM的架构下最常见的高可用方案。

< ">其基本原理为创建一个至少为2台VM所组成的Windows集群，每台VM上安装一台SQL Server Instance。由其中的一台SQL instance作为主节点（primary replica）提供对外读写访问，同时通过日志传输的形式提交到另外一台节点（secondary replica）进行数据同步。

< ">Secondary replica可以提供只读功能，用于做读写分离或高可用(强烈建议依旧保持备份的习惯)。

< ">备注

< ">在SQL server 2016之前的版本，组成Windows cluster还需要一台Domain controller(DC)。搭建步骤：在Azure VM中手动配置Always On可用性组。

< ">在Azure中搭建Always On的过程并不复杂，但是经常有客户会遇到搭建Always On之后无法使用App连接的自动故障转移功能。

< ">Always on的自动故障转移功能基于Always on Listener。Listener会被注册为一个windows cluster中的resource，类似于VIP概念;在集群发生故障转移时listener会被漂移到新primary的VM中。对于客户端来说，只需要访问Listner的IP地址就可以保证永远连接到当前的primary数据库上。

< ">在传统的IDC环境中，Always On会自动将Listener所属的虚拟IP地址与网卡物理地址注册到路由表中，所以无论任何节点都可以通过Listener找到primary所在的服务器地址并建立链接。

< ">在Azure环境下，该地址无法被注册，所以我们需要通过增加一个Load Balancer的方式来为Listener的访问请求进行转发。

< ">参考示例脚本：使用PowerShell将IP地址添加到现有负载均衡器

< ">该脚本非常重要，会在primary节点上创建一个始终监听在<n.n.n.n>端口上的监听，并会随着primary切换而自动转移到新的primary VM上。本示例中使用59999。

< ">在配置好了listener之后可能会遇到以下几个常见问题：

< ">在primary节点上可以通过listener IP访问集群，但在secondary上无法访问listener IP，只能通过提供primary服务器名或IP的方式来进行连接。

< ">在secondary上有时候可以访问listener IP有时候就不行，随机出现。

< ">如果遇到上述问题，我们可以通过以下几个步骤进行排错：

< ">开始=>运行=>cmd输入netstat-a检查，是否59999监听端口已经在primary网站营销推广如何做节点中存在。

< ">检查Azure门户中Load Balancer上的probe（探测器），探测的端口是否为59999或者是之前在PowerShell中创建的<nnnnn>端口。

< ">[int]$ProbePort="<nnnnn>"#Probe port

< ">经常会有客户错误配置为1433端口，对于LB来说，1433在primary和secondary都为存活状态，所以会随机的分配request给任何一台节点，可能是primary，可能是secondary。

< ">由于Always On必须要先访问primary，所以如果该请求发给了secondary就会得不到响应。

< ">Azure门户中Load Balancer的front Iled电视广告P是否与Windows cluster resource中的listener的IP完全一致。

< ">负载均衡规则中的probe是否配置。

< ">如果以上步骤全部配置正确，通常就可以正常的使用Always On了。