2016-05-18 14:32 GMT+12:00 Euler Taveira <[email protected]>: > On 17-05-2016 22:34, Lucas Possamai wrote: > > - Possuo um master e dois slaves > > > > Há 6 horas atrás, mudei o shared_buffer de 50GB pra 35GB em meu server. > > > Qual server? master? >
sim... > > > Para validar a mudança, um restart no postgres foi necessário. Porém, o > > mesmo não subia e então foi dado um restart no server (master). > > > Reiniciar o sistema operacional? Para que? > o postgres parou mas nao reiniciou. Após tentar resolver o problema por alguns minutos, foi decidido reiniciar o servidor. > > > *Após esse reboot, estou tendo o seguinte erro:* > > > > WAL segment `pg_xlog/00000002000011E800000012` successfully archived > > on host `slave-01` > > WAL segment `pg_xlog/00000002000011E800000012` successfully archived > > on host `slave-02` > > Failed to archive WAL segment `pg_xlog/00000002000011E800000012` on > > host `localhost:30022 > > > Essa mensagem não existe na versão 9.2... > existe e vc não sabe.. pois estou usando a versão 9.2 com certeza. > > > > > *Meu archive_command:* > > > > archive_command = 'exec nice -n 19 ionice -c 2 -n 7 > > ../../bin/archive_command.ssh_to_slaves.bash "%p" slave-01 slave-02 > > localhost:30022' > > > ... e provavelmente é do seu script. > > > Por favor, alguém teria alguma dica para me passar? > > > Corrija o seu script de arquivamento. > Não acho que tenha algo errado com o script. Como estava funcionando antes do reboot??? > > Afinal de contas, alguma instância do postgres *não* subiu? O seu relato > ficou muito confuso. > > Alterar shared_buffers *não* causa a falha do início do serviço por ter > valores diferentes no principal e secundário. Na 9.2, os parâmetros > max_connections, max_prepared_transactions e max_locks_per_transaction > dos servidores secundários são os únicos que *obrigatoriamente* deve ter > valores iguais ou maiores do que no servidor principal. Caso contrário, > o início do serviço falha com uma mensagem: > Eu sei que não interfere para com slave e master. A causa do processo não ter iniciado, não foi da mudança do shared_buffer (Eu nunca disse que foi) - Não foi mudado nada além do shared_buffer. Eu vinha tendo problema de IO (uso SATA) há meses.. acabei fazendo tudo o que posso para melhorar o problema. Lendo em vários fóruns.. falando com muitas pessoas.. usando o DBA.STACK.. e a lista oficinal do Postgres, veio a tona de que o meu shared_buffer (51GB) estava alto de mais. Fiz testes em servidor VM (sei que não é a mesma coisa mas nao tenho como ter um servidor igual ao MASTER para testes), e o melhor shared_buffer apresentado foi 32GB. *Utilizei vários links e sources:* https://www.keithf4.com/a-large-database-does-not-mean-large-shared_buffers/ https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server http://pgtune.leopard.in.ua/ E então, apos meses de testes e pesquisa, foi alterado. Infelizmente está comprovado de que diminuir o shared_buffer no meu caso, não ajuda. Pelo contrário... > > FATAL: servidor em espera ativo não é possível porque max_connections = > 10 é uma configuração mais baixa do que no servidor principal (seu valor > era 100) > LOG: processo de inicialização (PID 23362) terminou com código de retorno > 1 > LOG: interrompendo inicialização porque o processo de inicialização falhou >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
