Dicas AG – Falha ao sincronizar bancos de dados com automatic-seeding (Secondary database is not joined)

A partir do SQL Server 2016, o Always On Availability Groups possui um recurso chamado Automatic Seeding como mais uma opção para sincronização inicial ao configurar réplicas e bancos de AG.

Basicamente, tal como mirroring, o sincronismo inicial depende de um backup e restore, e o que o automating seeding da forma mais simples faz é, bem, backup e restore, teoricamente sem intervenção alguma do DBA (você pode fazer de forma híbrida também backup+restore+automatic_seeding se quiser). Basta marcar essa opção durante a configuração, sair pra passear e esperar os servidores SQL das réplicas primárias e secundárias tocarem o trabalho.

Bem, sabemos que às vezes coisas estranhas acontecem. Ocorreu que utilizei o automatic seeding pra sincronizar uma réplica assíncrona de um AG com cinco bancos. Quando fui conferir, dos cinco (5) bancos, dois (2) tiveram falhas de sincronização, indicando que não foi possível ingressar o banco de dados:

 

Mais informações:

  • As duas bases problemáticas não estavam sendo visualizadas na listagem de banco de dados;
  • Explorei o diretório das bases e descobri que tanto o .mdf e o .ldf dos dois bancos problemáticos já estavam criados;

 

O ERRORLOG já “cantou a pedra”:

Não é muito intuitivo, mas aqui está a resposta:

“Necessário conceder permissão para criação de banco para o AG”.

ALTER AVAILABILITY GROUP AGMeuNomeFicticio01 GRANT CREATE ANY DATABASE

Depois disso bastou resumir a sincronia dos dois bancos envolvidos, podendo fazer isso via interface ou através do comando:


ALTER DATABASE DBMeubanco1 SET HADR RESUME
GO
ALTER DATABASE DBMeubanco2 SET HADR RESUME

Resumindo o banco, ele realiza backup e restore se necessário e se resolve normalmente depois de algum tempo:

Espero ter ajudado.

[]’s

Dicas AG – Criação de listener e adição de IP em arquiteturas AG multi-subnet

Resultado de imagem para esquilos familia

Olá, post rápido sobre listener com Always On Availability Groups, envolvendo redes diferentes.

Introdução extremamente simplificada 

O post chama Always On Availability Groups de AG pela simplicidade.
Dependendo da sua arquitetura de AG, existe a opção de adicionar um listener, nome virtual que pode ser utilizado pelas aplicações.
O listener (que é um nome) precisa estar vinculado a um ou mais IP’s.
O seu cluster que contém um AG pode envolver servidores e IP’s de uma única rede ou pode envolver IP’s de redes diferentes (multi-subnet).
Esse post pretende ajudar quem precisa adicionar um IP em listener já existente ou a partir de um novo listener (e por bônus, como remover)

 

Criar listener com diferentes IP’s (Multi-subnet AG)


USE MASTER;
ALTER AVAILABILITY GROUP [AGJennifer]
ADD LISTENER N'List001' (
WITH IP
(
(N'10.231.31.25', N'255.255.255.0'),
(N'10.91.1.25', N'255.255.255.0')
)
, PORT=1433);
GO

Caso seu cluster já tenha réplicas (aka servidores na linguagem AG) de redes diferentes ingressadas no AG, você pode criar um listener contendo os IP’s que atendam todos os nós envolvidos.

Caso por exemplo você adicione dois nós da rede A, e um nó da rede B, caso você crie um listener com apenas um endereço de IP  não reconhecido pela rede B, você receberá o seguinte erro:

Msg 19456, Level 16, State 0, Line 69
None of the IP addresses configured for the availability group listener can be hosted by the server ‘ReplicaEstrangeira’. Either configure a public cluster network on which one of the specified IP addresses can be hosted, or add another listener IP address which can be hosted on a public cluster network for this server.

 

Adicionar IP em um listener já existente

Bem comum quando você precisa ingressar uma máquina de outra rede (rede B por exemplo) no AG e já existe um listener que NÃO contém um IP reconhecido pela rede B. Nesse caso o recomendado é primeiro você adicionar o IP e depois a réplica (o contrário que seria adicionar a réplica antes do IP não dá bom).


USE [master]
GO
ALTER AVAILABILITY GROUP [AGJennifer]
MODIFY LISTENER N'List001' (
ADD IP(N'10.231.31.25', N'255.255.255.0'))

Após adicionar o IP de outra rede no listener, adicionar uma réplica desta rede deverá ocorrer sem problemas.

BONUS: Como remover um IP de um listener

Dessa vez a interface gráfica do Management Studio não ajuda, portanto, você tem duas boas opções:
a) Via powershell (Get-ClusterGroup <Nome AG> | Get-ClusterResource <Nome AG>_<IP_A_SER_REMOVIDO> | Remove-ClusterResource)
b) Via interface gráfica, no cluster manager

Até o próximo post, pessoal.