Re: [pgbr-geral] Conexões inativas não são liberadas

[Raphael Coutinho]

Raphael Coutinho

Em 07/08/2016 3:15 PM, "Marcelo Zoel" <marcelo.z...@gmail.com> escreveu:
>
> Obrigado pela resposta Raphael.
>
> Exatamente o que você faz para derrubar as conexões, executa alguma query
no banco? Seria algo deste tipo?
>
> SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname =
'regress' AND pid <> pg_backend_pid() AND state = 'idle' AND state_change <
current_timestamp - INTERVAL '5' MINUTE;
>
> Acredito que este método seja uma boa solução de contorno.

Exatamente Marcelo
>
> Em 7 de agosto de 2016 14:50, Raphael Coutinho <rcoutosi...@gmail.com>
escreveu:
>>
>> Raphael Coutinho
>>
>> Em 07/08/2016 2:44 PM, "Marcelo Zoel" <marcelo.z...@gmail.com> escreveu:
>> >
>> > Boa tarde a todos,
>> >
>> > sou novato no PostgreSQL e gostaria de pedir ajuda nesta lista para
solucionar um problema que está ocorrendo com um sistema desenvolvido por
terceiros para minha empresa.
>> >
>> > O Postgre acusa que não há mais conexões disponíveis após algum tempo
de uso do sistema, No momento não tenho outra solução a não ser derrubar o
banco e iniciar novamente.
>> >
>> > Acredito que o problema esteja relacionado a forma como o sistema está
interagindo com o banco, porém não conseguirei obter resposta do
desenvolvedor para uma possível solução em curto prazo.
>> >
>> > Reparei que as conexões estão em IDLE e minha expectativa é que o
Postgre derrubasse essas conexões por inatividade após algum período de
tempo determinado em configuração. Fiz algumas pesquisas e fiquei surpresa
que ele não tem nenhum suporte nativo para esta função.
>> >
>> > Minha pergunta é como posso implementar isso da melhor forma e sem
precisar mexer muito na minha infraestrutura e a aplicação.
>> >
>> > minha versão é a 9.3 rodando em RHEL 6.8.
>> >
>> > Agradeço a todos pela paciência.
>> >
>> > Marcelo
>>
>> Olá Marcelo,
>>
>> Também estava com esse problema, o que fiz foi um shell para eliminar
conexões com status IDLE a X tempo.
>>
>> Utilizei a view pg_settings para consultar os referidos processos.
>>
>> Abraço,
>> Raphael
>> >
>> > ___
>> > pgbr-geral mailing list
>> > pgbr-geral@listas.postgresql.org.br
>> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Conexões inativas não são liberadas

[Raphael Coutinho]

Raphael Coutinho

Em 07/08/2016 2:44 PM, "Marcelo Zoel" <marcelo.z...@gmail.com> escreveu:
>
> Boa tarde a todos,
>
> sou novato no PostgreSQL e gostaria de pedir ajuda nesta lista para
solucionar um problema que está ocorrendo com um sistema desenvolvido por
terceiros para minha empresa.
>
> O Postgre acusa que não há mais conexões disponíveis após algum tempo de
uso do sistema, No momento não tenho outra solução a não ser derrubar o
banco e iniciar novamente.
>
> Acredito que o problema esteja relacionado a forma como o sistema está
interagindo com o banco, porém não conseguirei obter resposta do
desenvolvedor para uma possível solução em curto prazo.
>
> Reparei que as conexões estão em IDLE e minha expectativa é que o Postgre
derrubasse essas conexões por inatividade após algum período de tempo
determinado em configuração. Fiz algumas pesquisas e fiquei surpresa que
ele não tem nenhum suporte nativo para esta função.
>
> Minha pergunta é como posso implementar isso da melhor forma e sem
precisar mexer muito na minha infraestrutura e a aplicação.
>
> minha versão é a 9.3 rodando em RHEL 6.8.
>
> Agradeço a todos pela paciência.
>
> Marcelo

Olá Marcelo,

Também estava com esse problema, o que fiz foi um shell para eliminar
conexões com status IDLE a X tempo.

Utilizei a view pg_settings para consultar os referidos processos.

Abraço,
Raphael
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Bloquear visualização das tabelas

[Raphael Coutinho]

Em 23 de junho de 2016 16:33, Fabio Takashi Muratani <
ftaka...@touchhealth.com.br> escreveu:

> Mesmo se eu criar um novo esquema e um usuário nesse novo esquema eu vou
> conseguir conectar em qualquer banco e executar um \d?
>

