Replicação de servidores de banco de dados

Replicação de servidores de banco de dados Cresce cada vez mais dentro das organizações a necessidade de garantir a alta disponibilidade das informações. Como a base de dados de qualquer empresa é seu bem mais precioso, é necessário garantir a alta disponibilidade, a performance no acesso aos dados e também a segurança dessas informações. Podemos dizer que uma boa política de backup é suficiente para garantir a segurança dos dados em caso de desastre ou qualquer falha que possa ocorrer com as bases de dados, mas no mundo de hoje, competitivo e em desenvolvimento constante, só isso não basta, é preciso que os dados estejam disponíveis 100% do tempo. As empresas precisam cada vez mais garantir a continuidade do negócio. Por mais que ocorra qualquer falha de sistema, as empresas não estão mais toleráveis a espera da restauração de uma base de dados ou de um sistema. Para uma empresa, um sistema parado é sinônimo de prejuízo. Imagine o Call Center de uma grande empresa com seu sistema parado por uma hora, onde são efetuadas milhares de vendas. Isso seria desastroso e com certeza significaria um prejuízo considerável. Por esta e várias outras razões, para a grande maioria, não é aceitável tempo de espera para recuperação de falhas. Neste contexto, vamos entender como a Replicação de Dados pode nos ajudar a garantir a alta disponibilidade dos ambientes de bases de dados, a performance na manipulação e recuperação destes dados e também na segurança. Também vamos entender a importância de se manter uma documentação sobre os ambientes de Banco de Dados atualizada e com uma gama de informações importantes para ajudar na implantação de projetos de Replicação de Dados. Replicação de Dados A Replicação de Dados nos permite configurar e/ou desenvolver a distribuição de dados entre ambientes homogêneos ou heterogêneos, ou seja, nos permite distribuir informações a partir de uma base de dados em um servidor de origem, para uma ou várias bases de dados em outros servidores de destino. As instâncias e suas bases de dados, nos servidores de origem e destino, podem

estar executando sobre SGBDs (Sistemas Gerenciadores de Bancos de Dados) distintos, isso não é um limitador para que seja desenvolvida e configurada a Replicação de Dados. Podemos por exemplo: ter no servidor de origem, uma instância do SQL Server sendo executada e no servidor de destino, para onde serão replicados os dados, uma instância Oracle. Na replicação temos controle absoluto de como e quando ela ocorrerá, uma vez que tudo isso é definido na sua implementação e configuração. Mas a replicação não nos permite simplesmente distribuir os dados, também podemos, em um estágio da replicação, configurar a transformação destes dados para em seguida distribuí-los entre os servidores de destino, por exemplo: uma empresa possui dois sistemas distintos e um deles está substituindo o outro, entretanto, os dois precisam permanecer no ar até que o sistema legado seja completamente desativado. Esses sistemas possuem bases de dados diferentes e a forma de armazenamento dos dados também são diferentes. Então, podemos configurar a replicação de dados com um nível de transformação destes dados antes de serem distribuídos para a base de dados do novo sistema. Por esta razão os sistemas de replicação de dados também são utilizados em larga escala como recurso de ETL - Extract Transform Load (Extração Transformação Carga), considerada uma das fases mais críticas em projetos de Data Warehouse. Podemos projetar a replicação de dados de forma a atender as necessidades de uma ampla variedade de ambientes. A arquitetura da Replicação de Dados é dividida em uma série de análises, configurações, procedimentos e componentes distintos. Cada nível pode ser personalizado de forma a atender uma situação particular da replicação. A partir de agora discutiremos alguns itens da arquitetura da replicação. Projetando a necessidade da replicação : O primeiro passo, é conhecer e identificar o que precisa ser replicado. Nem todas as tabelas ou todos os dados de uma tabela, precisam ser replicados. Nós precisamos sempre ter em mente, que só devemos trafegar os dados que realmente são necessários. Um erro muito comum nos projetos de replicação que identifico, é que nem tudo aquilo que está sendo replicado, é necessário. Vou dar um exemplo bem prático: Uma fábrica de calçados, resolveu abrir uma nova filial para atender somente a demanda de chinelos, enquanto a matriz, realizava a fabricação de sapatos e botas. Quando foi montada a replicação para o banco de dados que ficava na filial, não foi dada a devida a atenção aos dados que seriam replicados, dessa forma, a replicação ficava enviando informações de toda a produção de sapatos e botas do banco de dados da matriz para o banco de dados da filial, e isso não era preciso. Ao identificar esse problema, reduzimos o tempo

