Revista Eletrônica da FANESE ISSN

Transcrição

1 REPLICAÇÃO E ALTA DISPONIBILIDADE NO SQL SERVER 2012 Renata Azevedo Santos Carvalho 1 RESUMO Neste artigo serão relatadas as novidades que o SQL Server 2012 vem trazendo nesta sua nova versão no que se refere a soluções de auto-disponibilidade e de replicação de bases. A grande novidade é o SQL Server AlwaysOn, considerado uma solução simples e unificada, de fácil gerenciamento e implementação, que traz uma redução de custos devido a possibilidade de reutilização de hadware já existente, melhor utilização dos servidores, e maior retorno sobre o investimento. Serão detalhados as duas soluções do AlwaysOn, a AlwaysOn Availability Groups que atua no nível de banco de dados e o AlwaysOn Failover Cluster Instances que atua na proteção no nível de instâncias. Por fim será exposto neste que SQL Server AlwaysOn veio para facilitar as complexidades do Failover Cluster Instance, do Data Base Mirroring e do Log Shipping. Palavras chaves: SQL Server AlwaysOn, Mirroring, Log Shipping, Clustering 1 INTRODUÇÃO Atualmente boa parte dos negócios estão informatizados, desde os Bancos aos pequenos estabelecimentos no comércio. Todos usam algum determinado sistema que armazena as informações que aparecem na tela do computador, essas informações são armazenadas em um banco de dados. 1 Bacharel em Ciência da Computação pela Universidade Tiradentes UNIT. Mestre em Ciência da Computação pela Universidade Federal de Pernambuco UFPE. MCTS em Sql Server Professora universitária da Faculdade de Administração e Negócios de Sergipe FANESE. Analista de Banco de Dados do Sergipe Parque Tecnológico - SERGIPETEC. renatamsdn@gmail.com

