Os últimos anos têm visto uma adoção crescente do PostgreSQL. PostgreSQL é um banco de dados relacional incrível. Em termos de recursos, está lá em cima com o melhor, se não o melhor. Há muitas coisas que eu amo nele – PL/PG SQL, padrões inteligentes, replicação (que realmente funciona fora da caixa) e uma comunidade de código aberto ativa e vibrante. No entanto, além dos recursos, existem outros aspectos importantes de um banco de dados que precisam ser considerados. Se você planeja criar uma grande operação 24 horas por dia, 7 dias por semana, a capacidade de operar facilmente o banco de dados quando ele estiver em produção se torna um fator muito importante. Nesse aspecto, o PostgreSQL não se sustenta muito bem. Nesta postagem do blog, detalharemos alguns desses desafios operacionais com o PostgreSQL. Não há nada fundamentalmente incorrigível aqui, apenas uma questão de priorização. Espero que possamos gerar interesse suficiente na comunidade de código aberto para priorizar esses recursos.
1. Nenhuma detecção automática de driver de cliente de failover mestre
O driver cliente do PostgreSQL não detecta automaticamente quando houve um failover de mestre (e um novo mestre foi eleito). Para contornar isso, os administradores precisam implantar uma camada de proxy no lado do servidor. As escolhas populares são mapeamento de DNS, mapeamento de IP virtual, PgPool e HAProxy. Todas essas opções podem funcionar bem, mas é necessário um aprendizado adicional significativo e um esforço do administrador. No caso em que um proxy é introduzido no caminho de dados, também há um impacto considerável no desempenho. Esse é um recurso integrado padrão em muitos dos novos bancos de dados NoSQL, e o PostgreSQL faria muito bem em se destacar em seus livros quando se trata de operações.
2. Sem Failover Automático Integrado entre Master e Standby
Quando um postgreSQL mestre falha, um dos servidores em espera precisa ser eleito para mestre. Este mecanismo não está embutido no PostgreSQL. Normalmente, ferramentas de software de terceiros, como Patroni, Pacemaker, etc., são usadas para lidar com esse cenário. Por que não ter isso embutido no servidor? Essas ferramentas de terceiros parecem enganosamente simples, mas exigem esforço, conhecimento e testes consideráveis por parte do administrador para fazer isso corretamente. Ao construir isso no banco de dados, você está fazendo um enorme favor ao administrador do banco de dados.
Facilitando o gerenciamento de um banco de dados #PostgreSQL de produçãoClique para tweet
3. Nenhuma atualização principal de tempo de inatividade zero
Não é possível atualizar seu banco de dados PostgreSQL de uma versão principal para outra sem tempo de inatividade. Você basicamente tem que desligar todos os seus servidores e usar pg_upgrade para atualizar seus dados para a versão mais recente. O tempo de inatividade não é grande, pois não há cópia de dados envolvida, no entanto, ainda há tempo de inatividade. Se você estiver executando uma operação 24 horas por dia, 7 dias por semana, isso pode não ser uma opção para você.
Com o lançamento da replicação lógica, temos uma opção alternativa para atualização online.
- Crie uma nova configuração do PostgreSQL Master-Standby com a nova versão.
- Configure a replicação lógica para replicar da versão mais antiga para a versão mais recente.
- Quando estiver pronto, altere sua string de conexão para apontar da configuração mais antiga para a nova.
Novamente, isso pode funcionar, mas a sobrecarga é enorme. Idealmente, o que é necessário aqui é uma maneira de atualizar no local de maneira contínua em uma configuração de espera principal. A atualização do MySQL permite que você atualize seus escravos no local para a nova versão e, em seguida, acione um failover.
4. Sem vácuo no local CHEIO
Autovacuum/VACUUM é muito útil e ajuda a resolver esse problema até certo ponto. Você deve examinar regularmente o inchaço em suas mesas para garantir que suas configurações de autovacuum sejam apropriadas e funcionem bem para sua mesa. No entanto, o autovacuum não vai até o fim - na verdade, ele não acaba mesclando e excluindo as páginas. Se você tiver um grande número de atualizações, inserir e excluir cargas de trabalho, suas páginas ficarão fragmentadas, afetando seu desempenho. A única maneira de contornar isso é executar VACUUM FULL que basicamente reconstruirá todas as páginas para eliminar a fragmentação. No entanto, este processo só pode ser feito com tempo de inatividade – sua mesa está inativa pela duração do VACUUM FULL. Para grandes conjuntos de dados, isso pode levar várias horas e não é uma alternativa prática se você deseja executar uma operação 24 horas por dia, 7 dias por semana.
Observação:A comunidade já começou a trabalhar no mecanismo de armazenamento zheap que supera essa limitação.
Se houver outras melhorias que você acha que seriam úteis, sinta-se à vontade para deixar um comentário.
