--- title: "Técnicas de replicação de dados para alta disponibilidade: uma comparação completa" canonical: "https://safekit.eviden.com/pt-pt/best-practises/data-replication-techniques/" description: "Compare técnicas de replicação de dados ao nível da base de dados, do disco e do ficheiro. Saiba por que razão o SafeKit propõe uma arquitectura sem SAN para uma replicação síncrona simples e em tempo real, que evita a perda de dados e permite failover automático em Windows e Linux." category: "best-practises" lang: "pt-pt" topics: "Técnicas de replicação de dados ao nível da base de dados, do disco ou do ficheiro?, Tabelas comparativas das técnicas de replicação de dados" --- # Técnicas de replicação de dados para alta disponibilidade: uma comparação completa {#data-replication-techniques-for-high-availability-a-complete-comparison} ## Técnicas de replicação de dados ao nível da base de dados, do disco ou do ficheiro? {#data-replication-techniques-at-database-level-disk-level-or-file-level} ### Visão geral {#overview} Este artigo analisa as vantagens e desvantagens das técnicas de replicação de dados ao nível da base de dados, do disco e do ficheiro para clusters de alta disponibilidade. São considerados o failover, o failback e a simplicidade de implementação. ![Técnicas de replicação de dados](https://safekit.eviden.com/wp-content/uploads/2023/03/data-replication-techniques.png "w:128") As tabelas comparativas seguintes explicam detalhadamente as técnicas de replicação de dados implementadas pelo SafeKit, um produto de software de alta disponibilidade. ### O que é a técnica de replicação de dados ao nível da base de dados? {#what-is-the-data-replication-technique-at-database-level} É a replicação de ficheiros de registo entre dois servidores, efectuada pelo sistema de gestão de bases de dados, como o [registo de transacções do SQL Server](). Para que o failover seja automático, é obrigatória a replicação síncrona; caso contrário, as últimas transacções confirmadas não estarão disponíveis no servidor secundário após o failover. Esta técnica replica uma base de dados, mas não os restantes dados da aplicação. O failover de muitas aplicações também requer a replicação de outros dados, como ficheiros de configuração. Se um servidor falhar e perder ficheiros da base de dados, o failback não é automático. Um DBA experiente tem de restaurar a base de dados no servidor avariado. ### O que é a técnica de replicação de dados ao nível do disco? {#what-is-the-data-replication-technique-at-disk-level} É a replicação das alterações nos discos entre dois servidores, como no [DRBD](). Para obter failover automático sem perda de dados, é necessária a replicação síncrona entre os discos. Esta técnica pode replicar bases de dados e outros ficheiros, mas afecta significativamente a organização dos dados da aplicação. Todos os dados têm de estar no disco replicado. Isso pode ser impossível se alguns dados estiverem no disco do sistema, que tem de ser específico de cada servidor. São necessários conhecimentos especializados para configurar um disco replicado com um sistema de ficheiros e colocar nele os dados da aplicação. ### O que é a técnica de replicação de dados ao nível do ficheiro? {#what-is-the-data-replication-technique-at-file-level} É a replicação das alterações nos ficheiros entre dois servidores, como no [SafeKit](https://safekit.eviden.com/pt-pt/). Para obter failover automático sem perda de dados, é necessária a [replicação síncrona em tempo real](https://safekit.eviden.com/pt-pt/best-practises/synchronous-replication-vs-asynchronous-replication/). Esta técnica pode replicar bases de dados e outros ficheiros sem afectar a organização dos dados da aplicação. Por exemplo, a replicação de ficheiros em tempo real funciona mesmo que uma aplicação armazene os seus dados no disco do sistema. A solução é muito simples de configurar: basta indicar os caminhos dos directórios a replicar. ## Tabelas comparativas das técnicas de replicação de dados {#comparative-tables-between-data-replication-techniques} Escolher a abordagem correta de replicação de dados é fundamental para garantir a continuidade do negócio. Esta comparação destaca os principais diferenciadores do cluster espelho SafeKit com replicação de ficheiros em tempo real face às alternativas tradicionais, como a replicação ao nível da base de dados, a replicação de disco, as soluções de disco partilhado e os sistemas tolerantes a falhas. **Cluster espelho SafeKit: vantagens sobre abordagens alternativas de replicação e clustering** Característica | Vantagem SafeKit | Limitação das alternativas ---|---|--- [3 produtos em 1](https://safekit.eviden.com/best-practises/clustering-software-vs-hardware-clustering/) | Poupa no Windows e Linux o custo de armazenamento externo partilhado/replicado, equipamentos de balanceamento de carga e edições enterprise de sistemas operativos e bases de dados. Inclui todas as funcionalidades de clustering: replicação síncrona de ficheiros em tempo real, monitorização de falhas, reinício automático, failover de IP virtual. | As abordagens tradicionais exigem produtos separados para replicação de armazenamento, balanceamento de carga e clustering — aumentando custos e complexidade. [Configuração muito simples](https://safekit.eviden.com/pt-pt/solutions/) | Configuração através de módulos de aplicação. Novos serviços e diretórios replicados podem ser adicionados facilmente. Tudo gerido por uma consola web centralizada. Nenhum controlador de domínio ou Active Directory necessário. | Microsoft cluster e soluções semelhantes exigem configuração complexa de Active Directory e controladores de domínio. [Replicação síncrona](https://safekit.eviden.com/best-practises/synchronous-replication-vs-asynchronous-replication/) | A replicação em tempo real é síncrona sem perda de dados em caso de falha (RPO = 0). | A replicação assíncrona pode perder transações recentes que ainda não foram replicadas no momento da falha. [Failback totalmente automatizado](https://safekit.eviden.com/architectures/file-replication-byte-level-with-failover-mirror-cluster/#step3) | Após uma falha, quando um servidor reinicia, o failback de replicação é totalmente automático. O servidor que falhou é reintegrado no cluster sem parar a aplicação no servidor restante. | A maioria das soluções de replicação (especialmente ao nível da base de dados) exige ressincronização manual. A aplicação pode mesmo ser parada durante o failback. [Replicação de qualquer tipo de dados](https://safekit.eviden.com/architectures/file-replication-byte-level-with-failover-mirror-cluster/#step1) | A replicação funciona para bases de dados e para quaisquer ficheiros que precisem de ser replicados. | A replicação ao nível da base de dados protege apenas a base de dados, não ficheiros de configuração, registos ou outros dados da aplicação. [Replicação de ficheiros vs. replicação de disco](https://safekit.eviden.com/best-practises/byte-level-file-replication-vs-block-level-disk-replication/) | A replicação baseia-se em diretórios de ficheiros que podem estar localizados em qualquer sítio, inclusive no disco do sistema. | A replicação de disco exige uma partição dedicada e configuração especial da aplicação para armazenar os dados. [Replicação de ficheiros vs. disco partilhado](https://safekit.eviden.com/best-practises/shared-nothing-architecture-vs-shared-disk-architecture/) | Os servidores podem ser implementados em dois locais remotos sem infraestrutura partilhada. | As soluções de disco partilhado exigem proximidade física e não conseguem abranger locais remotos. [Locais remotos e IP virtual](https://safekit.eviden.com/best-practises/how-a-virtual-ip-address-works/) | Todas as funcionalidades de clustering funcionam para 2 servidores em locais remotos. A LAN estendida permite o reencaminhamento VIP de nível 2. Para redes IP diferentes, o VIP é gerido por um balanceador de carga com health check do SafeKit. | Muitas soluções de clustering não suportam failover entre locais remotos ou exigem redirecionamento DNS complexo com tempos de recuperação imprevisíveis. [Quórum e split brain](https://safekit.eviden.com/best-practises/heartbeat-failover-quorum-windows-linux-cluster/) | Funciona com apenas 2 servidores. Um verificador simples de split brain para um router gere o isolamento de rede entre os locais. | A maioria das soluções de clustering exige um 3.º servidor para gestão do quórum. [Cluster ativo/ativo](https://safekit.eviden.com/architectures/active-active-cluster-real-time-replication/) | O servidor secundário não é dedicado. O cluster pode operar em modo ativo/ativo com 2 módulos espelho diferentes. | Os [sistemas tolerantes a falhas](https://safekit.eviden.com/best-practises/high-availability-cluster-vs-fault-tolerant-system/) dedicam o secundário à execução da mesma aplicação sincronizada ao nível das instruções. [Solução HA uniforme](https://safekit.eviden.com/architectures/clustering-software-load-balancing-mirroring/) | O SafeKit implementa tanto o cluster espelho (replicação + failover) como o [cluster farm (balanceamento de carga + failover)](https://safekit.eviden.com/architectures/network-load-balancing-cluster/). Uma arquitetura N-camadas pode ser tornada altamente disponível com uma única solução no Windows e Linux. | Arquiteturas típicas misturam tecnologias diferentes para balanceamento de carga, replicação e failover — aumentando a complexidade operacional. [RTO / RPO](https://safekit.eviden.com/best-practises/what-is-rpo-and-rto-with-examples/) | Reinício rápido da aplicação em caso de falha: cerca de 1 minuto ou menos. Zero perda de dados (replicação síncrona). | A [replicação completa de VM](https://safekit.eviden.com/pt-pt/best-practises/vm-ha-vs-application-ha/) (VMware HA, Hyper-V cluster) exige o reinício de todo o sistema operativo num novo hipervisor, resultando em tempos de recuperação mais longos. **Em resumo** , o cluster espelho SafeKit oferece uma solução de alta disponibilidade unificada e económica que combina replicação síncrona de ficheiros, failover e failback automáticos, balanceamento de carga e suporte a locais remotos — tudo sem exigir hardware dedicado, armazenamento partilhado ou um terceiro servidor de quórum. Esta simplicidade torna-o particularmente adequado para editores de software e organizações que necessitam de HA fiável em servidores Windows e Linux padrão.