de replicação, o custo de banda de link e espaço em disco no banco de dados da filial. Obviamente, precisamos também que a modelagem do banco de dados a ser replicado, esteja com as formas normais aplicadas. O que eu quero dizer com tudo isso? Não se prendam somente a simplesmente montar a replicação, selecionar as tabelas e colocar no ar. Existe todo um trabalho de levantamento das necessidades e conhecimento do que realmente iremos replicar. Entendam o negócio, conheçam o modelo de dados e conversem muito com os analistas/desenvolvedores da aplicação em questão. Um escopo bem definido irá te ajudar e muito na hora da mão na massa no SQL Server. Não se esqueçam também de avaliar todas as dependências das tabelas replicadas, atentem-se a verificar as foreign keys existentes e replicar as tabelas correspondentes também. Outro fator importante e muito relevante no projeto, de quanto em quanto tempo eu terei que replicar as informações? Esse é outro dado que impacta totalmente na decisão de implantar uma replicação ou investir numa tecnologia para acesso remoto ao servidor de banco de dados. Se você necessita que as informações sejam atualizadas numa frequência alta, quase que on-line, não teria o porque implantar uma replicação. Invista num link forte e coloque suas informações publicadas para as filiais, salvo os casos em que o banco de dados seja criado para geração de relatórios, e assim diminuir uma grande carga do servidor de banco de dados principal. Exemplo de configuração de replicação de Dados utilizando SQL Server 2008 : Listagem 1: Criação do database e tabelas utilizadas no exemplo USE [master] GO CREATE DATABASE [DBMatriz] GO USE DBMatriz GO CREATE TABLE [dbo].[tbacao]( [idacao] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, [idacaotipo] [int] NOT NULL, [idacaostatus] [int] NOT NULL, [dtsolicitacao] [smalldatetime] NOT NULL,

[idusuariosolicitacao] [int] NOT NULL, [dtexecucao] [smalldatetime] NULL, [idusuarioexecucao] [int] NULL, [obsexecucao] [varchar](255) NULL, [dsacao] NULL, [obssolicitacao] [varchar](255) NULL, CONSTRAINT [PK_tbAcao] PRIMARY KEY CLUSTERED ( [idacao] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO CREATE TABLE [dbo].[tbacaopedido]( [idacaopedido] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, [idacao] [int] NOT NULL, [idpedido] [bigint] NOT NULL, CONSTRAINT [PK_tbAcaoPedido] PRIMARY KEY CLUSTERED ( [idacaopedido] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO CREATE TABLE [dbo].[tbacaotipo]( [idacaotipo] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, [nmacaotipo] [varchar](120) NOT NULL, [idusuariogrupo] [int] NOT NULL, CONSTRAINT [PK_tbAcaoTipo] PRIMARY KEY CLUSTERED ( [idacaotipo] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY] O primeiro passo que devemos realizar, é habilitar a replicação no servidor de banco de dados que será replicado. Durante a instalação, selecione a opção SQL Server Replication, conforme Figura 1. Figura1. Habilitar SQL Server Replication Após instalada a feature de replicação no servidor de banco de dados, devemos configurar o Distributor. No cenário ideal, nós devemos separar o distributor em um servidor dedicado, porém também podemos configurá-lo no servidor que será replicado, lembrando que essa decisão deve ser estudada, levando em consideração os databases existentes no servidor e o tamanho da replicação que estará sendo implementada. Para configurar o distributor, clique com o botão direito em Replication e em seguida Configure Distribution, conforme Figura 2.

Figura 2. Configurando o Distributor Em Configure Distribution Wizard Distributor (Figura3), você irá configurar o servidor atual como Distributor ou poderá indicar um outro servidor para ser o Distributor. No nosso exemplo, o próprio servidor será o Distributor.

Figura 3. Selecionando o servidor para Distributor Na Figura 4, caso o seu servidor não esteja com o SQL Server Agent configurado para iniciar automaticamente, o wizard da replicação irá questionar se você não quer mudar a inicialização para automática. É altamente recomendável que o SQL Server Agent seja configurado para iniciar automaticamente, pois ele tem papel fundamental no funcionamento da replicação.

Figura 4. Alterar inicialização do SQL Server Agent para iniciar automaticamente Como dito anteriormente, para todo tipo de replicação, será necessário criar um pacote Snapshot, com a estrutura e dados para carga inicial. Para que todos os assinantes consigam acessar esse pacote, criaremos um compartilhamento com acesso somente aos usuários que iniciam o SQL Server Agent dos servidores replicados (Figura 5).

Figura 5. Configurando a Snapshot Folder DICA: Para um bom funcionamento de toda a estrutura de replicação, sugiro que utilize sempre um mesmo usuário e senha locais, criados em todos os servidores que fazem parte da replicação, e que esse usuário seja configurado para iniciar o SQL Server e o SQL Server Agent. Mas fica a seu critério, lembrando que se forem usuários diferentes em cada servidor replicado, você precisará configurar o acesso desses usuários no compartilhamento do snapshot. O passo seguinte conforme Figura 6, é configurar o nome do database e o local onde ficarão fisicamente os arquivos de dados e log. Nesse exemplo, iremos seguir o sugerido, mas lembre-se, é sempre recomendável separar os arquivos de dados e log em discos físicos diferentes.

Figura 6. Nome e local do database distributor A próxima tela do wizard será para habilitar os servidores e databases publicadores (Publishers). Conforme Figura 7, nesse exemplo somente teremos o servidor local.

Figura 7. Habilitando os publicadores Em seguida, será perguntado qual a ação que você quer tomar para finalizar o wizard. Temos 2 opções, configurar o Distributor nesse momento ou gerar um script para configurá-lo depois. Nesse exemplo, já iremos configurá-lo. Seguindo, será mostrado um resumo de todas as opções selecionadas durante esse wizard. Figura 8.

Figura 8. Ação para finalização e resumo das opções selecionadas Agora já podemos criar nossos pacotes de replicação, chamados de Publications. Iremos criar uma publicação, utilizando a Transaction Replication, para ilustrar o que podemos fazer com a replicação do SQL Server. Para criar uma publicação, clique com o botão direito em Local Publication e depois em New Publication, conforme Figura 9.

Figura 9. Criando nova publicação Na tela seguinte, clique me Next. Como mostrado na Figura 10, em Publication Database, vamos selecionar o database que iremos replicar as informações, no nosso exemplo DBMatriz. Em seguida, na tela Publication Type, iremos selecionar a opção Transactional Replication. Nessa replicação, como dito anteriormente, os dados somente são enviados aos assinantes, não haverá retorno de nenhuma alteração ou novos dados. Clique em Next.

Figura 10. Selecionando o database e o tipo de replicação Serão exibidos todos os objetos do dabatase escolhido. Agora iremos selecionar as tabelas que desejamos replicar. Note na Figura 11, onde estão listadas as tabelas de nosso exemplo, que há uma tabela com um um símbolo indicando que ela não pode ser selecionada/replicada. A tabela tbamb2 não tem primary key definida, por esse motivo não pode ser replicada. Um requisito básico para replicar tabelas, é que elas precisam ter a chave primária criada.

Figura 11. Selecionando as tabelas a serem replicadas Após selecionar todas as tabelas, iremos verificar as propriedades dos objetos selecionados, clicando em Article Properties e depois em Set Properties of All Table Articles, conforme indica a Figura 12

Figura 12. Verificando as propriedades das tabelas selecionadas A Figura 13, mostra a tela de propriedades que podemos alterar para replicar, tanto a estrutura da tabela, quando seus dados. Obviamente para cada tipo de necessidade, temos que alterar propriedades diferentes, porém sugiro uma atenção para as seguintes propriedades: Copy foreign keys constraints, Copy check constraints, Copy Clustered index, Copy nonclustered indexes, Copy collation, Copy permissions. Uma atenção especial em Action if name is in use, pois é nesse item que definiremos qual o comportamento da replicação, caso a tabela já exista no destino. Normalmente utilizo a opção, Truncate all data in the existing object. Essa opção irá realizar um truncate na tabela antes de enviar os dados a serem replicados.

Figura 13. Propriedades das tabelas selecionadas Após configuradas as propriedades, clique em OK e depois em Next. Então chegamos aos filtros que podemos criar para as tabelas que serão replicadas, Figura 14. Para cada tabela que selecionamos anteriormente, podemos criar filtros para os dados que serão replicados. Não criem filtros complexos ou selects muito extensos, pois isso pode impactar drasticamente na performance da replicação, e consequentemente no seu database principal. Justamente por esse motivo, você poderá notar que JOINs não são permitidos no select principal desses filtros. Outro fator importante ao criar um filtro, tenha em mente que se nas propriedades das tabelas, você habilitou enviar para os assinantes todas as regras de constraints, certifique-se que não haverá violação dos dados nesses filtros.

Figura 14. Adicionando filtros as tabelas de sua replicação Seguindo adiante, iremos configurar o Snapshot Agent. Como mencionado no início, toda replicação é sempre iniciada através de um snapshot do database. Nesse momento, iremos indicar se queremos criar o snapshot imediatamente ao término do wizard, e deixá-lo disponível para os novos assinantes, e as opções de agendamento da execução do agente que controla o snapshot. Conforme mostrado na Figura 15, recomendo deixar marcada a opção Create snapshot immediately and keep ths snapshot available to initialize subscriptions e deixar desmarcada a opção que configura o agente do snapshot. O Snapshot Agent somente deve ser executado na criação de um novo assinante, ou na necessidade de reinicializar algum assinante, portando sua executação poderá ser manual, somente quando necessária.

Figura 15. Configuração do Snapshopt Agent Na Figura 16, vamos configurar as contas de usuários que irão executar o Snapshot Agent e Log Reader Agent. O ideal, é que você tenha em todos os servidores que fazem parte da replicação, uma mesma conta local, com usuários e senhas iguais, para evitarmos problemas de acessos e permissões pelos agentes.

Figura 16. Configurando a segurança dos agentes do snapshot e log reader Por fim, será questionado se queremos criar a publicação nesse momento ou gerar um script que fará todo esse trabalho. No nosso caso, só iremos deixar marcada a opção Create the publication. Após será solicitado um nome para nossa publicação.

Figura 17. Finalizando o processo de criação de uma publicação e nomeando o publication Finalizamos o primeiro passo. Agora iremos criar os assinantes que receberão os dados da publicação que acabamos de criar. No Microsoft SQL Server Management, em Replication e depois em Local Publications, note que apareceu um ítem com o nome do database replicado, mais o nome que você preencheu ao criar a publicação. Clique com o botão direito em cima desse novo item, e depois em New Subscriptions,

Figura 18. Criando um novo Subscription (assinante) Conforme ilustrado na Figura 19, devemos selecionar um Publisher e depois qual será a ação do distributor. Temos duas opções, a Push subscriptions e Pull subscriptions. Na Push o distributor irá enviar as informações ao subscriber (assinante), já na Pull, o assinante é responsável por ir até o distributor e pegar as informações. No nosso exemplo, iremos utilizar a push subscription.

Figura 19. Selecionando o publisher e a opção do distributor Na próxima tela, iremos selecionar os subscribers que receberão a replicação. Note que aparecerão os servidores que você tem registrado no seu Management Studio. Caso queira incluir mais servidores, basta clicar no botão Add Subscriber e cadastrá-los. Após selecionar cada servidor subscriber, será necessário escolher o database no servidor assinante que receberá os dados ou até poderá criar novos databases nos mesmos

Figura 20. Selecionando os assinantes e os respectivos databases Após, iremos configurar as contas que serão utilizadas pelos agentes do subscriber. Clicando em ( ), irá abrir uma tela para configurar as contas que serão utilizadas pelos agentes. Recomendo que utilize a mesma conta local criada anteriormente, lembrando novamente que a utilização de uma mesma conta, irá reduzir a possibilidade de problemas referentes a permissões entre os servidores.

Figura 21. Configurando as contas utilizadas pelos agentes no subscriber Em seguida iremos definir como o agente do distributor irá enviar as informações ao assinante. Essa é uma informação que você deverá ter definido no projeto de sua replicação. A pergunta que se aplica a isso é: Por quanto tempo posso manter as informações das tabelas sem atualizar?. Respondida essa pergunta, poderemos configurar a latência dessa replicação. Mas não podemos deixar a replicação por um longo período de tempo sem replicar os dados, pois isso pode expirar os dados, e se isso acontecer, será necessário reiniciar o assinante e novamente gerar um snapshot do database principal. A tela seguinte, conforme Figura 22, nos dá a opção de inicializar imediatamente a Subscription no término do wizard.

Figura 22. Agendamento e inicialização do assinante Finalizando, a Figura 23 mostra as duas últimas telas no processo de criação do subscriber. A primeira mostra as opções de criação do subscriber. Deixaremos marcada a primeira opção, que irá criar o subscriber imediatamente e a segunda é para gerar o script desse wizard. Após será exibido um resumo do wizard.

Figura 23. Finalizando a criação do subscriber Pronto! Criamos nossa replicação com Publicadores e Assinantes. Agora iremos abrir o Replication Monitor e verificar se todas as ações de inicialização, criação do snapshot e envio das informações ao subscriber foram realizadas com sucesso. No Management Studio do servidor matriz, vá em Replication e clique com o botão direito. Após selecione a opção Launch Replication Monitor. Será apresentada uma tela como a Figura 24

Figura 24. Replication Monitor Essa é a tela que utilizamos para administrar a replicação no SQL Server. Nela podemos definir as propriedades de tempo de sincronização, iniciar e parar replicações para um ou todos os assinantes, ver detalhes da replicação, entre outras coisas. Como podemos visualizar na Figura 24, na guia All Subscriptions, estão listados todos os assinantes da publicação selecionada. Como a latência está em 00:00:00, podemos perceber que os dados foram enviados e o pelo tempo da latência, essa indica que o dados está praticamente on-line. Outra guia importante e que temos que monitorar constantemente, é a guia Agents (Figura 25). Nela podemos verificar os status dos agentes de Snapshot e Log Reader. Figura 25. Guia Agents do Replication Monitor Para testar na prática, crie uma nova Database Engine Query no seu Management

Studio, e no database DBMatriz, execute os inserts da Listagem 2: Listagem 2: Inserindo dados na tabela da matriz INSERT INTO tbacaotipo (nmacaotipo, idusuariogrupo) VALUES ('Preparando', 1) INSERT INTO tbacaotipo (nmacaotipo, idusuariogrupo) VALUES ('Replicando', 1) Após, execute um select na tabela tbacaotipo no database DBFilial (nosso exemplo), e veja que os dados encontram-se lá.