Em 3 de dezembro de 2015 15:10, Guimarães Faria Corcete DUTRA, Leandro < [email protected]> escreveu:
> 2015-12-03 14:42 GMT-02:00 Mauricio Tavares <[email protected]>: > > > > Quanto falei "ganbiarra" (note as aspas) não foi para desmerecer os > esforços > > da comunidade em criar melhorias para um banco que já fornece muitos > > recursos avançados. (muitos já evidenciados aqui na lista). Mas foi para > > evidenciar que tais modificações foram implementadas para suprir uma > > necessidade que outros bancos de dados já fornecem nativamente. > > Mas então o termo não é esse. Colocar entre aspas não nos diz > exatamente o que você quis dizer. > > E outra: quando o PostgreSQL implementa algo, não vende para casos > inadequados, e oferece alta qualidade. Só uma comparação: leia o > artigo ‘You don’t need RAC’ (ou algo assim) da Oak table network, e > compare a lista de defeitos (/bugs/) conhecidos do PostgreSQL com a de > outros SGBDs, livres ou proprietários, SQL ou prerrelacionais (‘NoSQL’ > &c). > > > > Uma coisa que me chamou a atenção no postgres XC, foi a versão do > Postgres é > > a 9.1. uma versão relativamente antiga visto que já estamos na versão > 9.4. > > Ressalto que, confio na versão 9.1. > > E se você ler o que a equipe do XC publicou a respeito, ou mesmo > outros projetos com abordagens parecidas, como a do PostGIS (em menor > grau), verás que o atraso é proposital, faz parte do processo. > > De novo, é uma necessidade de nicho, e um grande aumento de > complexidade num projeto que hoje tem zero defeitos conhecidos. > Devagar com o andor… que deste lado do paraíso funcional, o santo é de > barro. > > > > O órgão onde trabalho possui muitos servidores (uns virtuais, outros > > físicos) com bases de dados pequenas. Visando um melhor aproveitamentos > dos > > recursos disponíveis na infraestrutura, foi cogitado em montar uma "Base > > Única de Dados", e agrupar todas estas pequenas bases de dados nesta base > > única. Inicialmente seriam entre 3 a 5 nós de servidores. É por isto a > > necessidade do multi-master. > > Multimestre (BD distribuído) me parece uma solução completamente > equivocada, pelo menos tomando por base essa descrição para lá de > sucinta. > > Vejamos. Hoje são bases distintas. Por que unificá-las implicaria em > ter vários mestres? Por que não poderia ser de um a cinco mestres com > quantas réplicas forem necessárias? Porque não podem ser até cinco > bases se comunicando entre si? > Por que unificá-las implicaria em ter vários mestres? 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. ...... 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? 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??? Porque não podem ser até cinco bases se comunicando entre si? Até onde sei, cinco base se comunicando entre sí, seria 1 master e 4 slave. Correto? Ou tem outra forma de implementar esta comunicação entre elas? > > Veja que o uso de réplicas tem dois benefícios: além de alta > disponibilidade e recuperação, também podem receber muitas consultas > para aliviar os servidores principais. > > Concordo plenamente... Temos alguns sistemas que usam um servidor master para as transações e um servidor slave só para as atividades de relatórios e BI. > > > Bem, o cenário é este.... E evidentemente estou aberto a sugestões de > uma > > arquitetura diferente a multi-master. Entretanto, precisarei de apoio dos > > Srs. para ter argumentos técnicos para discutir dais propostas com a > equipe > > de infra, visto que é ela que está batendo o pé em ter tal ambiente > > multi-serve. > > O principal argumento é a falta de necessidade. Pelo menos em sua > mensagem, não encontrei argumentos demonstrando a necessidade de BD > distribuída, muito menos demonstração da consideração (e descarte) de > alternativas. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:[email protected] > +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:[email protected] > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Mauricio T. Leite Analista de Sistemas
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