Me corrijam se eu estiver falando bobagem povo, mas pelo que sei você
conecta no banco default "postgres", para conectar nos demais, você precisa
de *GRAN CONNECT ON DATABASE ; *
Passei por um problema semelhante na empresa onde trabalho. No nosso caso
aqui, temos um database XPTO com N esquemas de vários clientes. Ocorre que
necessitamos criar um acesso para utilização de uma ferramente de BI (Qlik
Sense) no esquema de determinado cliente, o fato é que o cara ao conectar
no db XPTO visualizava toda estrutura de esquemas e tabelas dos demais
clientes, mesmo sem acesso de leitura, o cara conseguia visualizar os nomes
das tabelas e esquemas. Eu tentei fazer tirando o acesso ao pg_catalog, do
public e dando grant a grant, mas a parada não funfou. O Euler não
recomendou a prática, é um cara que entende bastante. No caso aqui, optamos
por manter estruturas de database por cliente. Resolveu para nós.

Abraço


> ---
> *Fábio Takashi Muratani*
> *Ambiente de Produção*
>
> <http://www.touchtecnologia.com.br/>
> <http://www.touchhealth.com.br/>
> <http://www.touchtecnologia.com.br/>
>
> *E-mail:* ftaka...@touchhealth.com.br <ftaka...@touchtec.com.br>
> *Tel:* 55 11 3846- Ramal: 1209
>
> Em 23 de junho de 2016 15:41, Maycon Pimentel de Freitas <
> maycon.pimen...@gmail.com> escreveu:
>
>> On 23-06-2016 11:42, Fabio Takashi Muratani wrote:
>> >>Tenho um banco dentro do schema public, criei um usuário também no
>> >> schema public com apenas permissão de select em uma tabela, porém, ao
>> >> conectar com esse usuário eu consigo ver o nome de todas as tabelas do
>> >> banco, inclusive suas colunas com o "\d", existe uma maneira de
>> bloquear
>> >> isso?
>> >>
>> >Não. O acesso ao catálogo é liberado por padrão. Não, não é uma boa
>> >retirar as permissões [1] porque você vai "quebrar" algumas aplicações.
>> >
>> >
>> >[1] https://wiki.postgresql.org/wiki/Shared_Database_Hosting
>> >
>> >
>> >PS> não é um banco ou usuário dentro do esquema. Banco e usuário são
>> >globais. Além disso, um banco contém um ou mais esquemas.
>>
>> Fabio,
>> Você pode alterar o search_path do usuário removendo o public. Contudo,
>> toda e qualquer operação na tabela, deverá ser explicitado o schema.
>>  -- Alterando o search_path do usuário
>> ALTER USER  SET search_path="$user";
>> -- Exemplo de consulta a tabela
>> SELECT * FROM public.;
>>
>> Mas se o usuário tiver o um pouco de conhecimento, ele mesmo pode
>> reverter essa configuração.
>>
>>
>> Maycon Pimentel de Freitas
>> maycon.pimen...@gmail.com
>>
>> Em 23 de junho de 2016 12:16, Euler Taveira <eu...@timbira.com.br>
>> escreveu:
>>
>>> On 23-06-2016 11:42, Fabio Takashi Muratani wrote:
>>> > Tenho um banco dentro do schema public, criei um usuário também no
>>> > schema public com apenas permissão de select em uma tabela, porém, ao
>>> > conectar com esse usuário eu consigo ver o nome de todas as tabelas do
>>> > banco, inclusive suas colunas com o "\d", existe uma maneira de
>>> bloquear
>>> > isso?
>>> >
>>> Não. O acesso ao catálogo é liberado por padrão. Não, não é uma boa
>>> retirar as permissões [1] porque você vai "quebrar" algumas aplicações.
>>>
>>>
>>> [1] https://wiki.postgresql.org/wiki/Shared_Database_Hosting
>>>
>>>
>>> PS> não é um banco ou usuário dentro do esquema. Banco e usuário são
>>> globais. Além disso, um banco contém um ou mais esquemas.
>>>
>>>
>>> --
>>>Euler Taveira   Timbira - http://www.timbira.com.br/
>>>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
*Raphael Coutinho*
Skype r.coutosilva
(21) 96465-9823
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGSQL_TMP

[Raphael Coutinho]

Em 18 de abril de 2016 11:27, Matheus de Oliveira <matioli.math...@gmail.com
> escreveu:

>
> 2016-04-14 19:19 GMT-03:00 Raphael Coutinho <rcoutosi...@gmail.com>:
>
>> Estou querendo separar o pgsql_tmp do disco SSD e colocar no SAS. Já que
>> o forte do SSD é leitura, acredito que separar esse diretório vai me trazer
>> um ganho de performance, conservar a vida útil do SSD.
>
>
> Nem pense em montar uma partição no pgsql_tmp direto, nem fazer link
> simbólico nem nada do tipo. Lembre-se que no layout físico do PostgreSQL
> apenas o diretório pg_xlog aceita uma intervenção manual para ser um link
> simbólico, os demais arquivos/diretórios não devem se "mexidos" manualmente
> (salvo talvez a troca dos links simbólicos no pg_tblspc, em versões
> recentes e com muito cuidado).
>
​Valeu a dica Matheus. Aqui utilizo o pg_xlog via link simbólico e
também particionamos.


