none
Case de Sucesso - Replicação de Ambiente Crítico RRS feed

  • Pergunta

  • Pessoal,

    Estamos analisando a possibilidade de trabalhar com Replicação.
    Hoje temos um servidor principal em SP com contingência em mirror local e, os todos os usuários acessam este servidor principal centralizado em SP.

    Em caso de problemas de comunicação (Link), este ambiente fica fora para o usuário local das capitais.

    Estamos estudando a possibilidade de trabalhar com replicação de dados em algumas capitais, evitando a indisponibilidade, onde o usuário estaria utilizando seu servidor local em caso de problemas, e quando normalizado o link, efetue a conexão no servidor principal em SP com os dados atualizados.

    Minha dúvida ocorre no sentido de ser um Ambiente Crítico da Empresa e os todos os dados DEVEM ser atualizados exatamente no momento da volta do link, voltando a conexão do usuário ao servidor principal e não ao servidor local (replicado).

    Só trabalhei com replicação tipo snapshot e ou pontos de vendas que ao final do dia, centralizavam dados no servidor principal (tipo D-1).

    Gostaria de saber se vcs acham este tipo de replicação segura neste sentido ?
    Vocês conhecem algum CASE de Sucesso com este tipo de estrutura, ou seja, utilizando replicação em algumas capitais para prever problemas de link de acesso ?
    Sugerem alguma outra alternativa de solução na resolução da possível indisponibilidade de algumas capitais ?

    Obrigada !


    EID
    quarta-feira, 22 de julho de 2009 13:10

Respostas

  • Concordo em partes,

    Imagine todas as filiais depender do link para acessar um server central ( espelhado por exemplo ) ? Com a replicação não existe esse problema, pois caso um server caia os demais podem continuar operando até que o server que caiu volte e sincronize, sem contar que o espelhamento até o 2005 tinha vários problemas...


    Abraços

    Demétrio Silva
    quarta-feira, 12 de agosto de 2009 16:01
  • Olá EID,

    Você pode optar pela replicação do tipo merge ou P2P, visto que os dois lados irão atualizar dados. No entanto, não há como "No momento que o LINK voltar", todos os databases estarem sincronizados.

    Imagine o seguinte:

    O servidor central, chamado publisher, cai e as filiais,  chamadas subscribers, continuam operando.... Imagine que o servidor volte apenas após umas 5 horas. Imagine ainda que durante essas cinco horas cada subscriber gere uns 3 milhões de registros.

    Pronto, passadas as cinco horas, o publisher volta ao ar. O que vai acontecer agora é que os subcribers irão sincronizar os dados com o publisher e isso pode não ser uma coisa tão rápida( vai depender do teu link e outros fatores ).

    No entanto, nessa topologia de replicação, se qualquer um servidor cair, os outros podem continuar trabalhando ( mas não com todos os dados sincronizados ).

    Abraços


    Demétrio Silva
    quarta-feira, 22 de julho de 2009 14:06

