SQL Server AlwaysOn Availability Groups é uma tecnologia que foi inicialmente lançada pela Microsoft com o SQL Server 2012.
O conceito principal, é que tem os seus dados disponíveis em mais do que um sítio ao mesmo tempo. Para tal, tem grupos de bases de dados que têm réplicas primárias e réplicas secundárias. Estas réplicas estão alojadas em servidores diferentes e podem ser sincronizadas em dois modos:
- Modo Assíncrono de Compromisso de Disponibilidade
- Modo Assíncrono de Compromisso de Disponibilidade
Grupos de Disponibilidade Modo Assíncrono de Compromisso
Com o modo assíncrono de Compromisso, a réplica secundária nunca é totalmente sincronizada com a réplica primária. A razão para isto, é que devido à natureza de commit assíncrono, qualquer base de dados secundária pode ficar para trás em qualquer ponto. Isto significa que se estiver a utilizar o modo de commit assíncrono e executar um failover forçado (esta é a única forma de failover que pode executar), então é altamente possível ter perda de dados.
Availability Groups Synchronous-Commit Mode
Com o modo de commit síncrono, depois de ter sido unido a um grupo de disponibilidade, uma base de dados secundária alcança a base de dados correspondente e entra no estado “Synchronized”. O pré-requisito para isto, claro, é que a sincronização de dados (e, portanto, o movimento de dados) continue e não seja interrompida por qualquer razão (ou seja, problemas de rede, problemas de espaço em disco, etc.). Se a sincronização de dados continuar e o modo de autorização síncrona for utilizado, então cada transacção que é autorizada numa dada base de dados primária também foi autorizada na base de dados secundária.
Exemplo de uma arquitectura SQL Server Always On Availability Groups
O diagrama abaixo ilustra uma réplica de 2 nós com o SQL Server Always On Availability Groups.
Vamos discutir mais aprofundadamente os conceitos ilustrados no diagrama arquitectónico acima.
Discussão e Recomendações
Uma coisa que é muito importante notar, é que, com base na arquitectura dos Grupos de Disponibilidade, cada réplica, tem o seu próprio armazenamento dedicado, afinal, esta é a forma de ter os seus dados disponíveis em múltiplos sítios. Isto baseia-se no princípio da redundância.
Eu tenho um geo-cluster com 2 nós em 2 sites diferentes, Site A e Site B. Em cada site, tenho uma réplica do meu SQL Server Availability Groups. No exemplo acima, no Sítio A, tenho as minhas réplicas primárias, e no Sítio B, as minhas réplicas secundárias. Tal como discutido anteriormente, as minhas réplicas podem ser sincronizadas com commit.
p> Outra coisa importante a notar, é que se quiser realmente alcançar uma alta disponibilidade, necessita de um terceiro sítio para ser servidor como Testemunha de Partilha de Ficheiros. É por isso que no meu diagrama acima, incluí um terceiro site, ou seja, o Site C, que fornece uma partilha de ficheiros a fim de ser utilizado como Testemunha de Partilha de Ficheiros para o geo-cluster.
Como ligar a minha Aplicação a uma Base de Dados num Grupo de Disponibilidade do SQL Server?
Se é novo nos Grupos de Disponibilidade do SQL Server pode estar a perguntar-se: “como é que a minha aplicação se ligará à base de dados?”. Bem, não se preocupe porque isto é muito simples. Cada Grupo de Disponibilidade tem o seu próprio ouvinte (um par de nome de rede virtual e IP virtual) que precisa de configurar durante a criação de um Grupo de Disponibilidade. Na configuração da cadeia de ligação da sua aplicação, terá de introduzir o nome/IP do ouvinte e o seu número de porta para que a sua aplicação possa “ver” a(s) base(s) de dados no grupo específico de disponibilidade. Depois disso, a arquitectura de alta disponibilidade subjacente será transparente para a sua aplicação.
Uma nota importante aqui, aconselhamo-lo a utilizar Grupos de Disponibilidade para a sua solução apenas se a sua solução/aplicação suportar esta arquitectura de alta disponibilidade.
O que acontece durante um Failover?
Um Failover numa arquitectura de Grupos de Disponibilidade do SQL Server Availability Groups é diferente (e mais rápido) do que um Failover numa Instância de Clusterização do SQL Server (FCI) tradicional. A maior diferença é que sempre que ocorre um failover para um Grupo de Disponibilidade de Servidor SQL, a única coisa que muda de proprietário, é o ouvinte. Isto significa que após o failover, o ouvinte do grupo específico de disponibilidade estará a apontar para a outra réplica porque essa réplica acabou de se tornar a nova réplica primária e outra (que até essa altura era a primária) passou a ser a réplica secundária. Tudo isto, naturalmente, pressupõe que ambas as réplicas estão sincronizadas.
Observações Finais
Como se pode ver na discussão e no exemplo acima, todas as anteriores fazem do SQL Server Always On uma solução muito poderosa de alta disponibilidade que deve ser definitivamente considerada ao conceber centros de dados activos-activos.
Por último, note que o exemplo acima foi simplificado, de modo a ajudá-lo a compreender os próprios fundamentos dos Grupos de Disponibilidade do SQL Server e como estes contribuem para ter instâncias do SQL Server altamente disponíveis.
Com a oferta do SQL Server Always On Availability Groups, é possível construir soluções sofisticadas de base de dados de alta disponibilidade com mais de 2 sítios e assim ter uma infra-estrutura verdadeiramente altamente disponível.
Em artigos subsequentes, discutiremos mais tópicos sobre o SQL Server Always On Availability Groups, por isso mantenha-se atento!
Forçar as suas capacidades de administração do SQL Server – Inscreva-se no nosso Curso Online!
Se quer realmente aprender técnicas sofisticadas de administração de SQL Server, então deve verificar o nosso curso online on-demand intitulado “Essential SQL Server Administration Tips” (desconto especial de tempo limitado incluído no link).
Via o curso, aprenderá dicas práticas essenciais de administração de SQL Server sobre manutenção, segurança, desempenho, integração, tratamento de erros e muito mais. Muitas demonstrações ao vivo e recursos para download incluídos!
Inscrição Agora com Desconto!
Cursos Online em Destaque:
- Boost SQL Server Database Performance with In-Memory OLTP
- Dicas Essenciais de Administração de Servidores SQL
- Fundamentos do Servidor SQL – Base de Dados SQL para Principiantes
- Dicas Essenciais de Desenvolvimento de Servidores SQL para Programadores SQL
- A Filosofia e os Fundamentos da Programação de Computadores
- NET Programming for Beginners – Windows Forms with C#
li>Introduction to Data Science and SQL Server Machine Learningli>Introduction to Azure SQL Database for Beginnersli>SQL Server 2019: O que há de novo – Características novas e melhoradasli>Entity Framework: Introdução – Guia Completo para Principiantesli>Como Importar e Exportar Dados em Bases de Dados SQL Serverli>Aprenda Como Instalar e Começar a Utilizar o SQL Server em 30 Minsli>Guia de Como Começar e Rentabilizar um Blog de Sucesso
Artigos Relacionados com a Administração do SQL Server:
- Dicas Essenciais de Administração de Sever SQL
- Como Patchar uma Instância de Servidor SQL Autónomo
- O Serviço de Navegação do Servidor SQL e Porta UDP 1434
- O Número Máximo de Ligações Concorrentes in SQL Server
- Top 10 SQL Server DBA Daily Tasks List
- Não há nenhum Cluster de Failover do SQL Server disponível para aderir
- Encrypting a SQL Server Database Backup
- …more
Clique este artigo: 
(2 votos, média: 5.00 de 5)
/p>
Loading…
Referência: SQLNetHub.com (https://www.sqlnethub.com)
© SQLNetHub
