Re: [firebase-br] Ajuda com replicação de bases de dados

Sex Maio 12 13:12:29 -03 2006

Essas informações foram tiradas de um documento da web que não me lembro 
onde peguei mais da uma ideia basica de como funciona a replicação e alguns 
problemas.

Replicação

Replicação de dados é a criação e a manutenção de cópias de uma base de 
dados ou sistema de arquivos. Estas cópias são mantidas em servidores 
independentes para aumentar a confiabilidade e garantir acesso local. Um dos 
aspectos centrais a ser considerado em replicação de dados é a política de 
gerenciamento na atualização das réplicas dos dados no sistema distribuído. 
Quando da atualização de uma cópia do repositório de dados, em um dos 
servidores, as demais cópias devem refletir, imediatamente ou de forma 
diferida, esta alteração. A replicação de dados em sistemas distribuídos é 
utilizada para torná-los mais confiáveis e seguros, pois o sistema pode 
sobreviver à falhas de uma ou mais cópias do componente replicado. Além 
disso, é desejável que os detalhes da replicação sejam escondidos dos 
usuários finais, proporcionando transparência de localização: o usuário 
utiliza uma das réplicas sem perceber qual.

Utilizando a replicação, os dados compartilhados podem ser distribuídos 
automaticamente para a plataforma destino, diminuindo o tráfego na rede e 
melhorando os requisitos de disponibilidade, isto pode ser usado para 
aplicações que são obrigadas a compartilhar dados com outras aplicações.

A tecnologia de replicação pode suportar as aplicações de suporte a decisão 
pela melhora de disponibilização dos dados, performance no acesso aos dados, 
e usabilidade dos dados. Isto ajuda os funcionários de uma empresa a terem 
informações seguras e atualizadas para poderem tomar decisões efetivas e 
exatas. Também é possível consultar informações antigas, e estas podem 
conter o que mudou e quando mudou.

Os clientes que estão migrando suas aplicações antigas ou replicando os 
dados entre vários ambientes podem utilizar a replicação para reduzir o 
tempo de desenvolvimento e o custo de manutenção da aplicação, os dados 
podem ser formatados através do acesso compartilhado de várias fontes de 
dados.

Os sistemas estão direcionados para ter cada vez mais disponibilidade, 
mantendo a competitividade e a satisfação da demanda de clientes. Isto acaba 
gerando uma pressão sobre a janela batch que geralmente ajuda na 
reorganização do banco de dados. A replicação cria um backup do sistema onde 
o acesso pode ser redirecionado durante quedas planejadas e ajuda a eliminar 
o processo de extração do processo de batch pela replicação dos dados em 
background ao longo do dia.

Pode-se distinguir três formas de replicação de arquivos em sistemas 
distribuídos

·        replicação em lotes: a comunicação é estabelecida em intervalos de 
tempo e é baseada em transações enfileiradas que são agendadas para 
processamento posterior nos servidores que possuam réplicas dos dados. As 
políticas de agendamento variam podendo ocorrer em um determinado intervalo 
de tempo ou em função da quantidade de alterações acumulada ou, ainda, em 
instantes específicos de um ciclo de processamento. Uma vez que a 
comunicação é estabelecida, conjuntos de dados são copiados para o servidor 
com dados replicados. Os protocolos mais utilizados são FTP e RDIST. Esta 
forma é muito usada para sincronização de espelhos de sites Web na Internet;

·        replicação por demanda: os servidores replicados obtêm o conteúdo 
quando necessário devido à demanda das aplicações. Quando uma aplicação 
solicita um recurso que não esteja no conjunto de dados do servidor 
replicado ou que esteja desatualizado é atendido o pedido buscando o recurso 
no servidor original. Os protocolos mais utilizados são FTP, HTTP e ICP;

·        replicação sincronizada: os servidores replicados cooperam usando 
estratégias sincronizadas e protocolos especializados de réplica para manter 
os conjuntos de dados replicados coerentes (two phase lock and commit 
protocols).

