Esta página descreve a elevada disponibilidade e as ferramentas que recomendamos que use.
Acerca da resiliência dos dados
Pode pensar na resiliência dos dados em termos de disponibilidade, tempo de restauro do serviço e perda de dados. Normalmente, a disponibilidade é medida em termos de tempo de atividade e expressa como a percentagem de tempo em que a base de dados está disponível. Por exemplo, para alcançar uma disponibilidade de 99,99%, a sua base de dados não pode estar inativa durante mais de 52,6 minutos por ano ou 4,38 minutos por mês. O tempo necessário para restaurar o serviço após uma interrupção é denominado objetivo de tempo de recuperação ou RTO. A quantidade de perda de dados aceitável devido a uma indisponibilidade é denominada objetivo de ponto de recuperação ou RPO e é expressa como o período durante o qual as transações são perdidas. Por exemplo, um RPO de 10 minutos significa que, em caso de falha, pode perder dados relativos a um período de até 10 minutos.
É comum definir um objetivo de disponibilidade ou um objetivo ao nível do serviço (SLO), juntamente com objetivos para o RTO e o RPO. Por exemplo, para uma determinada carga de trabalho, pode definir o SLO como 99,99% e também exigir um RPO de 0, sem perda de dados em caso de falha, e um RTO de 30 segundos. Para outra carga de trabalho, pode definir o SLO como 99,9%, o RPO como 5 minutos e o RTO como 10 minutos.
Pode implementar a resiliência básica da base de dados com cópias de segurança da base de dados. O AlloyDB Omni suporta cópias de segurança através do pgBackRest e também arquiva os ficheiros de registo de transações (WAL) da base de dados para minimizar a perda de dados. Com esta abordagem, se a sua base de dados principal ficar indisponível, pode ser restaurada a partir de uma cópia de segurança com um RPO de minutos e um RTO de minutos a horas, consoante o tamanho da base de dados.
Para requisitos de RPO e RTO mais rigorosos, pode configurar o AlloyDB Omni numa configuração de alta disponibilidade através do Patroni. Nesta arquitetura, existe uma base de dados principal e duas bases de dados em espera ou réplicas. Pode configurar o AlloyDB Omni para usar a replicação de streaming do PostgreSQL padrão para garantir que cada transação confirmada na base de dados principal é replicada de forma síncrona para ambas as bases de dados de reserva. Isto oferece um RPO de zero e um RTO inferior a sessenta segundos para a maioria dos cenários de falha.
Dependendo da configuração do cluster, a replicação síncrona pode afetar o tempo de resposta das transações, e pode optar por arriscar uma pequena quantidade de perda de dados. Por exemplo, pode ter um RPO diferente de zero em troca de uma latência transacional inferior implementando uma elevada disponibilidade com replicação assíncrona em vez de síncrona. Devido ao potencial impacto da replicação síncrona na latência das transações, as arquiteturas de alta disponibilidade são quase sempre implementadas num único centro de dados ou entre centros de dados próximos (a dezenas de km de distância/com uma latência de <10 milissegundos). No entanto, tenha em atenção que esta documentação usa a replicação síncrona como predefinição.
Para a recuperação de desastres, que é a proteção contra a perda de um centro de dados ou de uma região onde existem vários centros de dados próximos, o AlloyDB Omni pode ser configurado com a replicação de streaming assíncrona da região principal para uma região secundária, normalmente a centenas ou milhares de km de distância, ou a dezenas a centenas de milissegundos de distância. Nesta configuração, a região principal está configurada com a replicação de streaming síncrona entre as bases de dados principal e de reserva na região, e a replicação de streaming assíncrona está configurada a partir da região principal para uma ou mais regiões secundárias. O AlloyDB Omni pode ser configurado na região secundária com várias instâncias da base de dados para garantir que fica protegido imediatamente após uma comutação por falha da região principal.
Como funciona a alta disponibilidade
As técnicas e as ferramentas específicas usadas para implementar a alta disponibilidade para bases de dados podem variar consoante o sistema de gestão de bases de dados. Seguem-se algumas das técnicas e ferramentas normalmente envolvidas na implementação da elevada disponibilidade para bases de dados, que podem variar consoante o sistema de gestão de bases de dados:
Redundância: a replicação da base de dados em vários servidores ou regiões geográficas oferece opções de comutação por falha se uma instância principal ficar inativa.
Comutação por falha automática: mecanismo para detetar falhas e mudar facilmente para uma réplica em bom estado, minimizando o tempo de inatividade. As consultas são encaminhadas para que os pedidos da aplicação cheguem ao novo nó principal.
Continuidade dos dados: são implementadas salvaguardas para proteger a integridade dos dados durante falhas. Isto inclui técnicas de replicação e verificações de consistência dos dados.
Clustering: o clustering envolve o agrupamento de vários servidores de base de dados para funcionarem em conjunto como um único sistema. Desta forma, todos os nós no cluster estão ativos e processam pedidos, o que proporciona equilíbrio de carga e redundância.
Recuperação: métodos para reverter para a arquitetura original através de nós primários e de réplica pré-transferência de falhas nas respetivas capacidades originais.
Equilíbrio de carga: a distribuição de pedidos de base de dados por várias instâncias melhora o desempenho e processa o aumento do tráfego.
Monitorização e alertas: as ferramentas de monitorização detetam problemas como falhas do servidor, latência elevada, esgotamento de recursos e acionam alertas ou procedimentos automáticos de comutação por falha.
Cópia de segurança e restauro: as cópias de segurança podem ser usadas para restaurar bases de dados para um estado anterior em caso de corrupção de dados ou falha catastrófica.
Agrupamento de ligações (opcional): otimiza o desempenho e a escalabilidade das aplicações que interagem com as suas bases de dados.
Ferramentas de alta disponibilidade
O Patroni é uma ferramenta de gestão de clusters de código aberto para bases de dados PostgreSQL concebida para gerir e automatizar a elevada disponibilidade para clusters PostgreSQL. O Patroni usa vários sistemas de consenso distribuídos, como etcd, Consul ou Zookeeper, para coordenar e gerir o estado do cluster. Algumas das principais funcionalidades e componentes do Patroni incluem a elevada disponibilidade com comutação por falha automática, eleição do líder, replicação e recuperação. O Patroni é executado juntamente com o serviço PostgreSQL em instâncias do servidor de base de dados, gerindo o respetivo estado, as comutações por falha e a replicação para garantir a elevada disponibilidade e fiabilidade.
O Patroni usa um sistema de consenso distribuído para armazenar metadados e gerir o cluster. Neste guia, usamos um Distributed Configuration Store (DCS) denominado etcd. Uma das utilizações do etcd é armazenar e obter informações de sistemas distribuídos, como a configuração, o estado de funcionamento e o estado atual, garantindo uma configuração consistente em todos os nós.
O proxy de alta disponibilidade (HAProxy) é um software de código aberto usado para o equilíbrio de carga e o proxy de aplicações baseadas em TCP e HTTP, usado para melhorar o desempenho e a fiabilidade das aplicações Web através da distribuição de pedidos recebidos por vários servidores. O HAProxy oferece equilíbrio de carga através da distribuição do tráfego de rede por vários servidores. O HAProxy também mantém o estado de funcionamento dos servidores de back-end aos quais se liga através da realização de verificações de funcionamento. Se um servidor falhar numa verificação de estado, o HAProxy deixa de lhe enviar tráfego até voltar a passar nas verificações de estado.
Considerações sobre a replicação síncrona e assíncrona
Num cluster PostgreSQL gerido pelo Patroni, a replicação pode ser configurada nos modos síncrono e assíncrono. Por predefinição, o Patroni usa a replicação de streaming assíncrona. Para requisitos de RPO rigorosos, recomendamos a utilização da replicação síncrona.
A replicação síncrona no PostgreSQL garante a consistência dos dados aguardando que as transações sejam escritas na base de dados principal e, pelo menos, numa base de dados de reserva síncrona antes de serem confirmadas. A replicação síncrona garante que os dados não são perdidos em caso de falha primária, oferecendo uma forte durabilidade e consistência dos dados. O principal aguarda confirmações do standby síncrono, o que pode levar a uma latência mais elevada e, potencialmente, a um débito mais baixo devido ao tempo de ida e volta adicional. Isto pode reduzir o débito geral do sistema, especialmente sob carga elevada.
A replicação assíncrona permite que as transações sejam confirmadas no cluster principal sem aguardar confirmações dos clusters de espera. O servidor principal envia registos WAL para os servidores de reserva, que os aplicam de forma assíncrona. Esta abordagem assíncrona reduz a latência de escrita e melhora o desempenho, mas acarreta o risco de perda de dados se o servidor principal falhar antes de o servidor de reserva ficar atualizado. Os sistemas em espera podem estar atrás do sistema principal, o que pode levar a potenciais inconsistências durante a comutação por falha.
A escolha entre a replicação síncrona e assíncrona num cluster Patroni depende dos requisitos específicos de durabilidade, consistência e desempenho dos dados. A replicação síncrona é preferível em cenários em que a integridade dos dados e a perda mínima de dados são essenciais, enquanto a replicação assíncrona é adequada para ambientes em que o desempenho e a latência mais baixa são prioritários. Pode configurar uma solução mista que envolva ter um cluster de três nós com um standby síncrono na mesma região, mas numa zona próxima ou num centro de dados diferente, e um segundo standby assíncrono numa região diferente ou num centro de dados mais distante para se proteger contra potenciais interrupções regionais.