Alta disponibilidade para postgresql

Eu sou novo no banco de dados PostgreSQL. Recentemente, nosso desenvolvedor precisou fazer algumas atualizações em nossos sistemas.

Por isso, planejamos implementar algum método para implementar o failover do banco de dados.

Com base na minha leitura do wiki do postgresql aqui , estamos tentando implementar o modo de espera quente ou quente. Então, minhas perguntas são:

1. Quais são as principais diferenças entre eles?
2. Qual é o melhor?
3. Existe algum outro método que possamos considerar para obter alta disponibilidade em nossos bancos de dados do Postgres?

1a. O modo de espera morna é um backup incremental "ativo" alimentado com blocos completos de alterações (segmentos wal) de 16 mb cada, que são enviados ao nó de espera assim que são preenchidos. Você não pode consultar um nó em espera quente. 16 mb de alterações (por padrão) podem significar muitas transações; se o mestre falhar, elas serão perdidas.

1b. Hot Standby . (também um backup incremental "ativo"). pequenas alterações são enviadas ao escravo (registros wal, que são pequenas partes de um segmento wal). Você pode consultar (somente leitura) o nó de espera ativa. A janela para transações perdidas, caso o mestre falhe, é muito pequena. Existem nós de espera ativa síncrona e assíncrona, um nó síncrono forçará o mestre a aguardar a confirmação da aplicação de alterações e, em seguida, o mestre confirmará a transação. Na replicação assíncrona, o mestre envia os registros wal e não espera confirmação . O primeiro requer um link muito confiável e rápido entre o mestre e o escravo, também adiciona sobrecarga ao mestre, mas não garante perda de dados.

Em relação aos backups incrementais: 1. Você faz uma cópia base de toda a instalação do banco de dados. 2. Envie para o escravo. 3. Configure-o para acompanhar as alterações.

A replicação de streaming (espera em espera) é a vencedora aqui. Pessoalmente, prefiro a replicação assíncrona, pois ela não impõe uma carga considerável ao mestre e o atraso da replicação é muito pequeno (alguns segundos em muitos casos)

Um complemento para essa configuração é o pg-pool. Ele atua como um proxy entre o aplicativo e os servidores que participam de uma configuração de replicação como a descrita acima, possui recursos de balanceamento de carga e consulta paralela. Também é capaz de fornecer failover automático. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

A resposta que você já recebeu é útil, mas termos um pouco confusos aqui. Todas as soluções de replicação internas usam o mesmo mecanismo básico: copiar dados de log de write-ahead para um servidor em espera.

Você pode mover esses dados do WAL para replicação, um arquivo de 16 MB por vez, usando o recurso archive_command ou o Streaming Replication (SR). Se estiver usando SR, você também deve configurar o arquivamento e o servidor alternará entre eles conforme apropriado.

Você pode ter um servidor em espera quente, que não pode responder a consultas. Ou você pode ter um servidor em espera, que pode responder somente leitura. Isso não tem relação com a forma como os dados estão entrando no modo de espera.

Cada uma dessas duas opções combina com as outras e você pode ter todas as quatro combinações. Você pode ter um Hot Standby respondendo a perguntas enquanto está sendo alimentado com arquivo por vez em segmentos WAL. Você pode ter um servidor de Replicação de Streaming que não tenha o Hot Standby ativado, para que ele não responda às consultas. Hoje em dia, o caso mais comum é a Replicação de Streaming e o Hot Standby. Esse é o conjunto completo de recursos. Novamente, não ignore o mecanismo antigo archive_command apenas porque é possível evitar agora. Ainda assim, você pode evitar falhas de streaming difíceis de recuperar.