As estratégias de sincronização variam desde fortemente coerentes (alguns 
poucos minutos) até fracamente coerentes (algumas horas). As atualizações 
ocorrem entre as réplicas baseadas nas restrições de tempo do modelo de 
coerência empregado e são feitas, geralmente, apenas através dos dados que 
foram modificados.

Ao se utilizar arquivos replicados, surge a questão de que se deve replicar 
todo o conteúdo ou simplesmente particionar os dados em servidores 
diferentes. Ao se escolher a replicação, deve-se estar ciente de que o 
conteúdo deve estar sincronizado em servidores diferentes.

Um problema a ser resolvido é como replicar o conteúdo de forma 
transparente, autônoma e com alto desempenho. Deve-se avaliar, 
cuidadosamente, que aspectos devem ser privilegiados, como a consistência, a 
disponibilidade dos dados ou o desempenho que se deseja alcançar. As 
questões anteriores devem ser tratadas ao se trabalhar com replicação no 
ambiente distribuído: algoritmos de distribuição das réplicas, colocação das 
réplicas, consistência e atualização de versões.

Sendo a cópia de informações de um ou mais Banco de dados para outro 
semelhante, depois das informações estarem consistentes existem dois tipos 
básicos de replicação - SÍNCRONA E ASSÍNCRONA

Replicação Síncrona:
Todas as cópias ou replicações de dados serão feitas no instante da 
sincronização e consistência. Se alguma cópia do banco é alterada, essa 
alteração será imediatamente aplicada a todos os outros bancos dentro da 
transação. A Replicação Síncrona é apropriada em aplicações comerciais onde 
a consistência exata das informações é de extrema importância.

Replicação Assíncrona:
Armazena e faz a replicação. A cópia de dados fica fora de sincronia entre 
os BDs. Se um BD é alterado, a alteração será propagada e aplicada para 
outro BD num segundo passo, dentro de uma transação separada sendo que esta 
poderá ocorrer segundos, minutos, horas ou até dias depois. A cópia poderá 
ficar temporariamente fora de sincronia, mas quando a sincronização ocorrer 
os dados convergirão para todos os locais especificados.

Este documento trata exclusivamente sobre replicação de dados assíncrono.

Quais componentes são necessários para a replicação de dados
Capturando as alterações no banco de dados de origem.
Toda estratégia de replicação de dados requer um método para capturar as 
alterações para um banco de dados de replicação. Há dois mecanismos 
principais - Logs de Transação e Triggers.

Logs de transação abordam a utilização de uma técnica chamada "log Sniffing" 
a qual replica uma transação sinalizada para replicação para um plataforma 
de transmissão. Esta técnica causa um impacto menor no servidor de Banco de 
Dados porque requer menos CPU quando da leitura de "Log" na memória e também 
na gravação para o disco. Este método de replicação é utilizado também por 
outros fabricantes de Bancos como Sybase, Informix e MS SQL/Server.

A Segunda técnica usa triggers no Banco de dados para propagar as alterações 
quando elas ocorrem. Como a Linguagem procedural de Banco de dados pode ser 
utilizada nesse método, ela provê maior flexibilidade a medida que os dados 
são replicados. Esta implementação de replicação é utilizada pelo Ingres, e 
Oracle, também é a técnica que nós utilizamos ao trabalharmos com replicação 
com Interbase e as triggers que utiliza o replicador é de insert, update e 
delete.

Transmitindo alterações de um de Banco de Dados para o(s) Banco de dados 
Destino
Para a transmição das alterações para o BD destino é requerido um Software 
que lê as alterações e as transmite ao BD Destino situado em algum lugar da 
rede e grava as alterações.

Este Software é conhecido como um gerenciador de replicação (Replicador) e 
também controla erros e conflito de Updates.

Conflitos de Update
Erro mais freqüente e que mais implica na segurança para replicação 
Assíncrona é crítica para quase todas as aplicações. Porém, o que 
aconteceria se o mesmo elemento de dados (por exemplo, a mesma coluna de um 
mesmo registro) for atualizada em dois locais diferentes ao mesmo tempo, ou 
mais precisamente no mesmo intervalo de replicação?

