Estou respondendo só pra reforçar um pouco mais os levantamentos do Dutra.
2015-12-03 15:28 GMT-02:00 Mauricio Tavares <[email protected]>: > O argumento que o responsável da infra deu, foi que caso um dos servidores > caia, seria fácil redirecionar as aplicações para outro servidor. > Usar o termo "fácil" para justificar o uso de servidores multi-master é até engraçado pra mim. Já parou pra pensar os, muito comentados, problemas de conflitos que podem ocorrer quando se tem multi-master assíncrono? Imagine o exemplo, bem simples, quando dois usuários diferentes tentam atualizar a mesma tupla, e aí, quem ganha? Mais complexo ainda é quando se pensa em chaves estrangeiras. Gerenciar esses conflitos é uma dor de cabeça danada. Por isso, a recomendação geral é evitar multi-master ao máximo, e só usar quando você tiver certeza que precisa e que sua aplicação e modelo da base estejam bem preparados para isso. Mesmo se considerarmos replicação multi-master síncrona, seu caso de uso não se enquadra, na minha opinião. > ...... Mas aí, tenho uma pergunta, o pgpool poderia fazer o papel do > balanceador? Ou seja, se um servidor cair, automaticamente seja direcionado > para outro servidor? > > Sim, o pgpool pode fazer tudo isso. Mas use a replicação nativa (master/slave) nos servidores PostgreSQL, a replicação por comandos do pgpool só dá dor de cabeça. > Por que não poderia ser de um a cinco mestres com quantas réplicas forem > necessárias? > Poderia ser desta forma, e ter para cada servidor mestre, um slave > replicando. Entretanto, promover o slave para o master, envolveria parar, > reconfigurar para master e reiniciá-lo. Estou correto??? > Não. Você consegue promover um slave para master sem queda ou parada. Existem várias opções onde você nem precisa reconfigurar as aplicações. Como usar um "Virtual IP" (na verdade seria um "alias", mas VIP é um termo comum), é possível automatizar essa operação usando o pgpool ou ferramentas de HA como o Pacemaker. Outra alternativa é configurar as conexões via DNS. Apesar de possível fazer "failover" completamente transparente, eu não recomendo, principalmente para ambientes melhores. Fazer isso de forma transparente é bem difícil e requer testes exaustivos. Atenciosamente, -- Matheus de Oliveira
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
