Leitura na Réplica do AlwaysOn com SQL Standard? Isso é possível? – Parte II

Olá pessoal tudo certo?

No post de hoje vamos finalizar o post anterior (Leitura na Réplica do AlwaysOn com SQL Standard? Isso é possível? – Parte I).

No post anterior, chegamos até a configuração do Cluster do Windows. Agora seguiremos com a configuração do AlwaysOn e como conseguiremos consultar dados na réplica utilizando o SQL Standard.

“Tiago, quero só ver se isso é verdade mesmo ou se você está me enrolando…” Calma meu amigo, nesse post vou mostrar qual foi a mágica que utilizei =)

Configurando o AlwaysOn

1. Para fazer a configuração do AlwaysOn, precisamos a abrir o “Configuration Manager” do SQL Server.

• 

2. No serviço do SQL Server, você deverá clicar com o botão direito à Propriedades, na aba “AlwaysOn High Availability” à Habilitar a feature.

• 

OBS: Os passos 1 e 2 devem ser configurados nos 2 (dois) nós.

3. No “Management Studio”, na guia “AlwaysOn High Availability” à botão direito à “New Availability Group Wizard”. (Este passo devera ser executado no servidor principal.)

• 

• 

4. Será aberto um wizard para realizar a configuração do AlwaysOn.

• 

5. Você precisa dar um nome para o recurso do AlwaysOn. No meu caso, escolhi “SQLAG2017”.

• 

6. Agora precisamos informar a base que vai fazer parte do grupo de disponibilidade.

• 

Como estamos utilizando o SQL Server Standard, ele é limitado ao AlwaysOn Basic, onde só podemos criar uma base por grupo de disponibilidade. Neste post vamos utilizar a base AdventureWorks.

https://docs.microsoft.com/pt-br/sql/database-engine/availability-groups/windows/basic-availability-groups-always-on-availability-groups?view=sql-server-ver15

7. Agora você precisa conectar na réplica.

• 

• 

8. Aqui vamos fazer as configurações de sincronização do AlwaysOn que pode ser síncrona ou assíncrona. Se tivéssemos uma edição do SQL Server Enterprise ($$$), nesse momento poderíamos configurar a leitura na réplica.

• 

9. Na aba “Endpoints”, devemos informar a porta e o nome do endpoint. Também podemos alterar a rede, caso tenhamos diferentes interfaces de rede. Por padrão, a porta do AlwaysOn é a mesma do Database Mirroring: 5022.

• 

10. Na aba “Listener”, a criação de um listener NÃO é obrigatória, mas é uma recomendação de boa prática criá-lo. Para fazer isso, você deverá informar um nome, a porta de conexão e o IP.

• 

https://docs.microsoft.com/pt-br/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover?view=sql-server-ver15

11. Agora precisamos informar como vamos configurar o AlwaysOn:

• Fazendo Backup e Restore;

• OU usando a opção “Join Only”, quando você já fez o RESTORE dos backups de forma manual no servidor da réplica.

• 

12. Se a criação do grupo de disponibilidade foi executada com sucesso, você receberá a tradicional mensagem de sucesso.

• 

Olha só que lindo que fica o AlwaysOn após a configuração =).

• 

• 

A base no servidor primário (SQL22) vai ficar com o status “sincronizado” e no servidor secundário (SQL23) vai ficar com o status “sincronizando”.

Leitura na réplica:

“Pô Tiago, você me enrolou de novo e não falou qual foi a mágica que usou!!!” Calma que agora vamos aos finalmentes… rsrsrs como fazer a leitura na réplica….

Mas antes temos um ponto de observação MUITO IMPORTANTE:

Se você quiser fazer a leitura na réplica, você terá que LICENCIAR o SQL Server!!!

Nativamente não é possível fazer leitura na réplica.

Segue abaixo um exemplo do erro ao tentar utilizar a base na réplica.

• 

Para efetuar o teste da leitura, vamos criar uma tabela no servidor primário chamada “Teste_Snapshot”, onde vamos inserir 4 registros.

• 

CREATE DATABASE AdventureWorks_SS
ON
(NAME = N'AdventureWorks2017',
FILENAME = N'C:\MSSQLSERVER\DATA\AdventureWorks_SS.ss)
AS SNAPSHOT OF AdventureWorks

• 

Com isso, após a criação do Snapshot será possível fazer a leitura na database “AdventureWorks_Ss”.

• 

IMPORTANTE:

Um ponto de observação muito importante é que os dados irão estar atualizados somente até o horário da criação do snapshot!

Ou seja, se você inserir novos dados na database original eles não serão replicados de forma automática para a database do Snapshot.

• 

Para atualizar os dados na réplica, será necessário atualizar o Snapshot. Portanto, você deverá apagar o Snapshot anterior, utilizando o comando “DROP DATABASE ADVENTUREWORKS_SS” e criar o Snapshot novamente, agora com os dados atualizados =).

OBS: Pode acontecer algum erro no DROP DATABASE se tiver alguma conexão utilizando a database. Com isso, pode ser necessário matar todas essas conexões antes de executar o DROP DATABASE.

Para manter esses dados atualizados de forma automática, sugiro que você crie um JOB para fazer esse procedimento a cada X minutos ou horas.

• 

Como falamos anteriormente, essa é uma solução de contorno que pode ser utilizada em vários cenários.

Vale reforçar que está solução só é válida se você licenciar os 2 nós, da mesma forma que se você tivesse um SQL Server Enterprise você também teria que licenciar ambos os servidores. Contudo, o valor de licenciar o SQL Server Standard será muito menor ao utilizar essa solução =).

Bom pessoal por hoje é isso, espero que essa solução seja útil para vocês.

Abraços,

Tiago Neves