Início / dba / Perguntas / 142603
Accepted
Ali Razeghi - AWS
Asked: 2016-06-30 11:12:51 +0800 CST

Falha ao criar, ingressar ou adicionar réplica ao grupo de disponibilidade no SQL Server 2014

  • 772

Eu tenho um FCI de 2 nós e uma instalação autônoma do SQL Server em um nó não FCI. Eu automatizei a configuração/instalação de FCIs, AGs e réplicas de banco de dados, o que funcionou bem até agora em todos os meus testes.

Hoje estou recebendo o erro abaixo quando executo:

USE [master]
GO
CREATE AVAILABILITY GROUP [AGName]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR 
REPLICA ON N'Node3\ReadOnly' WITH (ENDPOINT_URL = N'TCP://Node3-blah.blah.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, SESSION_TIMEOUT = 10, BACKUP_PRIORITY = 50, PRIMARY_ROLE(ALLOW_CONNECTIONS = ALL), SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
    N'Primary/Primary' WITH (ENDPOINT_URL = N'TCP://primary.blah.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, SESSION_TIMEOUT = 10, BACKUP_PRIORITY = 50, PRIMARY_ROLE(ALLOW_CONNECTIONS = ALL), SECONDARY_ROLE(ALLOW_CONNECTIONS = NO));
GO

Erro:

Msg 19405, Nível 16, Estado 17, Linha 3
Falha ao criar, unir ou adicionar réplica ao grupo de disponibilidade 'AGName', porque o nó 'Node3' é um possível proprietário da réplica 'Node3\ReadOnly' e 'Primary/Primary'. Se uma réplica for uma instância de cluster de failover, remova o nó sobreposto de seus possíveis proprietários e tente novamente.

O nó 3 não faz parte da FCI. Ele tem uma instalação autônoma do SQL Server e não está listado como um possível proprietário.

Se eu tentar fazer failover para o Nó 3, a FCI me informará que não é um possível proprietário.

Não tenho certeza do que causou isso. Fiz failover usando o FCI entre o nó 1 e 2 vários dias antes. Desta vez, removi o ouvinte para testar, pois era a última coisa em que estava trabalhando. Alguma ideia?

Eu poderia simplesmente desmontar o FCI e fazer com que a automação o recriasse, mas queria tentar resolver isso sem fazer isso, caso isso aconteça na produção um dia. Devemos ser capazes de remover o nó do WSFC e adicioná-lo novamente, mas não quero incomodar nossa equipe de operações, que precisa fazer isso. Iremos desmontar todo o cluster e deixá-lo construir do zero antes de liberá-lo.

Editar. Esta é a saída do nó FCI:

select * from sys.dm_os_cluster_nodes

NodeName    status  status_description  is_current_owner
---------------------------------------------------------
SQNodeL001-LA   0   up  1
SQNodeL002-LA   0   up  0
SQLNode003-LA   0   up  0

A saída do autônomo está vazia. Faz parte do WSFC, mas ainda não é FCI ou AG.

A saída do powershell nos mostra que todos os 3 podem ser nós proprietários, o que é estranho.

ClusterObject                                               OwnerNodes
-------------                                               ----------
SQL Server (Instance)                                           {SQNodeL001-LA, SQNodeL002-LA, SQNodeL003-LA}

Na GUI, ele não possui o nó 3 selecionado como proprietário preferencial. Perdão por fazer pequenas alterações e remover os nomes. O nome do primeiro nó está todo em letras minúsculas. Os outros 2 estão em maiúsculas. Parece que preciso fazer tudo isso no powershell para obter os dados precisos, ainda não automatizei essa etapa. Esse será o próximo sprint.

Editar 2 - resolvido:

Graças à consulta do PowerShell de Sean, pude ver que ele ainda está listado como proprietário no PowerShell, embora não esteja na GUI. Eu removi usando get-clusterresource "sql server (instance)" | set-clusterownernode -Owners node1 node2e funcionou. Obrigado Sean!

insira a descrição da imagem aqui

sql-server availability-groups

1 respostas

  1. Best Answer

    Msg 19405, Nível 16, Estado 17, Linha 3 Falha ao criar, unir ou adicionar réplica ao grupo de disponibilidade 'AGName', porque o nó 'Node3' é um possível proprietário da réplica 'Node3\ReadOnly' e 'Primary/Primary'. Se uma réplica for uma instância de cluster de failover, remova o nó sobreposto de seus possíveis proprietários e tente novamente.

    Isso acontece por dois motivos principais que testemunhei.

    Motivo nº 1 - O recurso/grupo está configurado para ter propriedade no nó com erro

    Às vezes (por vários motivos), recursos e grupos de recursos no clustering do Windows nem sempre têm a mesma propriedade. A melhor maneira de diagnosticar esse erro é verificar primeiro o que o SQL Server (que chama as APIs de clustering do Windows) considera os nós do cluster:

    SELECT * FROM sys.dm_os_cluster_nodes

    Assim que soubermos o que está no cluster, verifique via Powershell para ver o que o cluster acha que é a propriedade da FCI:

    Get-ClusterOwnerNode -Resource "SQLFCIInstanceName"

    Isso retornará os nós que podem possuir o recurso de cluster. É provável que inclua o nome do nó de um nó que sabemos que não deveria estar lá.

    Para corrigir isso, execute o seguinte comando powershell :

    Get-ClusterResource -Name "SQLFCIInstanceName" | Set-ClusterOwnerNode -Owners NodeName1,NodeName2

    Verifique novamente executando o primeiro comando powershell para verificar a propriedade e, em seguida, tente adicionar a réplica ao AG novamente.

    Razão nº 2 - Nomes de nó + idioma != Nomes de nó

    Se o idioma usado não fosse US_English, haveria uma boa chance de que os nomes dos nós (quando comparados entre si) não fossem necessariamente comparados corretamente. Isso causaria vários outros problemas (e causa) com o cluster fora do AG.

    Isso pode ser testado pegando os nomes dos nós, convertendo-os em superior ou inferior e comparando-os com eles mesmos. Parece que sempre deve funcionar ... mas alguns idiomas têm caracteres especiais que não fazem bem as conversões UPPER e LOWER.

    • 4

relate perguntas