Re: [pgbr-geral] Dúvida banco replicado - tabelas temporárias

[Felipe Pereira]

Em 26 de outubro de 2016 15:36, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> Caros,
>
> Criei uma base replicada de meu banco de produção pro pessoal de BI.
> Eles faziam elas no banco de produção, só que quando apontaram pro banco
> replicado não foi possível, pois no script que eles rodam eram criadas
> tabelas temporárias.
> Pensei que as tabelas temporárias não dessem esses erros, pois elas são
> apagadas no final da transação.
>
> Tem alguma maneira de "burlar" isso?
>
> Atenciosamente,
> Luiz carlos
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Não é possível utilizar tabelas temporárias no slave do Postgresql afaik.

Mas você pode tentar substituir os selects que geram as temporárias por
CTEs na mesma query:
https://www.postgresql.org/docs/current/static/queries-with.html

A parte que geraria sua antiga temporária vai dentro do WITH e o resto você
usa como usaria depois que a temporária já existe. Não é exatamente a mesma
coisa mas já ajuda.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PostgreSQL + AWS RDS

[Felipe Pereira]

Em 8 de novembro de 2016 12:11, Emanuel Araújo  escreveu:

> > To pra dizer que depende. O que tu ta precisando fazer exatamente?
>
> na verdade preciso aumentar o armazenamento de forma automática, sem a a
> necessidade de manualizar pelo portal ou por scripts.  A ideia é que o
> provedor cuide disso.
>
> Sobre o resize pra baixo, sei disso.  E a ideia é só crescer mesmo.
>
> > Não. Nessa modalidade de discos, ele apenas provisiona a quantidade de
> IOPS que você definir, independente do  tamanho do armazenamento. O que eu
> particularmente faço é usar o tamanho do disco como provedor de IOPS, acaba
> saindo muito mais barato
>
> Então, quando ela fala em: "With just a few clicks in the AWS Management
> Console, you can deploy a PostgreSQL database with automatically configured
> database parameters for optimal performance. Amazon RDS for PostgreSQL
> database instances can be provisioned with either standard storage or
> Provisioned IOPS storage. *Once provisioned, you can scale from 5GB to
> 6TB of storage* and from 1,000 IOPS to 30,000 IOPS. Amazon RDS for
> PostgreSQL also enables you to scale out beyond the capacity of a single
> database deployment for read-heavy database workloads"
>
> Ele não o faz automático.  É isso?
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


É isso mesmo Emanuel.

Ele apenas provisiona o recurso (espaço ou IOPs), e ainda diz que "you can
scale" ou seja, não se compromete a fazer um "automatic scale".
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] DBLINK Oracle x PGBouncer

[Felipe Pereira]

2016-10-24 11:37 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> Flávio,
>
> Funcionou
>
> ignore_startup_parameters = extra_float_digits,application_name,geqo
>
> Só não sei as consequências disso...
>
> Desculpa os aperreios aí.
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Link do parâmetro:
https://www.postgresql.org/docs/current/static/geqo-pg-intro.html

Ele controla o comportamento do planejador de queries.

O servidor tem um valor default para este parâmetro, então tirá-lo da sua
conexão não deverá afetar o comportamento do seu sistema.Isto só
aconteceria caso você estivesse explicitamente configurando um valor
diferente do servidor por algum motivo especial (o que não parece ser o
caso mesmo).
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] armazenamento de imagens no Banco x File System

[Felipe Pereira]

Em 25 de outubro de 2016 09:34, Michel Luiz Milezzi  escreveu:

> >>O que é mais indicado, gravar arquivos em file system ou no próprio
>> banco ?
>>
>
> Existe uma terceira via, que é a de usar um serviço exclusivo para este
> fim, como o Cloudinary [1].
>
> [1] http://cloudinary.com/
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



Adicionando à pergunta original: li um paper da Microsoft uma vez tratando
do assunto, obviamente que a relação era entre SQL Server e File System. A
conclusão do artigo deles era que arquivos até 2 MB eram melhor gerenciados
pelo Banco de Dados, já de 2 MB até 10 MB não havia diferença e arquivos
maiores do que 10 MB eram melhor gerenciados pelo file system.

De qualquer forma a resposta do Gurgel levanta os assuntos necessários a se
verificar antes de tomar a decisão.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] PgDay Campinas 2017

[Felipe Pereira]

Boa tarde a todos,