2 Quando fazemos alguma consulta do nosso saldo bancário, por exemplo, o sistema vai buscar essas informações dentro do banco de dados e a cada dia que passa, nós usuários exigimos mais agilidade no retorno da informação quando solicitada, por conta disso existem configurações que são feitas para que o banco de dados trabalhe de uma forma melhor e trazendo as informações mais rápidas ao usuário final, além de deixar o banco de dados sempre disponível ou o mínimo de tempo possível inativo visível ao usuário final. 2 REPLICAÇÃO A replicação, como o próprio nome já diz, serve para replicar, copiar e no banco de dados não é diferente. A replicação copia e distribui os dados de um banco para outro deixando assim sincronizados para manter a consistência dos dados. Dessa forma os dados podem ser distribuídos para locais diferentes tanto em rede local quanto em longas distâncias através da internet. A Microsoft fornece três tipos de replicações: Instantâneo, Tradicional e Mesclagem. De acordo com as informações obtidas no site da MSDN ( vamos conhecer um pouco sobre cada tipo de replicação. 2.1 Replicação de Instantâneo A replicação de instantâneo distribui os objetos e dados especificado por uma publicação exatamente como eles aparecem em um momento específico e não monitora as atualizações dos dados. Quando há a sincronização, todo o instantâneo gerado é enviado aos Assinantes. O processo de replicação de instantâneo é usado também para fornecer o conjunto inicial dos dados e objetos do banco para as publicações de mesclagem e tradicionais.

3 De acordo com a Microsoft, o uso da replicação de instantâneo por si só é mais apropriado quando: As alterações de dados ocorrerem raramente. É aceitável ter cópias de dados desatualizadas em relação ao Publicador por um período de tempo. Replicação de pequenos volumes de dados. Um volume grande de alterações ocorre por um curto período de tempo. A replicação de instantâneo é mais apropriada quando as alterações de dados forem significativas, mas pouco frequentes. Por exemplo, se uma empresa de vendas mantiver uma lista de preços de produtos e os preços forem todos atualizados ao mesmo tempo uma ou duas vezes por ano, é recomendada a replicação de todo o instantâneo de dados após ele ter sido alterado. Ao ter certos tipos de dados determinados, os instantâneos mais frequentes também podem ser apropriados. Por exemplo, se uma tabela relativamente pequena for atualizada no Publicador durante o dia, mas alguma latência for aceitável, as alterações podem ser distribuídas pela noite como um instantâneo. (MSDN Brasil) Como Funciona? Independente do tipo de replicação que for usado, sempre terá que existir uma replicação de instantâneo para inicializar os assinantes. De acordo com a Microsoft os instantâneos podem ser gerados e aplicados imediatamente após a assinatura ser criada ou de acordo com uma programação definida no momento que a publicação for criada. O Agente de Instantâneo prepara os arquivos de instantâneo que contêm o esquema e os dados das tabelas publicadas e os objetos do banco de dados, armazena os arquivos na pasta do instantâneo para o Publicador e registra o rastreamento de informações do banco de dados de distribuição no Distribuidor. Você especifica uma pasta padrão de instantâneo quando configura um Distribuidor, mas você pode especificar um local alternativo para uma publicação além do padrão.

4 2.2 Replicação Transacional Figura 1 Os principais componentes de replicação de instantâneo. Como dito anteriormente (no tópico de Replicação Instantâneo), a replicação tradicional é iniciada com um instantâneo criando uma cópia dos objetos e dos dados do banco de publicação. Após o instantâneo inicial é tirado, as próximas alterações ocorridas no Publicados são distribuídas para os assinantes quase em tempo real. Essas alterações são aplicadas na mesma ordem e nos mesmos limites

5 de transação que ocorreram no publicador. Desta forma, a consistência transacional é considerada como assegurada. De acordo com a Microsoft, a replicação transacional é normalmente usada em ambientes do tipo servidor para servidor e é apropriada em cada um dos seguintes casos: Você quer que as alterações com incremento sejam propagadas para os Assinantes à medida que ocorrem. O aplicativo requer baixa latência entre as mudanças de hora feitas no Publicador, assim as mudanças chegarão ao Assinante. O aplicativo requer acesso aos estados de dados intermediários. Por exemplo, se uma linha muda cinco vezes, a replicação transacional permite que um aplicativo responda a cada mudança (como acionar um gatilho), e não simplesmente uma mudança de dados da rede na linha. O Publicador tem um volume muito alto de atividade de inserção, atualização e exclusão. O Publicador ou Assinante é um banco de dados que não é do tipo SQL Server, como Oracle Como Funciona? A replicação transacional é implementadas por 3 agentes: Agente de Instantâneo, de Leitor de Log e de Distribuição do SQL Server. Vamos entender o que cada um faz: O Agente de Instantâneo é responsável por preparar os arquivos de instantâneo que contêm o esquema e os dados das tabelas publicadas e os objetos do banco de dados, armazena os arquivos na pasta do instantâneo e registra os trabalhos de sincronização do banco de dados de distribuição no Distribuidor. O Agente de Leitor de Log é responsável por monitorar o log de transações de cada banco de dados configurado para replicação transacional e copia as

6 transações marcadas para replicação do log de transações no banco de dados de distribuição. O Agente de Distribuição copia os arquivos do instantâneo inicial da pasta de instantâneo e as transações contidas nas tabelas do banco de dados de distribuição para os Assinantes. Figura 2 Principais componentes de replicação transacional

7 2.3 Replicação de Mesclagem Assim como a replicação transacional, a replicação de mesclagem também é iniciada com uma replicação de instantâneo. Após essa replicação as alterações posteriores ocorrentes pelo Publicador e Assinantes são rastreadas com gatilhos. De acordo com a Microsoft, a replicação de mesclagem é normalmente usada em ambientes de servidores para clientes e é mais apropriada nas seguintes situações: Diversos Assinantes podem atualizar os mesmos dados diversas vezes e propagar essas alterações para o Publicador e outros Assinantes. Os Assinantes precisam receber dados, fazer alterações offline e sincronizar posteriormente as alterações com o Publicador e outros Assinantes. Cada Assinante requer uma partição diferente de dados. Conflitos podem ocorrer e, quando isto acontecer, você precisará do recurso para detectá-los e encontrar a solução. O aplicativo requer a alteração nos dados da rede no lugar do acesso aos estados de dados intermediários. Por exemplo, se uma linha for alterada cinco vezes em um Assinante antes de ele sincronizar com um Publicador, a linha será alterada somente uma vez no Publicador pra refletir a alteração dos dados na rede (ou seja, o quinto valor). Nesse ambientes tanto o publicador como seus assinantes podem fazer atualizações e, quando forem mescladas, poderão ocorrer conflitos. A replicação de mesclagem oferece várias maneiras para se controlar os conflitos.

8 Figura 3 Componentes usados em replicação de mesclagem O tipo de replicação que você escolhe para um aplicativo, depende de muitos fatores, incluindo o ambiente físico da replicação, o tipo e a quantidade de dados a serem replicados e se os dados serão ou não atualizados no Assinante. O ambiente físico inclui o número e local dos computadores envolvidos na replicação e se esses computadores são clientes (estações de trabalho, laptops ou dispositivos portáteis) ou servidores. Cada tipo de replicação começa normalmente com uma sincronização inicial dos objetos publicados entre o Publicador e os Assinantes. Esta sincronização inicial pode ser executada por replicação com um instantâneo, que é uma cópia de todos os objetos e dados especificados por uma publicação. Depois que o instantâneo é criado, ele é distribuído aos Assinantes. Para alguns aplicativos, a replicação de

9 instantâneo é tudo o que é necessário. Para outros tipos de aplicativos, é importante que as alterações de dados subsequentes fluam para o Assinante de forma incremental com o passar do tempo. Alguns aplicativos também exigem que as alterações fluam do Assinante de volta para o Publicador. A replicação transacional e a replicação de mesclagem fornecem opções para estes tipos de aplicativos. As alterações de dados não são rastreadas para a replicação de instantâneo. Sempre que um instantâneo é aplicado, ele sobrescreve por completo os dados existentes. A replicação transacional rastreia as alterações pelo log de transação do SQL Server e a replicação de mesclagem rastreia as alterações pelos gatilhos e tabelas de metadados. 3 ALTA DISPONIBILIDADE O SQL Server disponibiliza várias soluções de alta disponibilidade que melhoram a disponibilidade dos servidores. A ideia da alta disponibilidade é mascarar as possíveis falhas de hardware ou software e mantém a disponibilidade dos aplicativos de forma que o usuário não perceba ou tenha o menor tempo de inatividade possível. O SQL Server disponibiliza as seguintes opções de alta disponibilidade: 3.1 Cluster de failover O cluster de failover proporciona suporte de alta disponibilidade para uma instância inteira do SQL Server. Um cluster de failover é uma combinação de um ou mais nós, ou servidores, com dois ou mais discos compartilhados. Aplicativos são instalados em um grupo de clusters do Microsoft Cluster Service (MSCS) conhecido como grupo de recursos. A qualquer momento, cada grupo de recursos pertence a apenas um nó do cluster. O serviço de aplicativo tem um nome virtual que é independente dos nomes de nó e é chamado de nome de instância do cluster de failover. Um

10 aplicativo pode se conectar à instância do cluster de failover fazer referência ao nome dela. O aplicativo não tem precisa saber qual nó hospeda a instância do cluster de failover. (MSDN Brasil). O cluster de failover pode ser usado para reduzir o tempo de inatividade do sistema e oferecer a maior disponibilidade, ele não protege contra falhar de disco. 3.2 Espelhamento de banco de dados O espelhamento de banco de dados é basicamente uma solução de software para aumentar a disponibilidade do banco de dados, dando suporte a failover quase instantâneo. O espelhamento de banco de dados pode ser usado para manter um único banco de dados de espera, ou banco de dados espelho, para um banco de dados de produção correspondente, que é referido como o banco de dados principal. (MSDN Brasil). No espelhamento, o banco de dados espelho fica inacessível aos clientes, porém pode ser usado indiretamente para relatórios. 3.3 Envio de logs Como o espelhamento de banco de dados, o envio de logs opera no nível do banco de dados. Você pode usar o envio de logs para manter um ou mais bancos de dados de espera passiva para um banco de dados de produção correspondente, que é referido como o banco de dados primário. Os bancos de dados de espera também são referidos como bancos de dados secundários. Cada banco de dados secundário é criado pela restauração de um backup do banco de dados principal sem recuperação ou com espera. A restauração com espera permite usar o banco de dados secundário resultante para relatório limitado. (MSDN Brasil). 3.4 Replicação A replicação usa um modelo de publicação/assinatura. Isso permite que um servidor primário, conhecido como Publicador distribua os dados para um ou mais servidores

11 secundários, ou Assinantes. A replicação possibilita disponibilidade em tempo real e escalabilidade entre esses servidores. Suporta filtragem para fornecer um subconjunto de dados nos Assinantes e também permite atualizações particionadas. Os assinantes ficam online e disponíveis para relatórios e outras funções, sem recuperação de consultas. (MSDN Brasil) 3.5 Bancos de dados compartilhados escalonáveis O recurso de banco de dados compartilhado evolutivo permite expandir um banco de dados somente leitura criado exclusivamente para relatórios. O banco de dados de relatório deve residir em um conjunto de volumes dedicados somente leitura cuja finalidade principal é hospedar o banco de dados. Usando o hardware de mercadoria para servidores e volumes, você pode expandir um banco de dados de relatório que fornece a mesma exibição de dados de relatório em vários servidores de relatório. Esse recurso também permite um caminho de atualização simples para o banco de dados de relatório. (MSDN Brasil) 4 APOSTAS DA MICROSOFT PARA ALTA DISPONIBILIDADE NO SQL SERVER 2012 A última versão do SQL Server veio voltado para a alta disponibilidade. Coisas que poderiam serem feitas com a versão anterior (SQL Server 2008 R2), agora estão com melhorias significativas nos cenários de HÁ (High Avaiability) e DR (Disaster Recovery). A solução passou a ser chamada de SQL Server AlwaysOn. Como parte da oferta do SQL Server AlwaysOn, as instâncias de cluster de failover do AlwaysOn aproveitam a funcionalidade WSFC (Windows Server Failover Clustering) para fornecer alta disponibilidade local por meio de redundância na instância de nível de servidor, uma FCI (instância de cluster de failover). Uma FCI é uma instância única do SQL Server que é instalada em nós de WSFC (Windows

12 Server Failover Clustering) e, possivelmente, em várias sub-redes. Na rede, uma FCI aparece ser uma instância do SQL Server sendo executada em um único computador, mas proporciona failover de um nó do WSFC para outro se o nó atual se tornar indisponível. (MSDN Brasil). Esse novo recurso permite realizar a proteção em alto nível com o Failover de diversos banco de dados, possuir múltiplos secundários, entre outras. 4.1 AlwaysOn Availability Groups Esse novo recurso possibilita a habilidade de realizar failover automático ou manual de grupos de bancos de dados, podendo possuir até quatro locais secundários. Essa nova solução provê proteção de todas as informações sem perda de dados e é totalmente flexível. A mesma pode ser realizada com armazenamento local ou compartilhado, diferente do Cluster, e ainda possuindo movimento dos dados entre os eles de forma síncrona ou assíncrona. Uma de suas grandes qualidades é o failover entre instâncias assim como reparação de páginas danificadas. (MORENO, Luan).

13 Figura 4 A primeira réplica replicando os dados de forma síncrona para duas réplicas no mesmo datacenter e ainda provendo a réplica 4 que está no servidor secundário a informações de forma assíncrona Possibilidades do AlwaysON 4.2 Availability Replica Roles Cada Availability Group, ou seja, cada grupo contendo diversos bancos de dados, deverá possuir 2 ou mais parceiros que são chamados de Availability Replicas ou seja replicas idênticas, para que assim o failover de uma máquina para outra possa acontecer. Cada instância do SQL Server no Availability Group é armazenada no Failover Cluster Instance (FCI). Esse recurso provê em nível servidor a alta disponibilidade das máquinas e recursos utilizados. Cada Réplica do Availability Group armazena uma cópia idêntica dos bancos de dados em cada servidor e instância do banco de dados. (MORENO, Lucas) 4.3 Modos de Sincronização de Dados A réplica de dados pode ser feita de forma síncrona ou assíncrona. De acordo com Lucas Moreno a transação síncrona para ser efetivada deverá ser aceita em ambos

14 os servidores, ocorrendo assim uma considerável latência em rede. Essa opção é recomendada para servidores que compartilham uma rede de alto nível. Já a forma assíncrona a transação é aceira sem o parceiro ter escrito a informação ainda em disco, aumentando assim o desempenho entre os servidores. 4.4 Modos de Failover nos Availability Groups Existem dois motos de comportamento para o Failover no Availability Group: O Automatic Failover que usa o modo de sincronização síncrona, dessa forma o failover pode ser manual ou automático; o Manual Failover usa o modo de sincronização síncrona como assíncrona, dessa forma, possui o direito de realizar somente um Failover Manual entre os parceiros. 5 CONSIDERAÇÕES FINAIS Nesse artigo foi relatado sobre a nova solução de alto disponibilidade e Disaster Recovery chamada de AlwaysOn, dando ênfase o Availability Group que é uma nova e abrangente solução de alta disponibilidade e Disaster Recovery que atuando no nível de banco de dados proporciona: Failover de múltiplos bancos de dados para aplicações que requerem múltiplos bancos de dados em uma única instância. Conectividade e redirecionamento automático da aplicação através da implementação do Avilbility Group Listener e nome virtual; Compressão e criptografia integrada; Sincronização de dados de forma síncrona ou assíncrona para até 4 nós. Reparação automática de páginas corrompidas Servidores secundários disponíveis para leitura; Suporte a FILESTREAM, FILETABLE e Service Broker;

15 Configuração simplificada com o uso de Wizard, integração com PowerSell e monitoração através de um Dashboard; Suporta até 3 réplicas síncronas sendo uma primária e duas secundárias; Permite o failover de múltiplos bancos de dados removendo a necessidade de lógicas complexas. REFERÊNCIAS BIBLIOGRÁFICAS acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/ acessado em 15/11/2012

16 acessado em 15/11/ acessado em 22/11/ acessado em 22/11/2012