Em um ambiente de banco de dados ocupado com bancos de dados de tamanho maior, a necessidade de replicação de dados em tempo real é uma ocorrência comum. Os aplicativos geralmente precisam que os dados de produção sejam replicados em tempo real para locais remotos para análises e outras necessidades críticas de operações de negócios.
Os DBAs também precisam garantir que os dados sejam replicados continuamente para os locais remotos para atender a vários requisitos. Esses requisitos, porém, nem sempre podem ser replicar todo o banco de dados; também pode haver a necessidade de replicar apenas um subconjunto dos dados (como uma tabela ou conjunto de tabelas ou dados de várias tabelas usando um SQL para análises, relatórios etc.)
Neste blog, vamos nos concentrar em como replicar tabelas para bancos de dados remotos em tempo real.
O que é replicação em nível de tabela?
A replicação em nível de tabela é o mecanismo de replicação dos dados de uma tabela específica ou conjunto de tabelas de um banco de dados (origem) para outro banco de dados (destino) hospedado remotamente em um ambiente distribuído. A replicação no nível da tabela garante que os dados da tabela sejam distribuídos continuamente e permaneçam consistentes nos sites replicados (destino).
Por que usar a replicação em nível de tabela?
A replicação em nível de tabela é uma necessidade essencial em ambientes maiores, complexos e altamente distribuídos. Na minha experiência, sempre houve a necessidade de replicar um conjunto de tabelas de um banco de dados de produção para um data warehousing para fins de relatório. Os dados devem ser replicados continuamente para garantir que os relatórios recebam os dados mais recentes. Em ambientes críticos, a desatualização dos dados não pode ser tolerada, portanto, as alterações de dados que ocorrem na produção devem ser replicadas imediatamente para o site de destino. Isso pode ser um verdadeiro desafio para os DBAs terem que prever vários fatores para garantir uma replicação de tabela eficiente e suave.
Vejamos alguns requisitos que a replicação em nível de tabela resolve:
- Os relatórios podem ser executados em um banco de dados em um ambiente diferente de produção, como data warehousing
- Um ambiente de banco de dados distribuído com aplicativos distribuídos extraindo dados de vários sites. No caso de aplicativos móveis ou da Web distribuídos, a cópia dos mesmos dados deve estar disponível em vários locais para atender a várias necessidades de aplicativos para as quais a replicação em nível de tabela pode ser uma boa solução
- Aplicativos de folha de pagamento que precisam que os dados de vários bancos de dados localizados em diferentes data centers distribuídos geograficamente ou instâncias de nuvem estejam disponíveis em um banco de dados centralizado
Vários fatores que afetam a replicação em nível de tabela - O que procurar
Como mencionamos acima, os DBAs precisam levar em consideração uma variedade de componentes e fatores em tempo real para projetar e implementar um sistema de replicação em nível de tabela eficaz.
Estrutura da tabela
O tipo de tabela de dados que está acomodando tem um grande impacto no desempenho da replicação. Se a tabela estiver acomodando uma coluna BYTEA com dados binários de tamanho maior, o desempenho da replicação poderá ser afetado. O impacto da replicação na rede, CPU e disco deve ser avaliado cuidadosamente.
Tamanho dos dados
Se a tabela a ser migrada for muito grande, a migração de dados inicial consumirá recursos e tempo, os DBAs devem garantir que o banco de dados de produção não seja afetado.
Recursos de infraestrutura
A infraestrutura deve ter recursos adequados para garantir que um sistema de replicação de desempenho confiável e estável possa ser construído. Quais componentes de infraestrutura devem ser considerados?
CPUs
A replicação de dados depende muito de CPUs. Ao replicar da produção, as CPUs não devem se esgotar, o que pode afetar o desempenho da produção.
Rede
É crítico para o desempenho da replicação. A latência de rede entre os bancos de dados de Origem e Destino deve ser avaliada por testes de estresse para garantir que haja largura de banda suficiente para que a replicação seja mais rápida. Além disso, a mesma rede pode ser usada por outros processos ou aplicativos. Portanto, o planejamento de capacidade deve ser feito aqui.
Memória
Deve haver memória adequada disponível para garantir que dados suficientes sejam armazenados em cache para uma replicação mais rápida.
Atualizações da tabela de origem
Se as alterações de dados na tabela de origem forem pesadas, o sistema de replicação deverá ter a capacidade de sincronizar as alterações nos locais remotos o mais rápido possível. A replicação acabará enviando um grande número de solicitações de sincronização para o banco de dados de destino, o que pode consumir muitos recursos.
O tipo de infraestrutura (datacenters ou nuvem) também pode afetar o desempenho da replicação e apresentar desafios. A implementação do monitoramento também pode ser um desafio. Se houver um atraso e alguns dados estiverem faltando no banco de dados de destino, pode ser difícil monitorar e não pode ser síncrono
Como implementar a replicação de tabela
A replicação em nível de tabela no PostgreSQL pode ser implementada usando uma variedade de ferramentas externas (comerciais ou de código aberto) disponíveis no mercado ou usando fluxos de dados personalizados.
Vamos dar uma olhada em algumas dessas ferramentas, suas características e capacidades...
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
Desleixado
O Slony é uma das ferramentas mais populares usadas para replicar de forma assíncrona tabelas ou tabelas individuais específicas em tempo real de um banco de dados PostgreSQL para outro. Esta é uma ferramenta baseada em Perl que executa a replicação baseada em gatilho de alterações de dados de uma tabela (ou conjunto de tabelas) de um banco de dados em um site para outro. É bastante confiável e tem anos de história de desenvolvimento. Embora altamente confiável, por ser uma ferramenta baseada em gatilhos, pode se tornar complexo gerenciar as configurações de replicação.
Vejamos algumas capacidades do Slony...
Vantagens de usar o Slony
- Suporta a metodologia de replicação de mestre para escravo ou vários escravos que ajuda a melhorar a escalabilidade de leitura horizontal. Em outras palavras, escravos não são graváveis
- Configurar vários escravos para um único mestre é possível e também suporta a metodologia de replicação em cascata
- Suporta mecanismos de alternância e failover
- Um grande número de tabelas pode ser replicado em grupos, em paralelo
- Podemos replicar entre diferentes versões principais de instâncias do PostgreSQL, o que torna o Slony uma ótima opção para atualizações de banco de dados
- Simples de instalar
Desvantagens do uso do Slony
- Não suporta replicação DDL
- Algumas alterações de esquema podem interromper a replicação
- Os eventos de replicação são registrados no banco de dados em tabelas de log específicas do Slony, o que pode representar uma sobrecarga de manutenção.
- Se um grande número de tabelas com grandes conjuntos de dados precisar ser replicado, o desempenho e a manutenção poderão representar sérios desafios
- Sendo uma replicação baseada em gatilho, o desempenho pode ser afetado
Bucardo
Bucardo é outro sistema de replicação baseado em perl de código aberto para PostgreSQL que suporta a replicação assíncrona de dados de tabela específicos entre duas ou mais instâncias do PostgreSQL. O que diferencia o Bucardo do Slony é que ele também suporta replicação multimestre.
Vejamos os diferentes tipos de mecanismos de replicação que o bucardo ajuda a implementar...
- Replicação multimestre:as tabelas podem ser replicadas em ambas as direções entre duas ou mais instâncias do PostgreSQL e os dados transacionais serão sincronizados bidirecionalmente
- Mestre-escravo:os dados das tabelas no mestre serão replicados para o escravo de forma assíncrona e o escravo estará disponível para operações de leitura
- Modo de cópia completa (Mestre-escravo):Bucardo -/replica todos os dados do mestre para o nó escravo, excluindo todos os dados do escravo
Vantagens de usar o Bucardo
- Simples de instalar
- Suporta os modos de replicação multi-mestre, mestre-escravo e cópia completa
- Pode ser usado para atualizar bancos de dados
- A replicação pode ser feita entre diferentes versões do PostgreSQL
Desvantagens do uso do Bucardo
- Sendo uma replicação baseada em gatilho, o desempenho pode ser um desafio
- As alterações de esquema, como DDLs, podem interromper a replicação
- Replicar um grande número de tabelas pode causar sobrecarga de manutenção
- Os recursos de infraestrutura devem ser otimizados para uma replicação de bom desempenho, caso contrário, a consistência não pode ser alcançada.
Replicação lógica do PostgreSQL
A replicação lógica é um recurso integrado revolucionário do PostgreSQL que ajuda a replicar tabelas individuais por meio de registros WAL. Sendo uma replicação baseada em WAL (semelhante a Streaming Replication) o pg logic se destaca quando comparado a outras ferramentas de replicação de tabelas. A replicação de dados por meio de registros WAL é sempre a maneira mais confiável e eficiente de replicar dados na rede. Quase todas as ferramentas do mercado fornecem replicação baseada em gatilho, exceto a replicação lógica.
Vantagens de usar a replicação lógica do PostgreSQL
- A melhor opção quando você deseja replicar uma única tabela ou conjunto de tabelas
- É uma boa opção se o requisito for migrar tabelas específicas de vários bancos de dados para um único banco de dados (como data warehousing ou bancos de dados de relatórios) para fins analíticos ou de relatórios
- Sem problemas de gatilhos
Desvantagens de usar a replicação lógica do PostgreSQL
- O gerenciamento incorreto de arquivos WAL/arquivos WAL pode representar desafios para a replicação lógica
- Não podemos replicar tabelas sem chaves primárias ou exclusivas
- DDLs e TRUNCATE não são replicados
- O atraso de replicação pode aumentar se os WALs forem removidos. Isso significa que a replicação e o gerenciamento do WAL devem se complementar para garantir que a replicação não seja interrompida
- Objetos grandes não podem ser replicados
Aqui estão mais alguns recursos para ajudá-lo a entender melhor a Replicação Lógica do PostgreSQL e as diferenças entre ela e a replicação de streaming.
Wrappers de dados estrangeiros
Embora os Foreign Data Wrappers na verdade não replicam os dados, eu queria destacar esse recurso do PostgreSQL porque ele pode ajudar os DBAs a obter algo semelhante à replicação sem realmente replicar os dados. Isso significa que os dados não são replicados da origem para o destino e os dados podem ser acessados por aplicativos do banco de dados de destino. O banco de dados de destino tem apenas uma estrutura de tabela com um link contendo detalhes do host e do banco de dados da tabela de origem e, quando o aplicativo consulta a tabela de destino, os dados são puxados do banco de dados de origem para o banco de dados de destino semelhante aos Links de banco de dados. Se os FDWs puderem ajudar, você poderá evitar totalmente a sobrecarga de replicar os dados pela rede. Muitas vezes chegamos a uma situação em que os relatórios podem ser executados em um banco de dados de destino remoto sem precisar que os dados estejam presentes fisicamente.
FDWs são uma ótima opção nas seguintes situações -
- Se você tiver tabelas pequenas e estáticas no banco de dados de origem, não vale a pena replicar os dados
- Pode ser realmente benéfico, se você tiver tabelas muito grandes no banco de dados de origem e estiver executando consultas agregadas no banco de dados de destino.
Vantagens de usar wrappers de dados estrangeiros
- A replicação de dados pode ser completamente evitada, o que economiza tempo e recursos
- Simples de implementar
- Os dados extraídos são sempre os mais recentes
- Sem manutenção excessiva
Desvantagens do uso de wrappers de dados estrangeiros
- As alterações estruturais na tabela de origem podem afetar a funcionalidade do aplicativo no banco de dados de destino
- Depende muito da rede e pode ter uma sobrecarga de rede significativa dependendo do tipo de relatório que está sendo executado
- A sobrecarga de desempenho é esperada quando as consultas são executadas várias vezes, pois cada vez que a consulta é executada, os dados devem ser puxados pela rede do banco de dados de origem e também podem representar sobrecarga de desempenho no banco de dados de origem
- Qualquer carga na origem pode afetar o desempenho dos aplicativos no banco de dados de destino
Conclusão
- A replicação de tabelas pode servir a vários propósitos críticos para os negócios
- Pode oferecer suporte a consultas paralelas distribuídas em ambientes distribuídos
- Implementar o síncrono é quase impossível
- A infraestrutura deve ser adequadamente capacitada, o que envolve custos
- Uma ótima opção para criar um banco de dados centralizado integrado para fins analíticos e de relatórios