Em 2017 o PgDay Campinas será realizado dentro do evento DevCamp (
http://www.devcamp.com.br/).

A submissão de palestras está aberta até o fim de janeiro através do
seguinte link:
http://www.devcamp.com.br/seja-um-palestrante/

Ao escolher a trilha, seleciona a opção "*Data Ocean*", que será a trilha
dedicada a bancos de dados.

Um abraço,

Felipe
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Database is in recovery mode

[Felipe Pereira]

Em 20 de abril de 2017 15:35, Tiago José Adami  escreveu:

> Boa tarde a todos.
>
> Tenho um servidor na Amazon com PostgreSQL 9.4.9 64-bit instalado, lá
> roda uma versão do Fedora modificada.
>
> Há 16 GB de memória RAM.
>
> max_connections=300
> shared_buffers=2GB
> work_mem=4MB
>
> De uns tempos para cá, após configurar o backup com arquivamento de
> logs está ocorrendo este erro sem muita razão aparente. Sempre ocorre
> depois de algum SQL SELECT (não necessariamente o mesmo e dificilmente
> usando as mesmas tabelas, já verifiquei isso).
>
> (...)
> WARNING,57P02,"terminating connection because of crash of another
> server process","The postmaster has commanded this server process to
> roll back the current transaction and exit, because another server
> process exited abnormally and possibly corrupted shared memory.","In a
> moment you should be able to reconnect to the database and repeat your
> command."
> (...)
>
> A aplicação recebe uma mensagem "Database is in recovery mode". Dura 2
> ou 3 segundos e volta ao normal.
>
> Nas minhas pesquisas e até onde vai meu conhecimento isto ocorre com
> problemas de hardware, em especial, memórias (lembro-me do tempo do
> PostgreSQL 7.4 rodando em servidores com pentes de memória de
> velocidade e latências diferentes).
>
> Mas levando em consideração que o servidor está na Amazon... o que
> mais poderia estar causando este erro? Algum palpite?
>
>
> TIAGO J. ADAMI
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



Olá Tiago,

O Linux possui um recurso chamado Out Of Memory Killer que pode estar
matando seus processos.

Quando um processo child é morto (por exemplo, os Selects que vc mencionou)
o postmaster reinicia a instância para se preservar, entrando em recovery
mode, conforme vc constatou.

Você pode proteger o postgres do OOM Killer através das configurações no
script de inicialização do init.d (que você pode copiar a partir do
$postgres_source/contrib/start-scripts/linux)

Se precisar de mais detalhes avise.

Um abraço,

Felipe
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: RES: PostgreSQL ataque???

[Felipe Pereira]

Em 20 de abril de 2017 12:06, Luiz Oliveira 
escreveu:

> O servidor Windows 2012 e para ajudar desabilitaram o firewall
>
>
>


O firewall não é o problema aqui.

Se a porta do banco de dados está aberta para a internet por algum
requisito de negócio (conexões de outros sistemas/clientes/etc) o firewall
teria que liberar a porta de qualquer maneira. Caso não haja esta
necessidade de estar aberta para a internet, então neste caso sim, o
firewall deveria bloquear este acesso.

De qualquer forma, o principal ponto aqui é:

1. o pg_hba não pode estar como trust para qualquer ip
2. é necessário sempre ter uma política de backup madura (backup +
armazenamento do backup fora do servidor + testes de restore do backup para
validar o mesmo)

Isto porque o atacante apenas aproveitou uma brecha de configuração
(pessoas com bancos de dados na porta padrão, expostas na internet e sem
requisitos de senha), ou seja, não foi um ataque sofisticado do ponto de
vista do banco de dados.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: RES: PostgreSQL ataque???

[Felipe Pereira]

Em 20 de abril de 2017 14:24, Ivo Sestren Junior 
escreveu:

> Tivemos o mesmo problema em um servidor aqui hoje também.
>
> Eu duvido muito que tenha recuperação, porque assim...
> O cara excluiu todas as tabelas da base de dados, e criou somente uma com
> os dados para pagamento.
>
> A base que tínhamos era bem grande, tenho muitas duvidas se o cara que fez
> isto realmente fez o download de todos os registros e estrutura do banco
> para depois excluir e pedir o resgate.
> Creio que ele simplesmente excluiu todas as tabelas e somente deixou a
> mensagem de resgate, para neste caso alguém pagar, e mesmo assim não obter
> os dados de volta.
>
> Imagina quanto de espaço e banda o cara precisaria para pegar todos os
> dados dos que sofreram com isto.
>
> Então creio que o único modo de recuperação seja alguma forma de backup
> efetuada anteriormente.
>
>
>>
Ótimo ponto!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Configuração de Máquina

[Felipe Pereira]

Em 10 de jul de 2017 5:47 PM, "Arthur Nascimento" 
escreveu:
>
> >> * vocês sabem qual a melhor distribuição Linux usar para o
> >> postgresql.
>
> A melhor é aquela que você (ou a sua equipe) domina. É difícil ser melhor
que isso, já que a distro não faz nada por si só.
> Em segundo lugar, olhe também para a política de atualizações de cada
uma: bugfixes críticos precisam chegar em questão de poucas horas nas
máquinas de produção e, quando possível, automaticamente; enquanto que
atualizações com features novas ou mudanças maiores precisariam passar por
aprovação/homologação/validação/etc de vocês. Se a distro não tiver
políticas desses dois casos bem definidas você (na verdade a sua empresa)
vai estar correndo riscos em um ou nos dois lados. Nesse ponto eu prefiro
centos/rhel (pela documentação e suporte da RH), mas muita gente apoia
debian/ubuntu. E BSDs são excelentes também, mas eu conheço bem menos
deles. (Pessoalmente eu prefiro distros source based e rolling release, mas
profissionalmente é outra história.)
>
>
> >> * temos que nos preocupar com mais alguma coisa?
> > Muitas. Bases de dados não são triviais. [...]
>
> Muitas mesmo. Anos atrás eu encontrei o PostgreSQL High Performance 9.0
do Gregory Smith. Os primeiros capítulos descrevem em muitos detalhes todos
os aspectos importantes nessa escolha (memória, processamento, I/O,
benchmarks etc), então eu recomendo muito ele como um começo. Parece que
esse ano saiu a versão atualizada para o 9.6, que eu não li ainda, mas se
seguir a linha da anterior, então vale a pena o investimento.
>
> Boa sorte,
> --
>
> Arthur Nascimento - tureba
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Olá Beatriz,

Para um banco de dados todos os recursos são importantes para um equilíbrio
e boa performance.

Podemos destacar na seguinte ordem de importância: memória, disco
(quantidade e velocidade), CPU , rede, etc.

Como você disse que já possui um ambiente, o ideal para o novo é ser no
mínimo igual ao antigo, mas seria melhor que fosse um ambiente melhor já
prevendo o crescimento.

Depois de definido o hardware, pode-se definir o SO conforme já comentado
por aqui e por fim fazer a instalação e os tunings apropriados para o
ambiente.

Esta é apenas uma noção geral e há muito o que se aprofundar em cada ponto
de acordo com as necessidades da empresa e da aplicação.

Abs
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Database is in recovery mode

[Felipe Pereira]

Em 24 de abril de 2017 16:46, Tiago José Adami  escreveu:

> Em 20 de abril de 2017 18:10, Fabrízio de Royes Mello
>  escreveu:
> > Isso é por conta do "overcommit_ratio = 50" que indica que foi
> solicitado alocar mais memória que o "total de swap + 50% da RAM" [1] ...
> como vc nao tem swap entao ele tentou alocar mais que RAM/2 e o kernel
> matou...
> >
> > Att,
> >
> >
> > [1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
>
> Agradeço pela ajuda, Fabrízio.
>
> Inicialmente fiquei confuso porque no /var/log/messages não haviam
> entradas do OOM Killer. Mas durante a redação da resposta eu fui
> conferir se havia algo desta vez e lá estava o registro.
>
> Sobre o problema: não estava exatamente no overcommit_ratio = 50 [1]
> porque o outro parâmetro overcommit_memory estava no padrão heurístico
> - valor 0. A realidade era que o servidor estava no limite de
> utilização de memória. O total de memória em cache passou a ser
> reduzido a meros 1 ou 2 GBs pouco antes do OOM entrar em ação.
>
> Com mais de 96 conexões ativas e executando comandos SQL sem parar, em
> um momento os 16 GB de memória RAM chegaria no limite. A solução
> encontrada foi criar uma partição SWAP de 10 GB. Tão logo foi criada,
> passou a ser preenchida em até 30% nos momentos de maior utilização,
> sendo liberada nos momentos de "bonanza".
>
> Achei um artigo convincente que dá detalhes de como funcionam estes
> parâmetros do Kernel [2] dando exemplos, mas baseando-se na
> configuração overcommit_memory=2, o que limita de forma parametrizada
> o total que um processo pode alocar além do limite real.
>
> Talvez já esteja entrando em uma nova thread, mas quando falamos de um
> servidor dedicado do PostgreSQL, qual seria a recomendação? Tunar o
> overcommit conforme mostra o artigo [2] ou manter os padrões?
>
> [1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt
> [2] http://engineering.pivotal.io/post/Virtual_memory_settings_
> in_Linux_-_The_problem_with_Overcommit/
>
> TIAGO J. ADAMI
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Boa tarde Tiago,

Eu acho que estes parâmetros, servem para fazer o que você fez, ou seja,
dar uma sobrevida aos momentos de pico do seu servidor.

Caso eles não estejam configurados, o OOM poderá matar seus processos (como
você experimentou) ou (caso você configure os parâmetros de memória do
PostgreSQL para baixo) você poderá sofrer um erro de Out of Memory do
servidor para o client.

Em outras palavras, estamos apenas administrando recursos que já chegaram
ao seu limite, a verdadeira solução seria:

1. Realizar um tuning das queries para que elas utilizem menos memória
2. Aumentar a quantidade de memória RAM do servidor

Respondendo diretamente sua pergunta, eu gosto de tunar, pois assim você
tem a oportunidade de verificar o uso de swap (como você fez) e, sendo
constante, ter argumentos técnicos para recomendar a compra de mais RAM.

[]'s

Felipe
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral