Configurando uma solução de replicação para alta disponibilidade no Oracle - Revista SQL Magazine 104

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Este artigo apresenta como devemos proceder para configurar o Oracle GoldenGate de forma que ele seja utilizado como a solução de replicação de um banco de dados.

De que se trata o artigo

O Oracle GoldenGate proporciona a aquisição, distribuição e entrega de dados em tempo real e com baixo impacto através de sistemas heterogêneos. Assim, ele oferece integração com tecnologias e aplicações Oracle, suporte para sistemas heterogêneos adicionais, e alto desempenho. O Oracle GoldenGate transporta transações confirmadas com integridade transacional e mínimo impacto sobre sua infraestrutura existente.


Em que situação o tema é útil

Para iniciar o aprendizado sobre como administrar, configurar e manter o sistema de replicação GoldenGate, ou mesmo decidir se ele deve ser utilizado em uma implementação baseando-se em suas funcionalidades, recursos, limitações e ferramentas de administração. A escolha do sistema de replicação é parte importantíssima na estratégia de implementação de alta disponibilidade de uma aplicação de missão critica.

Resumo DevMan

Este artigo apresenta como devemos proceder para configurar o Oracle GoldenGate de forma que ele seja utilizado como a solução de replicação de um banco de dados. Será demonstrado como o administrador de banco de dados pode instalar, iniciar e configurar o GoldenGate. Serão então demonstradas as principais tarefas necessárias para a verificação do correto funcionamento do GoldenGate.

A replicação de dados é muito utilizada nos bancos de dados relacionais, principalmente para garantir alta disponibilidade em sistemas críticos e, em segundo lugar, para prover escalabilidade horizontal (onde a carga é distribuída entre outros servidores). A replicação trata do envio dos dados alterados de um servidor para outro e os principais SGBDs (Sistemas Gerenciadores de Bancos de Dados) do mercado possuem esta funcionalidade.

Em julho de 2009, a Oracle Corporation, célebre devoradora de pequenas, médias e grandes empresas, adquiriu a GoldenGate, uma companhia com uma solução de replicação heterogênea. Desde então, a Oracle passou a encorajar seus clientes a utilizar o GoldenGate ao invés do Streams, sua antiga plataforma de replicação heterogênea.

A capacidade de executar replicação heterogênea significa que dados podem ser replicados entre versões do Oracle Database diferentes (por exemplo, entre Oracle 10gR2 e 11gR2), entre sistemas operacionais diferentes (por exemplo, entre AIX e Windows), entre arquiteturas diferentes (por exemplo, entre Intel Itanium e SPARC), e no caso do GoldenGate, até entre SGBDs diferentes, como entre o Oracle e o DB2. Na verdade, o Oracle Database nem precisa estar envolvido na solução, o GoldenGate pode ser utilizado para replicação entre dois servidores Microsoft SQL Server, por exemplo.

Um grande uso da replicação heterogênea, além dos já mencionados, é possibilitar a migração entre versões, sistemas operacionais, arquiteturas ou SGBDs diferentes com um tempo mínimo de parada, pois não é preciso ter o sistema indisponível durante uma lenta operação de Backup e Restore: apenas "vira-se a chave" para que a aplicação passe a utilizar o novo servidor, que foi constantemente atualizado. Desta forma, um cliente que comprou um AIX em uma máquina nova e muito poderosa, pode migrar seu banco de dados que atualmente está em um antigo servidor Intel de 32 bits com um tempo de indisponibilidade muito pequeno, mesmo tradando-se de um banco de dados na casa de Terabytes.

Topologias de replicação

