Início / dba / Perguntas / 279500
Accepted
Stockburn
Asked: 2020-11-11 22:59:58 +0800 CST

SQL Always On Grupos de Alta Disponibilidade Multi Sub-rede

  • 772

SQL 2017 Standard em SQL sempre em dois nós Basic AG. Existem dois registros DNS para o ouvinte com os diferentes IPs de sub-rede

Os servidores estão em sub-redes e encontramos problemas com um aplicativo que atinge o tempo limite aleatoriamente ao conversar com o banco de dados, outras vezes ele responde em milissegundos. Depois de executar o Wireshark, podemos ver que o aplicativo está tentando se comunicar com o banco de dados por meio do endereço IP do ouvinte do parceiro de failover, a réplica não legível.

Esta informação que li explica o tempo limite de 21 segundos.

https://techcommunity.microsoft.com/t5/sql-server-support/improved-multisubnet-listener-behavior-with-newly-released-sql/ba-p/318664

MultiSubnetFailover=TRUE parecia ser a resolução, mas o aplicativo está usando uma versão mais antiga do .NET, há mais alguma coisa que eu possa fazer para resolver ou contornar isso?

sql-server availability-groups

1 respostas

  1. Best Answer

    Conforme mencionado nos documentos aqui , o problema é explicado:

    MultiSubnetFailover=True Não suportado pelo NET Framework 3.5 ou OLEDB

    Problema: se seu grupo de disponibilidade ou instância de cluster de failover tiver um nome de ouvinte (conhecido como nome de rede ou ponto de acesso de cliente no WSFC Cluster Manager) dependendo de vários endereços IP de diferentes sub-redes e você estiver usando ADO.NET com .NET Framework 3.5SP1 ou SQL Native Client 11.0 OLEDB, potencialmente 50% de suas solicitações de conexão de cliente para o ouvinte do grupo de disponibilidade atingirão um tempo limite de conexão.

    E existem duas soluções principais:

    Soluções alternativas: Recomendamos que você execute uma das seguintes tarefas.

    Se não tiver permissão para manipular recursos de cluster, altere o tempo limite de conexão para 30 segundos (esse valor resulta em um período de tempo limite TCP de 20 segundos mais um buffer de 10 segundos).

    Prós: Se ocorrer um failover entre sub-redes, o tempo de recuperação do cliente será curto.

    Contras: Metade das conexões do cliente levará mais de 20 segundos

    Se você tiver permissão para manipular recursos de cluster, a abordagem mais recomendada é definir o nome da rede do ouvinte do grupo de disponibilidade como RegisterAllProvidersIP=0. Para obter mais informações, consulte "Configuração de RegisterAllProvidersIP" posteriormente nesta seção.

    Prós: Você não precisa aumentar o valor do tempo limite de conexão do cliente.

    Contras: Se ocorrer um failover entre sub-redes, o tempo de recuperação do cliente pode ser de 15 minutos ou mais, dependendo da configuração do HostRecordTTL e da configuração do agendamento de replicação do DNS/AD entre sites.

    Na minha opinião, metade das conexões que demoram mais de 20 segundos está longe de ser o ideal e eu procuraria alterar as configurações RegisterAllProvidersIPpara 0 e HostRecordTTLde acordo com suas necessidades. Saiba que diminuir muito esse valor aumentará as solicitações de pesquisa de DNS. Você também pode examinar o monitoramento de failovers aqui ajudaria com problemas de conexão após o failover.

    • 3

relate perguntas