Todas as Respostas

  • EID_DBA,

    Todas as suas idéias ou possibilidades vão depender do link.

    Primeiramente você deverá analisar e tentar definir a melhor forma de trabalhar este link.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quarta-feira, 22 de julho de 2009 13:38
    Moderador
  • Olá EID,

    Você pode optar pela replicação do tipo merge ou P2P, visto que os dois lados irão atualizar dados. No entanto, não há como "No momento que o LINK voltar", todos os databases estarem sincronizados.

    Imagine o seguinte:

    O servidor central, chamado publisher, cai e as filiais,  chamadas subscribers, continuam operando.... Imagine que o servidor volte apenas após umas 5 horas. Imagine ainda que durante essas cinco horas cada subscriber gere uns 3 milhões de registros.

    Pronto, passadas as cinco horas, o publisher volta ao ar. O que vai acontecer agora é que os subcribers irão sincronizar os dados com o publisher e isso pode não ser uma coisa tão rápida( vai depender do teu link e outros fatores ).

    No entanto, nessa topologia de replicação, se qualquer um servidor cair, os outros podem continuar trabalhando ( mas não com todos os dados sincronizados ).

    Abraços


    Demétrio Silva
    quarta-feira, 22 de julho de 2009 14:06
  • Demetrio,

    Com base neste cenário, talvez a replicação P2P seja mais vantagosa devido a disponibilidade da informação em outros pontos de acesso.

    O que você acha?


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quarta-feira, 22 de julho de 2009 17:24
    Moderador
  • Olá Júnior,

    Aqui na empresa usamos replicação há um bom tempo ( por problemas de sofwtares desktop, link, etc ) e sempre que posso eu evito o uso da replicação merge devidos aos seus diversos problemas arquiteturais( conflitos, etc ). Na maioria dos casos pode-se usar a P2P no lugar da merge.

    Abraços

    Demétrio Silva
    quarta-feira, 22 de julho de 2009 17:30
  • Demétrios,

    Aqui também utilizamos há alguns anos, principalmente a replicação transacional.

    Cara eu gosto muito desta replicação.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sexta-feira, 24 de julho de 2009 10:33
    Moderador
  • Cara


    Eu nao sei se eu eh que sou chato mas no meu entender replicacao serve apenas para disponibilizar o dado mais perto do ususario, seja em servidores, locais geograficos e dispositivos moveis. Aqui na empresa trabalhamos com missao critica  incluisive testamos de todas as contingencias. O que usamos que tem dado um resultado interessante pelo custo que representa e facilidade de resincronizar eh o logshipping. Mirror eh uma solucao interessante principalmente as solucoes de mirror com Witness, mas no caso do logshipping da pra configurar o intervalo de copia dos logs e melhorar bastante a flexibilidade. Pra se ter ideia, temos um ambiente com logship com 1.5 Tb de bases de dados e funcionando redondo jah ha um bom tempo.

    No sql 2008 tem algumas facilidades, a compressao do stream do log tanto pra logship quanto pra mirror eh uma feture interessante porque em caso de link muito estreito pode melhorar o teu desempenho. Hoje usamos pra a compressao dos backups um produto de terceiro que eh da Quest, mas o custo eh muito alto. Ate por esse motivo a migracao pra SQL 2008 tem se justificado.

    O cluster se tornou barato, isso se vc tiver trabalhando com contingencias no mesmo site, e o que vem a se tornar uma solucao interessante eh o Cluster Geografico (Procura depois por Majority Node Set Quorum.


    Divirta-se :)
    WTN
    quarta-feira, 12 de agosto de 2009 15:05
  • Concordo em partes,

    Imagine todas as filiais depender do link para acessar um server central ( espelhado por exemplo ) ? Com a replicação não existe esse problema, pois caso um server caia os demais podem continuar operando até que o server que caiu volte e sincronize, sem contar que o espelhamento até o 2005 tinha vários problemas...


    Abraços

    Demétrio Silva
    quarta-feira, 12 de agosto de 2009 16:01
  • WTN,

    Respeito a sua opinião, mas tenho um ponto de vista diferente.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quinta-feira, 13 de agosto de 2009 19:18
    Moderador
  • Demétrio

    Só clarificando , a situação q vc descreve como filiais acessando uma matriz, se enquadraria na situação que a replicação é realmente aplicável, criar cópias do dado deixando mais perto do usuário. Realmente link é um problema (principalmente aqui no Brasil).

    Um outro comentário é que eu mesmo, como consultor já precisei colocar no ar uma replicação pra fazer site tollerance, mas mesmo nao concordando entendo que cada empresa é uma empresa e existem restrições, incluisive de ordem financeira. Para montar um logship ou cluster ou mirror existem custos envolvidos.

    Uma conta que se tem que fazer é a seguinte, quanta grana a minha empresa perde quando o sistema dela para? e quanto dinheiro merece ser investido para mitigar esse risco?


    WTN
    quinta-feira, 13 de agosto de 2009 20:06
  • Olá Neto,

    Com certeza existem outras alternativas para disponibilidade( Mirroring é uma delas ).

    No entanto, vai da necessidade de cada um. Será que realmente é melhor ter apenas um server responsável por tudo ? Ou seria merlhor distribuir os dados? Isso vai depender do link, definição da diretoria, estrutura física, etc.

    Abraços

    Demétrio Silva
    sexta-feira, 14 de agosto de 2009 14:00
  • Demétrio,

    Quem tem um não tem nenhum!!!

    E sou da seguinte opinião se a informação é importante e a empresa não pode parar é melhor pensar em estratégias de contigência de dados, seja ela, Replicação, Mirroring, Log shipping, Cluster, Acesso Remoto, VPN.

    A definição deve estar sempre focada no melhor custo benefício.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sexta-feira, 14 de agosto de 2009 23:40
    Moderador