Além de oferecer a flexibilidade entre a origem e o destino dos dados, o GoldenGate permite que a topologia da replicação seja feita de muitas formas diferentes:

  • Unidirecional: esta é a forma mais tradicional e utilizada de replicação, onde um servidor envia dados para outro servidor, e este apenas os recebe. Além de prover alta disponibilidade, este tipo de replicação pode ser utilizada para criar um servidor exclusivo para extração de relatórios pesados, que se fossem executados no servidor principal afetariam um sistema onde o desempenho é crítico;
  • Bidirecional: nesta modalidade, cada servidor envia os dados que alterou para o outro, como se fosse um cluster. Mas ao contrário de um cluster, os possíveis conflitos de dados (por exemplo, criar uma Nota Fiscal número 42 em um servidor, ao mesmo tempo em que, por coincidência, criar no outro) devem ser tratados no nível da aplicação. Este tipo de replicação é mais utilizado para alta disponibilidade;
  • Ponto a ponto (em inglês, peer-to-peer): neste tipo de replicação, todos os servidores enviam dados para todos os outros servidores em uma extensão do modelo bidirecional. Da mesma forma, provê um cluster lógico, com a mesma necessidade de tratamento de conflitos. Este modelo atende melhor questões de alta disponibilidade e escalabilidade horizontal;
  • Difusão (em inglês, broadcast): neste modelo, um único servidor de produção é utilizado pela aplicação e seus dados são replicados para uma grande quantidade de servidores, para por exemplo, serem utilizados para extração de relatórios. Uma ideia para utilização deste modelo é uma matriz de uma empresa replicando seus dados para todas suas filiais, apenas para consulta;
  • Consolidação (em inglês, consolidation): este modelo é o oposto da Difusão, mais utilizado para atender a necessidade da criação de um grande repositório de dados (data warehouse), por exemplo, de todos os principais bancos de uma empresa, para que informações relevantes ao negócio possam ser extraídas dessa massa de dados;
  • Em cascata (em inglês, cascading): neste modelo de replicação, uma combinação entre o Unidirecional e a Difusão, o servidor principal primeiro envia os dados para um servidor replicado, e este então envia para uma grande quantidade de servidores. Este método pode ser útil para se evitar um possível impacto na produção de replicar dados para uma grande quantidade de servidores.

Observe na Figura 1 a visualização gráfica destes tipos de replicação, sendo todos estes cenários possíveis com o GoldenGate. Além de todos estes tipos de replicação, o GoldenGate permite, através de configurações, que os dados sejam filtrados antes de serem transmitidos (replicando só o que importa, economizando recursos de rede), e até mesmo transformados ao serem aplicados no servidor destino (por exemplo, replicando uma tabela com outro nome, ou alterando o conteúdo da coluna de salário de uma tabela de funcionários).

Figura 1. Modelos de replicação de dados.

Neste artigo iremos iniciar a utilização do GoldenGate por sua forma mais simples; uma replicação unidirecional entre SGBDs, versões de sistemas operacionais e plataformas iguais. Este é um guia rápido para uma implementação de replicação simples de um único SCHEMA entre dois servidores Linux x86-64 utilizando Oracle Database 11gR2.

Conhecendo o GodenGate

Antes de partirmos para a prática, precisamos conhecer os processos que compõe o GoldenGate. Ele é composto pelos seguintes componentes:

  • Extract: é o processo que faz a extração dos dados a partir dos Redo Logs (ver Nota DevMan 1) do Oracle Database. Os dados extraídos são armazenados nos arquivos Trail, descritos logo abaixo. Se o Extract for configurado de forma a se comunicar diretamente com o servidor destino, ele enviará os arquivos Trail diretamente para este;
  • Data Pump: é um subtipo do processo Extract que faz a ponte entre o Extract original do servidor origem, e o Replicat, que recebe os dados no servidor destino. Ele não é mandatório, mas sem o Data Pump, o Extract teria que se comunicar diretamente com o Replicat, o que pode ser um problema em situações como queda temporária do link de rede, ou um pico de alteração de dados no servidor origem. Ele também é utilizado para fazer filtros e alterações nos dados replicados. Quando o Data Pump é utilizado, é ele que envia os arquivos Trail para o processo Replicat no servidor destino. Este processo não deve ser confundido com as ferramentas de transporte de dados do Oracle Database também chamadas de Data Pump, que compreendem os programas expdp (para exportação) e impdp (para importação);
  • Replicat: é o processo que, sendo executado no servidor destino, lê os arquivos Trail enviados pelo servidor origem (pelo processo Extract ou Data Pump) e aplica as alterações que eles contêm no banco de dados;
  • Arquivos Trail: são os arquivos que contêm os dados extraídos pelo processo Extract e são enviados para o servidor destino, sendo recebidos e utilizados pelo processo Replicat. Eles existirão tanto no servidor origem quanto no destino;
  • Checkpoints: além dos mecanismos internos de Checkpoint dos bancos de dados origem e destino, utilizados para manter a integridade de suas transações, o GoldenGate possui seu próprio registro de "

    A exibição deste artigo foi interrompida :(
    Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?