Abaixo está um trecho do nosso whitepaper “PostgreSQL Management and Automation with ClusterControl” que pode ser baixado gratuitamente.
Observação da revisão: Lembre-se de que os termos usados neste blog Master-Slave são sinônimos de termos Master-Standby usados pelo PostgreSQL. Estamos usando Master-Slave para manter o paralelismo com outras tecnologias.
Para configuração de HA podemos ter várias arquiteturas, mas as básicas seriam arquiteturas mestre-escravo e mestre-mestre. Os servidores de banco de dados podem trabalhar juntos para permitir que um segundo servidor assuma rapidamente se o servidor primário falhar (alta disponibilidade ), ou para permitir que vários computadores sirvam os mesmos dados (balanceamento de carga).
Arquiteturas mestre-escravo do PostgreSQL
Essas arquiteturas nos permitem manter um banco de dados mestre com um ou mais servidores em espera prontos para assumir as operações se o servidor primário falhar. Esses bancos de dados em espera permanecerão sincronizados (ou quase sincronizados) com o mestre.
A replicação entre o mestre e os escravos pode ser feita por meio de instruções SQL (esperas lógicas) ou por meio de modificações internas da estrutura de dados (esperas físicas). O PostgreSQL usa um fluxo de registros WAL (write-ahead log) para manter os bancos de dados em espera sincronizados. Se o servidor principal falhar, o standby contém quase todos os dados do servidor principal, e pode ser rapidamente transformado no novo servidor de banco de dados mestre. Isso pode ser síncrono ou assíncrono e só pode ser feito para todo o servidor de banco de dados.
Configurar a replicação de streaming é uma tarefa que exige que algumas etapas sejam seguidas minuciosamente. Para obter essas etapas e obter mais informações sobre esse assunto, consulte:Torne-se um DBA do PostgreSQL - Como configurar a replicação de streaming para alta disponibilidade.
A partir da versão 10, o PostgreSQL inclui a opção de configurar a replicação lógica.
A replicação lógica permite que um servidor de banco de dados envie um fluxo de modificações de dados para outro servidor. A replicação lógica do PostgreSQL constrói um fluxo de modificações de dados lógicos do WAL. A replicação lógica permite que as alterações de dados de tabelas individuais sejam replicadas. Ele não exige que um servidor específico seja designado como mestre ou réplica, mas permite que os dados fluam em várias direções.
Você pode encontrar mais informações sobre replicação lógica:Blog:Uma visão geral da replicação lógica no PostgreSQL.
Para garantir efetivamente a alta disponibilidade, não basta ter uma arquitetura mestre-escravo. Também precisamos habilitar alguma forma automática de failover, portanto, se algo falhar, podemos ter o menor atraso possível na retomada da funcionalidade normal. O PostgreSQL não inclui um mecanismo de failover automático para identificar falhas no banco de dados mestre e notificar o salve para assumir a propriedade, o que exigirá um pouco de trabalho por parte do DBA. Você deve trabalhar em um script que inclua o comando pg_ctl promote, que irá promover o slave como um novo master. Existem também algumas ferramentas de terceiros para essa automação. Muitas dessas ferramentas existem e estão bem integradas com os recursos do sistema operacional necessários para um failover bem-sucedido, como a migração de endereço IP.
Após um failover, você precisa modificar seu aplicativo de acordo para trabalhar com o novo mestre. Você também terá apenas um servidor funcionando, então a recriação da arquitetura mestre-escravo precisa ser feita, então voltamos à mesma situação normal que tínhamos antes do problema.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
Arquiteturas Master-Master do PostgreSQL
Essa arquitetura fornece uma forma de minimizar o impacto de um erro em um dos nós, pois o outro nó pode cuidar de todo o tráfego, talvez afetando um pouco o desempenho, mas nunca perdendo funcionalidade. Também é usado para realizar (e talvez este seja um ponto ainda mais interessante) escalabilidade horizontal (scale-out), oposto ao conceito de escalabilidade vertical onde adicionamos mais recursos a um servidor (scale-up).
Para implementar essa arquitetura, você precisará usar ferramentas externas, pois esse recurso (ainda) não é suportado nativamente pelo PostgreSQL.
Você deve ter muito cuidado ao escolher uma solução para implementar master-master, pois existem muitos produtos diferentes. Muitos deles ainda são “verdes”, com poucos usuários sérios ou casos de sucesso. Alguns outros projetos, por outro lado, foram abandonados, pois não há mantenedores ativos.
Para mais informações sobre as ferramentas disponíveis, consulte:Blog:Top PG Clustering HA Solutions for PostgreSQL.
Balanceamento de carga e pool de conexões
Existem várias ferramentas de balanceador de carga que podem ser usadas para gerenciar o tráfego de seu aplicativo para obter o máximo de sua arquitetura de banco de dados. Da mesma forma, existem alguns outros que podem ajudá-lo a gerenciar a maneira como o aplicativo se conecta ao banco de dados, agrupando essas conexões e reutilizando-as entre diferentes solicitações.
Existem alguns produtos que são usados para ambas as finalidades, como o conhecido pgpool, e outros que se concentrarão em apenas um desses recursos, como pgbouncer (pooling de conexões) e HAProxy (usado para balanceamento de carga).