Isto é conhecido como conflito de Update. Sendo assim quanto menor for o 
tempo de atualização da réplica (ou seja, menor o intervalo(ciclo) de 
atualização) menor será a possibilidade de ocorrer conflitos de atualização.

Alternativamente, os conflitos de atualizações podem ser evitados limitando 
o "ownership" ou o direito para atualizar um elemento de dado para um 
determinado local. Na realidade, muitos acreditam que resolução de conflito 
é uma questão de processamento e não uma questão para os desenvolvedores de 
software. Eliminando a possibilidade de conflitos através de design e 
procedimentos, o software não precisaria resolver conflitos de updates pois 
os mesmos nunca ocorreriam, na teoria não é o que acontece hoje.

Essa visão no entanto é muito limitada quando os clientes estão exigindo que 
várias opções para resolução de conflitos sejam incorporadas nas ferramentas 
de replicação de dados.

Unique Keys e Generators
Tipicamente quando se trabalha com chaves únicas inteiras, uma trigger de 
BEFORE INSERT é utilizada adicionar e recuperar um novo valor de um 
generator. Quando se trabalha com replicação isso pode gerar alguns 
problemas.

O problema está em manter dois ou mais Banco de Dados sincronizados. Veja o 
exemplo abaixo:

Em um BD, o generator contém o valor 5. Quando um novo registro é 
adicionado, a trigger incrementa o valor do generator em 1 e o valor para a 
chave do novo registro passa à ser 6.

Este registro é replicado para um outro Banco de Dados.

Nesse segundo BD, o valor do generator é de 100. Quando o registro replicado 
for inserido no segundo BD, uma trigger sobrepõe o valor da chave (6) com o 
próximo valor do generator (101).

A solução tem duas possibilidades:

A primeira é confiar que o Cliente irá dar um valor a chave e não usar 
trigger.
A Segunda é dar intervalos de valores para cada BD o que acontece hoje com o 
replicador, sendo que cada local possuirá certos valores de chave. Como no 
Interbase um valor do tipo Interger pode chegar a 2 bilhões de números, os 
intervalos de números poderiam ser divididos em partes de milhões se for 
necessário. O Generator para cada local poderá ser inicializado com um 
intervalo diferente usando para isso o comando para alterar o valor inicial 
do Generator:

SET GENERATOR GEN_NAME TO 1000000;

Inicialização
Se você replicar uma origem de dados para um destino, então você precisará 
inicializar o destino pois ele estará fora de sincronia com a origem.. 
Tipicamente, você poderá fazer isto simplesmente implementando uma recarga 
dos dados da origem para o destino, ou seja do Banco de Dados para sua 
Replicação.

Alterações na DDL e DML
O Replicador é responsável pela manipulação do DML que é a linguagem de 
manipulação de dados enquanto precisa ter implementado algum dispositivo 
para manipular o DDL que seria a linguagem do banco onde é possível alterar 
a estrutura do banco e atualizar com as novas implementações que serão 
feitas e uma quisito importante para uma replicação segura é sempre manter 
as estruturas idênticas dos bancos replicados.

----- Original Message ----- 
From: "Francisco A Souza" <francisco em logosinfo.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, May 12, 2006 11:32 AM
Subject: Re: [firebase-br] Ajuda com replicação de bases de dados

eu gostaria de mais detalhes, se puder passar algum documento. ex. seria
bom. obrigado
----- Original Message ----- 
From: "Jean Vichinheski" <jean em equipesul.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, May 12, 2006 11:22 AM
Subject: Re: [firebase-br] Ajuda com replicação de bases de dados

Trabalho com replicação Assincorna
de banco de dados a quase 5 anos com diversos SGDBs, temos um software
desenvolvido
aqui mesmo ele trabalha ate com linha discada se tiverem alguma duvida como
funciona a replicação !!!
abs,

