O Microsoft SQL Server é um banco de dados com muitos recursos relacionados à replicação, espelhamento e cluster contra falhas. Todas elas são estratégias e configurações cuja finalidade é, com diferentes formas de atuação, tornar os dados sempre disponíveis para aplicativos clientes, em caso de falhas e desserviços ou simplesmente para replicar dados em locais mais geográficos para aumentar a disponibilidade, visando manter o desempenho e disponibilidade.
Neste tutorial, não comentaremos sobre Clustering contra Falhas ou Grupos de Disponibilidade Contínua, que são procedimentos de espelhamento de banco de dados com o objetivo principal de garantir a disponibilidade contínua de todos os serviços de forma rápida, em caso de desvios ou falhas no servidor. Pelo contrário, vamos nos concentrar nos procedimentos de replicação do banco de dados, ou seja, todas as configurações que permitem aos usuários ter todos os dados sendo replicados em mais Servidores SQL, de forma automática e em tempo real.
O SQL Server possui 4 tipos de procedimentos para replicação:
- Transactional
- Mesclar (Merge)
- Instanciado (Snapshot)
- Ponto-a-Ponto (Peer-to-Peer)
A replicação Ponto-a-Ponto é uma solução orientada para Escalabilidade Horizontal em alta disponibilidade, permitindo gerenciar muitas cópias de dados em mais instâncias do servidor, chamadas “nós”. Com base na replicação transacional, a replicação Ponto-a-Ponto propaga mudanças de dados para todos os nós quase em tempo real. Graças a essa redundância, os aplicativos que solicitam a escalabilidade horizontal das operações de leitura podem dividir os processos de leitura dos clientes em múltiplos nós, e acessar dados de forma muito mais rápida. Este tipo de replicação é absolutamente um dos procedimentos de replicação mais executados e “à prova de falhas”, pois a falta de disponibilidade de um ou mais nós não afeta o funcionamento e a disponibilidade de todo o sistema em si.
No entanto, a replicação Ponto-a-Ponto está disponível apenas na versão do SQL Server Enterprise, com custos de licença obviamente muito caros em relação a outras versões. Uma boa escolha alternativa, ao alcance de pequenas e médias empresas além de estável e flexível para configurar é a replicação por mesclagem, sobre a qual falaremos agora.
Começaremos imediatamente com a prática, iniciando com o necessário para configurar uma replicação por mesclagem e em seguida, como configurá-la em algumas simples etapas .
Consideramos 3 Servidores SQL Server 2014, sendo geograficamente distantes e em execução em diferentes redes. O esquema final que obteremos é o mostrado na figura abaixo:
É preciso um servidor primário principal que nomearemos aqui como Editor e servidores secundários nomeados Assinantes. Os Assinantes irão sincronizar seus próprios dados com o Editor (enviar e receber) e, como consequência disso também os dados de cada Assinante estarão em sincronia com os outros. Portanto, a primeira coisa a fazer é decidir qual dos três servidores atuará como Editor e em seguida, prosseguir com sua configuração, conforme exibido abaixo.
Em primeiro lugar, asseguremos que o serviço do SQL Server Agent seja iniciado e configurado no modo automático, caso contrário, vamos executá-lo.
PASSO 1: Criando uma publicação no servidor Editor
Começaremos a configurar todas as diferentes opções dentro da janela “New Publication Wizard”. Agora vamos direto para a primeira janela:
Agora selecionaremos base de dados que desejamos sincronizar:
Definiremos o tipo de replicação que desejamos configurar, será do tipo “Merge publication“:
Na próxima janela, manteremos a compatibilidade padrão então clicando em “Next”:
Agora, uma etapa muito importante da nossa instalação: escolhendo qual tabela de banco de dados queremos sincronizar. Selecionando-as de forma muito simples:
Na próxima janela, o assistente avisará sobre o novo campo ID a ser adicionado às tabelas selecionadas para identificar de forma individual os registros.
Na próxima janela, seremos perguntados também se desejamos adicionar filtros aos dados a serem sincronizados. Neste tutorial, não usaremos nenhum filtro, então vamos seguir clicando em “Next”:
Nas janelas a seguir, verificaremos as opções conforme definidas por padrão e depois continuaremos:
Agora, há outro passo importante da nossa instalação, que é a configuração das contas para executar o serviço de replicação (agente) e se conectar ao Editor, portanto, neste caso, para si próprio.
Na janela mais à direita, vamos escrever o nome de usuário do Administrador do servidor, colocando o servidor ou o nome do domínio na frente dele. Neste tutorial, consideremos que o nome do servidor é “EDITOR(PUBLISHER)”.
Na janela mais à esquerda, vamos colocar a conta do SQL Server, com quem é possível conectar-se ao banco de dados com privilégios máximos. Neste tutorial usamos o usuário SQL padrão “sa”.
Nota: a melhor coisa a fazer é ter o mesmo nome de usuário do SQL Server e a mesma senha em todo o servidor do banco de dados (tanto no editor como nos assinantes).
Confirmamos tudo clicando em OK e seguimos para a próxima janela.
Na janela a seguir, veremos a opção”Create the publication” e clique em “Next”:
Finalmente, o resumo de todas as configurações será mostrado e agora podemos criar a publicação clicando em “Finish”:
Uma nova janela será aberta, mostrando o progresso do instanciamento inicial, e ambas as operações devem ser concluídas corretamente.
PASSO 2: Configurar como o servidor Editor irá permite os assinantes acessarem dados publicados: Servidor FTP
Uma das configurações de replicação mais fundamentais é como os assinantes podem acessar os dados “publicados” pelo servidor Editor. Fisicamente falando, o Editor cria periodicamente uma instância de seus dados em uma pasta local e, em seguida, atualiza-o com as mudanças de dados. Portanto, devemos garantir que os assinantes possam ter acesso total a esse instanciamento para que possam sincronizar seus dados com o editor. Uma vez que em nosso tutorial estamos falando de servidores remotos (portanto, não dentro da mesma LAN), a maneira como escolhemos disponibilizar os dados para assinantes é o FTP (pois seria impossível usar uma pasta simples compartilhada pela rede) .
Então, temos que configurar no Editor um Servidor FTP que disponibilize remotamente para os assinantes a pasta onde o instanciamento de dados permanece. Podemos usar tanto o servidor FTP do IIS que é o padrão do Windows e um terceiro, como o FileZilla Server. Para a configuração de FTP dentro do IIS, consulte o guia oficial da Microsoft [ clicando aqui ].
Em primeiro lugar, temos que fazer uma alteração na publicação que acabamos de criar, para permitir o FTP como método de acesso aos dados publicados:
Vamos configurar a conexão (as configurações devem refletir a configuração do servidor de FTP). Informamos nome do servidor FTP (o mesmo que o próprio nome do servidor), a porta (21 o padrão, mas, devido a razões de segurança, também podemos especificar uma diferente), o nome de usuário e a senha do FTP (se estiver usando o IIS , escolheremos um nome de usuário do Windows, garantindo que seja um administrador, caso contrário, se estiver usando outro servidor de FTP, vamos usar o usuário que configuramos dentro dele). Finalmente, especificamos o caminho relativo da pasta que contém o instantâneo, considerando-o como a partir da raiz do servidor FTP. Ao configurar este procedimento, o SQL Server cria (por padrão) uma pasta chamada “ftp” (com o instanciamento de dados dentro) no caminho “C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\repldata”. Esse caminho deve ser configurado como root do servidor FTP e, portanto, o caminho relativo a ser configurado dentro desta janela será “/ ftp”, como mostrado na seguinte imagem:
Nota: será necessário abrir a porta FTP usando uma regra específica no firewall do Windows do servidor Editor. Além disso, ocorrendo erros de conexão, apesar da correta configuração no firewall no Publicador, isso também pode ser devido ao firewall do Assinante. Para verificar isso, tente desabilitar completamente o firewall do Assinante e, em seguida, tente novamente a sincronização. Posteriormente, você pode ativar o firewall novamente e, eventualmente, adicionar as regras apropriadas.
Nota 2: um erro na sincronização (no assinante) pode significar que essa configuração de FTP não foi feita corretamente. O assinante, ao acessar os dados, pode encontrar um erro genérico, levando a uma interrupção anormal do agente / trabalho de sincronização (erros como “o agente não está em execução”, ou falha junto com despejos de memória). Nessas situações, não deixe ser enganado por mensagens de erro como essa que podem se referir a problemas completamente diferentes, mas vamos verificar novamente essa configuração. Um primeiro teste poderia ser conectar-se do servidor remoto (um assinante) com qualquer outro software de cliente FTP, como o FileZilla, para ter certeza de que a conexão está correta e as pastas estão acessíveis.
Nota 3: a pasta “C: \ Program Files \ Microsoft SQL Server \ MSSQL12.MSSQLSERVER \ MSSQL \ repldata” e sua subpasta relativa “/ ftp” pode não estar acessível devido a problemas de permissões. Em caso de problemas que não sejam facilmente reconhecíveis, faremos imediatamente um teste definindo as permissões desta pasta para “Todos” -> “Controle total”.
Agora, depois de todas as configurações realizadas. Iremos verificar no “View snapshot agent status” se os instanciamentos são feitos corretamente com o “Launch Replication monitor” para ver se os assinantes estão sincronizando corretamente (até não configurar um assinante, ele permanecerá vazio).
Se no Publisher tudo estiver configurado corretamente, vamos agora configurar um assinante e, em seguida, executar a primeira sincronização de dados.
STEP 3: Criando a assinatura e os Assinantes
Pré-requisito: asseguremos que o serviço do SQL Server Agent esteja sendo executado nos assinantes.
Agora vamos ao SQL Server que se conectará ao servidor principal como um Assinante e depois sincronizará os dados. Dentro do menu “Replication”, vamos clicar com o botão direito do mouse em “Local Subscriptions” e depois em “New Subscriptions”.
Quanto à publicação, uma página do assistente será exibida:
Na janela a seguir, temos que nos conectar ao servidor do Editor para ver e selecionar sua publicação (a que fizemos anteriormente):
Aqui estão alguns passos de configuração fundamentais para garantir uma conexão correta. De fato ao procurar um editor, podemos conectar-se a ele apenas especificando o nome do servidor mas não o endereço IP (com ou sem uma porta específica). Isso significa que, neste sistema, devemos “mapear” de alguma forma o endereço IP do servidor Editor usando seu nome. Podemos fazer isso criando um Alias com a janela de configuração dos serviços do SQL Server, conforme mostrado na figura abaixo:
Vamos adicionar um alias com o nome do servidor remoto Editor, seu endereço IP e a porta do SQL Server, em ambos os caminhos dos “Aliases”.
Isso permitirá conectar-se a servidores SQL remotos apenas usando nomes e não endereços IP. É fundamental abrir a porta do SQL Server (aqui podemos ver o padrão) nos servidores. Ao clicar em “Find SQL Server Publisher”, seremos convidados a conectar-se ao servidor SQL Editor, então a janela de autenticação padrão do SQL Server exibirá a seguinte janela:
Uma vez autenticado, poderemos ver a publicação que criamos no editor, depois selecioná-lo e continuar:
No próximo passo manteremos as opções padrão:
Na janela a seguir, selecionaremos o banco de dados para sincronizar. Podemos criar este banco de dados no assinante apenas restaurando uma cópia do banco de dados principal que temos no editor.
Conforme mostrado na imagem, há o nome do servidor do assinante (chamamos “SUBSCRIBER” neste exemplo) e o nome do banco de dados.
Posteriormente, definiremos as credenciais necessárias para a autenticação. Usaremos a conta Administrador do Windows no primeiro painel e a conta do SQL Server no segundo (como fizemos antes com o editor).
No próximo passo, que consiste em configurar QUANDO executar a sincronização de dados. É possível configurá-lo em tempo real (sincronização contínua) ou agendá-lo definindo um intervalo de tempo. É apenas um agendamento padrão do Windows. Se precisamos de dados para serem continuamente sincronizados, também podemos escolher um intervalo de 10 segundos. Caso contrário, um intervalo de minutos / horas / dias também será suficiente.
Na janela a seguir, vamos definir a assinatura a ser inicializada imediatamente:
Finalmente, vamos configurar o assinante para executar também no modo servidor: isso significa que o assinante não só recuperará os dados do editor, mas também enviará seus próprios dados, implicando uma sincronização bidirecional. Manteremos a opção padrão para a prioridade de resolução de conflito:
Na última janela bast clicar em “Finish” para criar a assinatura e iniciar a sincronização:
Vamos verificar se a sincronização está funcionando corretamente, apenas abrindo a janela de status de sincronização (veja a figura abaixo):
A sincronização está corretamente em execução!
Seguindo exatamente todas as etapas deste tutorial, configuramos corretamente uma sincronização de dados entre dois (ou mais) SQL Server remoto sem problemas.
Claramente, é possível encontrar alguns erros devido ao procedimento articulado, mas com alguns pequenos truques é possível realizar uma configuração muito estável e eficiente.
No site da Microsoft, podemos encontrar muita documentação sobre como otimizar e configurar a replicação do banco de dados:
Olá… Obrigado por compartilhar esse conteúdo.
Pretendo usar esse método para sempre deixar meu BD de homologação atualizado. É viável realmente fazer dessa forma?
É possível replicar somente os dados de um servidor para o outro ao invés de fazer um merge?
Hi,
Yes, it’s possible, the replication can be also one direction.