>
> Se quiser separar arquivos temporários, crie um tablespace no outro disco
> e configure o parâmetro temp_tablespaces.
> ​Me parece ser a opção mais adequada mesmo.
>


> O Dutra fez um bom comentário quanto à efetividade dessa operação (que
> compartilho), quis comentar somente sobre como fazer (pois vejo muita gente
> fazendo errado).
>
> Atenciosamente,
> --
> Matheus de Oliveira
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 96465-9823
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br
[image: Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image: Twitter
DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] PGSQL_TMP

[Raphael Coutinho]

Olá galera!


Estou querendo separar o pgsql_tmp do disco SSD e colocar no SAS. Já que o
forte do SSD é leitura, acredito que separar esse diretório vai me trazer
um ganho de performance, conservar a vida útil do SSD.

Vocês costumam trabalhar assim ? A ganho vale a pena ?


Abraços,


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

Re: [pgbr-geral] Migrando Postgresql que versão usar ?

[Raphael Coutinho]

Em 13 de abril de 2016 09:31, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le 13 avril 2016 09:25:44 GMT-03:00, Raphael Coutinho <
> rcoutosi...@gmail.com> a écrit :
> >Em 13/04/2016 9:23 AM, "Luiz Henrique" <luiz.henriqu...@gmail.com>
> >escreveu:
> >> A dúvida : para qual versão os colegas sugerem migrar ? posso ir
> >direto para mais nova ? 9.5 ?
>
> Pode.  E deve.
>
>
> >Eu optaria pela versão 9.4.
>
> Por quê?
>
> ​Sempre fico meio pé atrás com últimas versões.
>
>
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691 (Vivo) ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 96465-9823
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br
[image: Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image: Twitter
DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Migrando Postgresql que versão usar ?

[Raphael Coutinho]

Em 13/04/2016 9:23 AM, "Luiz Henrique"  escreveu:
>
> Pessoal,
>
> Trabalho com aplicação Delphi cliente servidor usando postgres 8.2.17
> Vou iniciar estudos de migração para versão 9
> A dúvida : para qual versão os colegas sugerem migrar ? posso ir direto
para mais nova ? 9.5 ?

Eu optaria pela versão 9.4.

> Ou algo mais conservador ? tipo 9.1 ou 9.3 ?
> Alguem sugere tutorial ?
> A aplicação não usa nada de específico no banco, operações básicas mesmo.
Sem triger, functions,etc. Obrigado pela dica!
>
>
> --
> Atenciosamente,
>
> Luiz Henrique
>
> "Há 3 motivos para o sucesso:
> 1-Ensinar o que se sabe;
> 2-Praticar o que se ensina;
> 3-Perguntar o que se ignora"
> São Beda (adaptado)
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Streaming Replication - PostgreSQL 9.3

[Raphael Coutinho]

Prezados



Com relação a streaming replication (PostgreSQL 9.3), estou com o seguinte
problema no meu servidor standby:

*LOG:  arquivo de log restaurado "000109430010" do arquivador*
*LOG:  endereço da página 942/BA00 inesperado no arquivo de log
000109430010, posição 0*
*LOG:  iniciado fluxo de WAL do principal em 943/1000 na linha do tempo
1*
*FATAL:  não pôde receber dados do fluxo do WAL: ERRO:  segmento do WAL
solicitado 000109430010 já foi removido*

Temos uma rotina que comprimi (7z) e envia blocos do WAL do Master para o
Standby via scp. O Standby vai aplicando conforme os mesmos vão sendo
disponibilizados. Esta rotina também efetua a limpeza dos segmentos que já
foram aplicados no Standby, para isso, utilizamos o pg_controldata para
verificar a posição atual de segmentos aplicados standby, com essa
informação pegamos todos os segmentos WAL para trás e descartamos.

Conforme a informação do log acima, ele me diz que o segmento
WAL 000109430010 referencia um segmento anterior 942/BA00,
este já foi descartado.

É isso mesmo ? Alguém já passou por esse problema ? Vou ter que
re-sincronizar tudo com o basebackup ?


Atenciosamente,

[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 96465-9823
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br
[image: Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image: Twitter
DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replication - PostgreSQL 9.3

[Raphael Coutinho]

Em 3 de fevereiro de 2016 11:35, Glauco Torres <torres.gla...@gmail.com>
escreveu:

>
>>
>> Com relação a streaming replication (PostgreSQL 9.3), estou com o
>> seguinte problema no meu servidor standby:
>>
>> *LOG:  arquivo de log restaurado "000109430010" do arquivador*
>> *LOG:  endereço da página 942/BA00 inesperado no arquivo de log
>> 000109430010, posição 0*
>> *LOG:  iniciado fluxo de WAL do principal em 943/1000 na linha do
>> tempo 1*
>> *FATAL:  não pôde receber dados do fluxo do WAL: ERRO:  segmento do WAL
>> solicitado 000109430010 já foi removido*
>>
>> Temos uma rotina que comprimi (7z) e envia blocos do WAL do Master para o
>> Standby via scp. O Standby vai aplicando conforme os mesmos vão sendo
>> disponibilizados. Esta rotina também efetua a limpeza dos segmentos que já
>> foram aplicados no Standby, para isso, utilizamos o pg_controldata para
>> verificar a posição atual de segmentos aplicados standby, com essa
>> informação pegamos todos os segmentos WAL para trás e descartamos.
>>
>> Conforme a informação do log acima, ele me diz que o segmento
>> WAL 000109430010 referencia um segmento anterior 942/BA00,
>> este já foi descartado.
>>
>
> Cara, ao que parece seu standby parou por um período ou ouve algum
> problema de comunicação.
>
>
>> É isso mesmo ? Alguém já passou por esse problema ? Vou ter que
>> re-sincronizar tudo com o basebackup ?
>>
>>
> É isso mesmo. Sim, já passei. Sim, vai ter re-sincronizar.
>

​Obrigado Glauco! Esse era meu medo. Realmente, houve uma parada na
comunicação no último fim de semana. Inclusive, eu tenho um outro standby
que fica na rede interna, a mesma do master e não tive esse problema.
Engraçado que o arquivo aparentemente está íntegro, com mesmo tamanho dos
demais segmentos, fora que ele é zipado com o 7zip e ok no teste de
integridade.

>
> Se isso for constante ajuste o wal_keep_segments, ou então guardar o WAL
> em outro lugar. Leia sobre o archive_command [1].
>
>
> [1]
> http://www.postgresql.org/docs/current/static/continuous-archiving.html
>
>
> Att Glauco Torres.
>
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 96465-9823
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br
[image: Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image: Twitter
DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro ao archive_cleanup

[Raphael Coutinho]

Em 4 de novembro de 2015 18:39, Sebastian Webber <sebast...@swebber.me>
escreveu:

>
>
> Em 4 de novembro de 2015 15:07, Raphael Coutinho <
> raphael.couti...@dbmax.com.br> escreveu:
>
>>
>>
>> Em 4 de novembro de 2015 13:18, Sebastian Webber <sebast...@swebber.me>
>> escreveu:
>>
>>> 
>>>
>>
>> Não. Nem gerou o arquivo. Permissão Ok.
>>
>>
> Conforme o Dickson sugeriu: dá uma conferida no PATH do executavel do 
> pg_archivecleanup.
> Troca o endereço padrão pelo caminho completo, por exemplo
> /usr/pgsql-9.4/bin/pg_archivecleanup
>
Obrigado galera! Era o PATH mesmo.

>
>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br [image:
Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image:
Twitter DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Erro ao archive_cleanup

[Raphael Coutinho]

Boa tarde pessoal!


Alguém já passou por isso.

*AVISO:  archive_cleanup_command "pg_archivecleanup -d
/standby_db/archives/ -x .7z %r 2>> cleanup.log": código retornado 32512*

procurei na documentação e não localizei esse código.

abs

-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br [image:
Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image:
Twitter DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro ao archive_cleanup

[Raphael Coutinho]

Em 4 de novembro de 2015 13:18, Sebastian Webber <sebast...@swebber.me>
escreveu:

>
>
> Em 4 de novembro de 2015 13:03, Raphael Coutinho <
> raphael.couti...@dbmax.com.br> escreveu:
>
>> Boa tarde pessoal!
>>
>
> Boa tarde!
>
>
>> Alguém já passou por isso.
>>
>> *AVISO:  archive_cleanup_command "pg_archivecleanup -d
>> /standby_db/archives/ -x .7z %r 2>> cleanup.log": código retornado 32512*
>>
>>
> Alguma saida nesse arquivo cleanup.log?
>

Não. Nem gerou o arquivo. Permissão Ok.

>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br [image:
Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image:
Twitter DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replicação

[Raphael Coutinho]

Em 15 de setembro de 2015 12:03, Matheus de Oliveira <
matioli.math...@gmail.com> escreveu:

>
> 2015-09-14 12:32 GMT-03:00 Raphael Coutinho <raphael.couti...@dbmax.com.br
> >:
>
>> diretório onde ficam armazenados os archives, faz um scp para o standby
>> remoto e lá o restore command se encarrega de extrair e disponibilizar para
>> restauração.
>>
>> Feito isso, o nosso shell verifica em ambos os Servidores Standby em qual
>> segmento eles estão conforme a consulta abaixo:
>>
>>
>> *select pg_last_xlog_replay_location()*
>> Sendo assim,  *sabendo o ponto dos dois, pegamos o segmento inferior, e
>> removemos tudo para trás.*
>>
>
> Como já mencionado, o procedimento está incorreto.
>
> Mas ao invés de fazer isso "na raça", porque não configure o
> "archive_cleanup_command" no seu "recovery.conf" [1]?
>
Sim, ele está configurado no conf dos nossos Servers Standby, O Standby
que fica na rede local, fica a  maior parte do tempo em Streaming, porém o
que fica remoto (AWS), recebe os archives zipados via scp, aplica e o
archive_cleanup se encarrega da limpeza. O intuito do Shell é tratar da
limpeza dos archives gerados e armazenados aqui no ambiente do MASTER, a
ideia é ele pegar o último segmento aplicado no Standby01 e no Standby 02,
pegar o menor dentre eles, e limpar tudo para trás.


> Recomendo inclusive a utilização do pg_archivecleanup [2], que foi feito
> exatamente para isso.
>
> [1]
> http://www.postgresql.org/docs/current/static/archive-recovery-settings.html#ARCHIVE-CLEANUP-COMMAND
> [2] http://www.postgresql.org/docs/current/static/pgarchivecleanup.html
>
> Atenciosamente,
> --
> Matheus de Oliveira
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br [image:
Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image:
Twitter DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replicação

[Raphael Coutinho]

Em 14 de setembro de 2015 17:39, Euler Taveira <eu...@timbira.com.br>
escreveu:

> On 14-09-2015 17:10, Raphael Coutinho wrote:
>
>> A versão que utilizo é a 9.3.9
>>
> >
> Então o script fica mais simples.
>
> Não entendi bem o uso desse pg_controldata.
>>
> >
> RTFM.
>
   Valeu as dicas. Vou fazer isso.

>
> Utilizamos essa consulta (select pg_last_xlog_replay_location() nas
>> máquinas standby, justamente com o intuito de evitar a exclusão de algum
>> segmento que ainda não estivesse sido aplicado.
>>
>> replay != ponto do REDO. Se acontecer alguma falha no standby, o postgres
> inicia a recuperação do WAL a partir do "restartpoint".
>
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br [image:
Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image:
Twitter DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replicação

[Raphael Coutinho]

Em 14 de setembro de 2015 14:07, Euler Taveira <eu...@timbira.com.br>
escreveu:

> On 14-09-2015 12:32, Raphael Coutinho wrote:
>
>> De ontem para hoje, ocorreu uma situação curiosa. A Máquina remota,
>> estava solicitando um determinado segmento WAL. Ex. 46C05, sendo que a
>> consulta neste ambiente estava informando que o mesmo estava na 46F01.
>> Alguém já passou por isso ?
>>
>> Faltou informação, mas uma possibilidade é que 46C05 tenha um
> "restartpoint".
>
> Além disso, do jeito que você está fazendo está errado. Você precisa se
> basear no último local do REDO no servidor principal. Você não informou a
> versão do postgres mas a partir do 9.3 o pg_controldata relata o nome do
> arquivo que você precisa.
>
   A versão que utilizo é a 9.3.9
   Não entendi bem o uso desse pg_controldata.
   Utilizamos essa consulta (select pg_last_xlog_replay_location() nas
máquinas standby, justamente com o intuito de evitar a exclusão de algum
segmento que ainda não estivesse sido aplicado*.*


>
> $ pg_controldata /db/pgsql/data/ | grep 'REDO WAL'
> Latest checkpoint's REDO WAL file:0002072000F6
>
> Se for uma versão anterior, você vai precisar calcular o WAL:
>
> $ pg_controldata /db/pgsql/data/ | grep -E 'REDO|TimeLineID'
> Latest checkpoint's REDO location:720/F6A798C8
> Latest checkpoint's REDO WAL file:0002072000F6
> Latest checkpoint's TimeLineID:   2
> Latest checkpoint's PrevTimeLineID:   2
>
> Use o TimeLineID (2) para calcular os primeiros 8 caracteres preenchendo
> com zeros a esquerda (0002), o local do REDO (720) preenchendo com
> zeros a esquerda (0720) e a posição do REDO (F6) preenchendo com zeros
> a esquerda (00F6).
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br <http://www.dbmax.com.br/>
www.dbmax.com.br [image:
Facebook DBMax]
<http://www.facebook.com/DBMax.Inteligencia.Estrategica> [image:
Twitter DBMax] <http://twitter.com/DBMax_IE> [image: Blog DBMax]
<http://dbmax.com.br/blog/>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Monitoramente IO

[Raphael Coutinho]

Em 21/08/2015 14:12, Matheus de Oliveira matioli.math...@gmail.com
escreveu:


 2015-08-21 12:58 GMT-03:00 Raphael Coutinho raphael.couti...@dbmax.com.br
:

 Existe alguma ferramenta que eu consiga identificar os processos do
postgres que estão demandando mais escrita em disco. Utilizo as ferramentas
de sistema do Linux, iostat, vmstat, iotop. porém queria identificar os
processos a nível do banco de dados.

 Situação:
 Vários processos rodam em paralelo no servidor, eu quero conseguir
identificar a carga de IO que o INSERT. Existe algo nesse sentido ?


 Usando o iotop, por exemplo, você pode identificar o pid do processo que
está rodando e consultar a view pg_stat_activity para identificar o que o
backend está fazendo.

 Se não me engano o pg_activity [1] dá visão de uso de I/O também.

 [1] https://github.com/julmon/pg_activity

 Atenciosamente,
 --
 Matheus de Oliveira

Valeu pessoal! Vou ver o que consigo montar aqui e tentar unificar essas
informações do iotop com as views do pgsql.

abraço



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

[pgbr-geral] Monitoramente IO

[Raphael Coutinho]

Boa tarde pessoal


Existe alguma ferramenta que eu consiga identificar os processos do
postgres que estão demandando mais escrita em disco. Utilizo as ferramentas
de sistema do Linux, iostat, vmstat, iotop. porém queria identificar os
processos a nível do banco de dados.

Situação:
Vários processos rodam em paralelo no servidor, eu quero conseguir
identificar a carga de IO que o INSERT. Existe algo nesse sentido ?


Atenciosamente.

[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

Em 31 de julho de 2015 17:36, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2015-07-31 17:31 GMT-03:00 Sebastian Webber sebast...@swebber.me:
 
  Em 31 de julho de 2015 17:23, Guimarães Faria Corcete DUTRA, Leandro
  l...@dutras.org escreveu:
 
  E aí Dutra, tudo bem?

 Fora uma dorzinha de cabeça… e tu?


  Quanto ao tamanho, claro, o
  menor tamanho de disco pode atender a demanda do sistema, mas o ponto
 aqui
  não seria sugerir o melhor cenário?

 Esse é o ponto chave, acho: não temos informação suficiente para
 decidir qual o melhor cenário.  Eu, por exemplo, vi o consulente falar
 em SSD, e presumi que ele já decidira ter orçamento para isso.  Mas
 olhando o resto das informações prestadas, pode não ser o caso.

O foco é o desempenho. A galera aqui gera muitos relatórios, listas e a
ideia é entregar isso pro cliente o mais rápido possível.
Quero conseguir consolidar a melhor opção de Hardware pra isso, e
depois trabalhar na Tunning do Banco.
Com relação a valores, a empresa está aberta.


 Realmente, se ele for crescer dos 200 GB, pode ser que SSD saiba muito
 caro, e aí o SAS 15K RPM pode ser boa pedida.


Olá Pessoal! Fechamos o Server conforme abaixo:


Servidor Torre de 13.º Geração com Chassis para até 8 discos de 3.5

·Placa de vídeo Matrox® G200eR2 com 16MB de memória

·02 Processadores Intel Xeon E5-2620 v3 de 6 Núcleos, 2.4GHz
(3.2GHz de Frequência Máxima), 15MB de Cache, QPI Link de 8.00GT/s

·Sistema com dois processadores Instalados

·PowerEdge Server FIPS TPM Incluso

·2 x 16GB de memória RDIMM, com taxa de transferência de 2133MT/s,
Dual Rank, Largura de Dado x4

·Disco rígido 300GB 10K RPM SAS 6Gbps 2.5 Hot Plug, 3.5 Carrier

·Disco rígido de 600GB 10K RPM SAS 6Gbps de 2,5 Hot Plug em
Carrier de 3.5, 13G

·4 discos SSD 200GB SATA Mix Use MLC 6Gbps, 2.5 em carrier 3.5,
Hot-plug

·Controladora de discos PERC H730 com 1GB de cache

·Unconfigured RAID for H330/H730/H730P (1-16 HDDs or SSDs)

·Chassis para até 8 discos de 3.5 Hot Plug, configuração em torre

·Casters para PowerEdge T430

·Bezel de segurança

·Documentação inclusa

·Configuração de Performance Otimizada nas Memórias

·Configuração de Performance na BIOS

·Placa de gerenciamento remoto iDRAC8 Enterprise

·Heatsink for PowerEdge T430

·Drive de DVD-ROM SATA Interno

·Fontes redundantes, Hot Plug (1+1), 495W

·2 cabos de força C13, BR14136 (padrão brasileiro), 250V, 10A, 2
metros de comprimento

·Placa On-Board Dual Port 1GbE

·Sem sistema operacional - Consulte matriz de homologação de
sistemas em www.dell.com/Ossupport

·Instalação física não inclusa

·3 anos de garantia ProSupport 24x7 com atendimento on-site no
próximo dia útil


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



-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

Valeu a dica Flávio!

Em 31 de julho de 2015 11:43, Flávio Silveira f...@terra.com.br escreveu:



 On 31/07/2015 11:26, Raphael Coutinho wrote:

 A kingston tem uma vertente de SSD para Servidores chamada SSDNow!

 Vou dar uma pesquisada para ver o que a galera que está utilizando fala
 sobre.

 Pela descrição tem sistema de proteção contra queda de energia, a
 ferramenta de monitoramento da vida útil. Parece bem bacana, e  os produtos
 da Kingston costumam ser de qualidade.

 Se alguém aí tiver experiências com este modelo. Fico grato se
 compartilhar.

 Abraço.






 Em 30 de julho de 2015 16:24, Guimarães Faria Corcete DUTRA, Leandro 
 l...@dutras.orgl...@dutras.org escreveu:

 2015-07-30 16:20 GMT-03:00 Tiago José Adami  adam...@gmail.com
 adam...@gmail.com:
  Agora, tenha em mente que o custo de um SSD para servidor é alto.

 Sim.


  Talvez você possa investir em 2 discos de SAS 15.000 RPM para
  configurar um RAID 1

 Três.  Precisa ter um estepe, se quiser ter alta confiabilidade e
 disponibilidade.



 --
 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
 +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
 BRAZIL GMT−3  MSN: msnim:chat?contact= lean...@dutra.fastmail.fm
 lean...@dutra.fastmail.fm
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 --
 [image: DBMax - Intelgências Estratégica] Raphael Coutinho
 +55 (21) 3114-8869 +55 (21) 99884-3834
 http://www.dbmax.com.br/raphael.couti...@dbmax.com.br
 http://www.dbmax.com.br/www.dbmax.com.br [image: Facebook DBMax]
 http://www.facebook.com/DBMax.Inteligencia.Estrategica [image: Twitter
 DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
 http://dbmax.com.br/blog/




 ___
 pgbr-geral mailing 
 listpgbr-ge...@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


 Bom dia Raphael,

   Desculpe postar aqui embaixo mas não gosto de top post.

   Em termos de SSD, os únicos dois fabricantes no qual eu confiaria meus
 dados são Intel e Samsung, os outros sou bastante reticente.

 Abraços



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




-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

A kingston tem uma vertente de SSD para Servidores chamada SSDNow!

Vou dar uma pesquisada para ver o que a galera que está utilizando fala
sobre.

Pela descrição tem sistema de proteção contra queda de energia, a
ferramenta de monitoramento da vida útil. Parece bem bacana, e  os produtos
da Kingston costumam ser de qualidade.

Se alguém aí tiver experiências com este modelo. Fico grato se
compartilhar.

Abraço.






Em 30 de julho de 2015 16:24, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2015-07-30 16:20 GMT-03:00 Tiago José Adami adam...@gmail.com:
  Agora, tenha em mente que o custo de um SSD para servidor é alto.

 Sim.


  Talvez você possa investir em 2 discos de SAS 15.000 RPM para
  configurar um RAID 1

 Três.  Precisa ter um estepe, se quiser ter alta confiabilidade e
 disponibilidade.



 --
 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
 +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
 BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

Em 31 de julho de 2015 16:37, Sebastian Webber sebast...@swebber.me
escreveu:



 Em 30 de julho de 2015 12:33, Raphael Coutinho 
 raphael.couti...@dbmax.com.br escreveu:

 Boa tarde Galera!


 Boa tarde!


 Vamos montar um Servidor que vai abrigar a nossa base de produção com
 aproximadamente 200Gb.


 Essa é a base de produção e o DW rodam na mesma instância? ou estamos
 falando somente do servidor de DW?


Olá Sebastian! Sim. Base de Produção e  DW.



 Temos uma grande carga de dados, porém o ponto forte são as consultas
 complexas da turma de BI.

 Estou a estudar que tipo de discos utilizar. Você tem alguma
 recomendação, a princípio penso em utilizar um misto de discos SAS 15K e
 SSD para suprir as consultas, já que pelo que li o SSD tem um melhor
 potencial em leitura.


 A gravação do SSD também é superior. Mas o ponto em questão é: quanto é o
 consumo de IOPS do teu servidor? Antes de pensar em RAID e discos, vale a
 pena ter isso em conta. Como teu volume de dados é pequeno, dá pra pra
 chutar um RAID 1 de SSD, mas ainda assim eu prefiro saber a demanda de IOPS
 pra ver o que vale mais a pena.

 Vou levantar  essa questão do IOPS.

Falando em preço, normalmente 1 SSD tem um preço muito maior que um HD SAS
 15k. Não tenho idéia precisa dos valores, mas a bem pouco tempo atrás o
 valor era absurdo (tipo 1 SSD custava 6 discos SAS).  Isso vai fazer muita
 diferença na hora de comprar o servidor.

 Uma coisa importante: Disco estraga (tanto HD quanto SSD), assim vale a
 pena comprar com o server pra que o mesmo tenha aquela garantia bacana de 5
 anos e te deixe trabalhar tranquilo.

 --
 Sebastian Webber
 http://swebber.me

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




-- 
[image: DBMax - Intelgências Estratégica] Raphael Coutinho
+55 (21) 3114-8869 +55 (21) 99884-3834
raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

Boa tarde Galera!


Vamos montar um Servidor que vai abrigar a nossa base de produção com
aproximadamente 200Gb.

Temos uma grande carga de dados, porém o ponto forte são as consultas
complexas da turma de BI.

Estou a estudar que tipo de discos utilizar. Você tem alguma recomendação,
a princípio penso em utilizar um misto de discos SAS 15K e SSD para suprir
as consultas, já que pelo que li o SSD tem um melhor potencial em leitura.

Desde já agradeço qualquer orientação, material de pesquisa que ajude.


  [image: DBMax - Intelgências Estratégica] Raphael Coutinho
 +55 (21) 3114-8869 +55 (21) 99884-3834
 raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br   [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

Bacana Rodrigo. Valeu a dica.


Em 30 de julho de 2015 15:16, Rodrigo Della Justina 
rodrigodellajust...@gmail.com escreveu:

 Acredito, que conforme a utilização dos discos níveis de gravação (carga)
 possa diminuir consideravelmente
 a estimativa do ssd.

 Em 30 de julho de 2015 15:15, Rodrigo Della Justina 
 rodrigodellajust...@gmail.com escreveu:

 Realmente Raplhael

 Recomentei a um cliente, e estou utilizando o verificador de vida útil do
 SSD do próprio fabricante.
 SSDLife Pro scandisk. No cliente esta mostrando uma estimativa de 8 anos.

 para Linux:
 https://scottlinux.com/2014/07/15/determine-remaining-ssd-life-in-linux/



 Em 30 de julho de 2015 15:08, Raphael Coutinho rcoutosi...@gmail.com
 escreveu:

 Pelo que vi a vida útil do SSD é bem  inferior. Vi análises citando 2-3
 anos.

 Fiquei meio receoso quanto a isso. Algué utiliza em servidor?
 Em 30/07/2015 13:13, Albino B Neto b...@riseup.net escreveu:

 Em 30 de julho de 2015 12:47, Guimarães Faria Corcete DUTRA, Leandro
 l...@dutras.org escreveu:
  Estou a estudar que tipo de discos utilizar. Você tem alguma
 recomendação, a princípio penso em utilizar um misto de discos SAS 15K e
 SSD para suprir as consultas, já que pelo que li o SSD tem um melhor
 potencial em leitura.
 
  Com tão poucos dados, eu pensaria em fazer um Raid 1 ou 10 só com SSD.

 Ficaria com o RAID 1, discos sendo SSD.

 --
 Albino B Neto
 twitter.com/b1n0anb
 Debian. Freedom to code. Code to freedom! faw
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


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




 --
 *Rodrigo Della Justina *
 Architect Database IBM DB2 - CISS
 Mobile 55 46 8801 6165
 rodrigodellajust...@gmail.com




 --
 *Rodrigo Della Justina *
 Architect Database IBM DB2 - CISS
 Mobile 55 46 8801 6165
 rodrigodellajust...@gmail.com

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




-- 
  [image: DBMax - Intelgências Estratégica] Raphael Coutinho
 +55 (21) 3114-8869 +55 (21) 99884-3834
 raphael.couti...@dbmax.com.br http://www.dbmax.com.br/
www.dbmax.com.br   [image:
Facebook DBMax]
http://www.facebook.com/DBMax.Inteligencia.Estrategica [image:
Twitter DBMax] http://twitter.com/DBMax_IE [image: Blog DBMax]
http://dbmax.com.br/blog/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Raphael Coutinho]

Pelo que vi a vida útil do SSD é bem  inferior. Vi análises citando 2-3
anos.

Fiquei meio receoso quanto a isso. Algué utiliza em servidor?
Em 30/07/2015 13:13, Albino B Neto b...@riseup.net escreveu:

 Em 30 de julho de 2015 12:47, Guimarães Faria Corcete DUTRA, Leandro
 l...@dutras.org escreveu:
  Estou a estudar que tipo de discos utilizar. Você tem alguma
 recomendação, a princípio penso em utilizar um misto de discos SAS 15K e
 SSD para suprir as consultas, já que pelo que li o SSD tem um melhor
 potencial em leitura.
 
  Com tão poucos dados, eu pensaria em fazer um Raid 1 ou 10 só com SSD.

 Ficaria com o RAID 1, discos sendo SSD.

 --
 Albino B Neto
 twitter.com/b1n0anb
 Debian. Freedom to code. Code to freedom! faw
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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