Jean
----- Original Message ----- 
From: "Eduardo Jedliczka (TeamFB)" <jedyfb em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, May 12, 2006 10:54 AM
Subject: Re: [firebase-br] Ajuda com replicação de bases de dados

Bom, deixa eu dar o meu pitaco...

Durante o estuda da minha pós em banco de dados, estudei muito sobre
replicação de dados, este foi minha primeira tentativa de tema para a
monografia!!!

Descobri, que a maioria dos bancos tidos como "grandes" possui ferramentas
internas de replicação e/ou auditoria. Coisas estas inexistentes no FB, mas
possíveis de implementação mediante algum "trabalho".

bom, de forma resumida, qualquer replicador tido como "EFICIENTE" trabalha
com triggers para alimentar as tabelas "sombra", ou seja, duplicando o banco
local em outras tabelas contendo apenas os registros inseridos, alterados e
excluidos.

depois disto, ha um programa que lê as tabelas sombra em um banco e executa
estas operações em outro banco.

Se você for fazer isto pela web, funcioná sem problemas. O único senão, é
que o firebird possui um protocolo muito pesado, ou seja, quase que
impraticável. Mas dá para contornar utilizando WebServices, WebSphere ou até
mesmo um "protocolo leve" via ASP ou PHP, isto sem citar acesso remoto via
4 camadas. (banco origem -> servidor web c/ php ou aplicacao servidora ->
aplicação cliente -> banco destino )

Só que nenhum dos replicadores que eu estudei foram projetados para
trabalhar com pouca largura de banda.

Se desejarem conversar sobre uma possível abordagem, posso escrever algo
mais detalhado (e publicar em algum lugar mediante ajuda do Mestre Cantu).

Mas gostaria de afirmar que não sou dono da verdade, e que nesta lista há
pessoas muito mais hábeis e versadas em replicação do que eu, que poderiam
contribuir grandemente neste assunto.

======================
Eduardo Jedliczka
Membro do TeamFB - FireBase
Apucarana - PR
======================

----- Original Message ----- 
From: "Rodrigo Schiavo" <rodrigo.schiavo em sti.ind.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, May 12, 2006 7:41 AM
Subject: Re: [firebase-br] Ajuda com replicação de bases de dados

Sim, como eu disse no corpo do e-mail, a velocidade da replicação
on-line não foi satisfatória, ficou bastante lenta. Acredito que meu
problema seja resolvido com a replicação off-line.
Vou entrar em contato hoje com o desenvolvedor do FBReplicator para ver
se alguma forma de replicação off-line sera implementada, ou se devo
fazer isso por conta própria.

Rodrigo A. de Freitas escreveu:
> Como ficou o desempenho da replicação sendo feita via internet ? Não é
> um tanto quanto lento ?
>
> []'s
>
>
> Rodrigo A. de Freitas
> Análise e Desenvolvimento
> -----------------------------------
> Soluções & Informática
> www.solucoeseinformatica.com.br
>
>
> Rodrigo Schiavo escreveu:
>  > Consegui resolver meu problema com ele aqui.
>  >
>  > Suporta sim, estou testando a seguinte estrutura aqui:
>  >
>  > SERVIDOR_REDE_INTERNA > MAQUINA_REPLICADORA > SERVIDOR_MAQUINA_REMOTA
>  >
>  > Estou usando 3 máquinas para esta operação, uma delas é dedicada ao
>  > replicador, porém como minhas bases sofrem muitas inserções e deletes
>  > por segundo, a velocidade de replicação online não ficou satisfatória,
>  > estou tentando configurar replicação por arquivos OffLine de alterações
>  > agora.
>  >
>  > Att.
>  > Rodrigo Schiavo
>  >
>  >
>
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
>
>
>

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa

-- 
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.5/147 - Release Date: 24/10/2005

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.6/337 - Release Date: 11/05/2006

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço 
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa

-- 
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.5/147 - Release Date: 24/10/2005