Re: [pgbr-geral] Streaming replication + Vaccum DB Servidor Remoto
Em 23-05-2011 07:43, gilmarli...@agrovale.com.br escreveu E o mais interessante que ele começa a gerar esta mensagem juntamente e quando o vaccum chega em uma tabela. Testei varias vezes fazendo este processo remotamente e ocorre isto. Já se eu fizer ele em um servidor que esta no mesmo ambiente que o servidor master isto não ocorre. Agradeço novamente qualquer ideia. Gilmar instale o iperf nos dois servidor e execute num servidor: iperf -s no outro: iperf -c xxx.xxx.xxx.xxx onde xxx.xxx.xxx.xxx é o IP do servidor onde o iperf -s está rodando. Dessa forma você vai ter a informação qual a velocidade do link de rádio. Att. ___ 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 + Vaccum DB Servidor Remoto
Olá!Não conhecia esta ferramenta muito fera.bom o resultado deu foi este:[ 3] local 192.168.1.14 port 54700 connected with 192.168.1.29 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 31.6 MBytes 26.5 Mbits/secAgradeço. Em 23-05-2011 07:43, gilmarli...@agrovale.com.br escreveu E o mais interessante que ele começa a gerar esta mensagem juntamente e quando o vaccum chega em uma tabela. Testei varias vezes fazendo este processo remotamente e ocorre isto. Já se eu fizer ele em um servidor que esta no mesmo ambiente que o servidor master isto não ocorre. Agradeço novamente qualquer ideia. Gilmar instale o iperf nos dois servidor e execute num servidor: iperf -s no outro: iperf -c xxx.xxx.xxx.xxx onde xxx.xxx.xxx.xxx é o IP do servidor onde o iperf -s está rodando. Dessa forma você vai ter a informação qual a velocidade do link de rádio. Att. ___ 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 + Vaccum DB Servidor Remoto
Em 23 de maio de 2011 10:48, gilmarli...@agrovale.com.br escreveu: Olá! Não conhecia esta ferramenta muito fera. bom o resultado deu foi este: [ 3] local 192.168.1.14 port 54700 connected with 192.168.1.29 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 31.6 MBytes 26.5 Mbits/sec Me parece que sua rede por rádio é bem rápida. Perguntas: Como está o archive_command do mestre? Como está o recovery.conf do escravo? Mande pra nós se puder. Como estão as permissões do diretório onde gravas o archive? []s Flavio ___ 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 + Vaccum DB Servidor Remoto
Em 23 de maio de 2011 10:48, gilmarli...@agrovale.com.br escreveu: Olá! Não conhecia esta ferramenta muito fera. bom o resultado deu foi este: [ 3] local 192.168.1.14 port 54700 connected with 192.168.1.29 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 31.6 MBytes 26.5 Mbits/sec Me parece que sua rede por rádio é bem rápida.Sim, e uma solução Ubitiqui Full Duplex. (solução muito boa, com custo baixo.) Perguntas: Como está o archive_command do mestre?Não estou usando o archive_command, pois tavo vendo que na versão 9.0 não e mais necessário utilizar. Eu apenas defino estes 3 parametros no postgres.confwal_level = hot_standby max_wal_senders = 1wal_keep_segments = 240 Como está o recovery.conf do escravo? Mande pra nós se puder.standby_mode = 'on'primary_conninfo = 'host=192.168.1.253 port=5573 user=postgres password=SENHA'trigger_file = '/tmp/failover.trg' Como estão as permissões do diretório onde gravas o archive?Dentro o diretório pg_xlog tenho o diretório chamado archive_status onde não e gravado nada, nem no master e nem no slave cujo a permissão e ambos esta:drwx-- 2 postgres postgresJá dentro do diretório pg_xlog posso muitos logs gerado pelo postgres, exemplo abaixo.000100100070Estes foi criado no master e foi replicado para o slave, o mesmo acontece com algums outros.Agradeço ajuda []s Flavio ___ ___ 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 + Vaccum DB Servidor Remoto
Me parece que sua rede por rádio é bem rápida. Sim, e uma solução Ubitiqui Full Duplex. (solução muito boa, com custo baixo.) Perguntas: Como está o archive_command do mestre? Não estou usando o archive_command, pois tavo vendo que na versão 9.0 não e mais necessário utilizar. Eu apenas defino estes 3 parametros no postgres.conf Como assim não é mais necessário utilizar? Onde é que leste isso? O archive_command não é necessário pro streaming, mas ele ainda é necessário para o backup! E também para servidores escravos que vão muito atrás do mestre, o seu caso. wal_level = hot_standby max_wal_senders = 1 wal_keep_segments = 240 Se você não faz archiving, você precisa de mais max_wal_senders. Isso causa o erro que você está vendo. Incremente este valor. Durante vacuum, a quantidade de dados modificadas é muito grande. Se você fizesse archiving, mandando as cópias para o servidor escravo, poderia não ter que se preocupar com isso, como o Euler já nos disse aqui. Como está o recovery.conf do escravo? Mande pra nós se puder. standby_mode = 'on' primary_conninfo = 'host=192.168.1.253 port=5573 user=postgres password=SENHA' trigger_file = '/tmp/failover.trg' Se você tivesse archiving em algum lugar, poderia ter uma linha: restore_command = 'cp /dir/archiving/%f %p' ou restore_command = 'scp IP.SERV.MESTRE:/dir/archiving/%f %p' O erro que você vê não apareceria nunca mais. Como estão as permissões do diretório onde gravas o archive? Dentro o diretório pg_xlog tenho o diretório chamado archive_status onde não e gravado nada, nem no master e nem no slave cujo a permissão e ambos esta: drwx-- 2 postgres postgres Ok. Já dentro do diretório pg_xlog posso muitos logs gerado pelo postgres, exemplo abaixo. 000100100070 Estes foi criado no master e foi replicado para o slave, o mesmo acontece com algums outros. O erro que você está vendo significa que o servidor slave está precisando do arquivo: 1) ainda no mestre, conforme wal_keep_segments OU; 2) no diretório de archiving, para recuperação via restore_command. A presença do arquivo no slave significa que o slave criou o arquivo e, agora, precisa dos dados via streaming ou restore_command para fazer um restart point. Cheque se, na exata hora que o erro aparece, se o *mestre* ainda tem o arquivo. Se não, ressincronize tudo e aumente wal_keep_segments. Minha sugestão é usar archive_command mandando os logs pro escravo. No mínimo, mantenha uma cópia no mestre acessível pelo escravo. É o que tenho em todos os meus 9.0 em hot-standby (já são 5 em produção). []s Flavio ___ 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 + Vaccum DB Servidor Remoto
Entendi.O diretório para arquivar os logs poderia ser?pg_xlog/archive_statusAgradeço novamente Me parece que sua rede por rádio é bem rápida. Sim, e uma solução Ubitiqui Full Duplex. (solução muito boa, com custo baixo.) Perguntas: Como está o archive_command do mestre? Não estou usando o archive_command, pois tavo vendo que na versão 9.0 não e mais necessário utilizar. Eu apenas defino estes 3 parametros no postgres.conf Como assim não é mais necessário utilizar? Onde é que leste isso? O archive_command não é necessário pro streaming, mas ele ainda é necessário para o backup! E também para servidores escravos que vão muito atrás do mestre, o seu caso. wal_level = hot_standby max_wal_senders = 1 wal_keep_segments = 240 Se você não faz archiving, você precisa de mais max_wal_senders. Isso causa o erro que você está vendo. Incremente este valor. Durante vacuum, a quantidade de dados modificadas é muito grande. Se você fizesse archiving, mandando as cópias para o servidor escravo, poderia não ter que se preocupar com isso, como o Euler já nos disse aqui. Como está o recovery.conf do escravo? Mande pra nós se puder. standby_mode = 'on' primary_conninfo = 'host=192.168.1.253 port=5573 user=postgres password=SENHA' trigger_file = '/tmp/failover.trg' Se você tivesse archiving em algum lugar, poderia ter uma linha: restore_command = 'cp /dir/archiving/%f %p' ou restore_command = 'scp IP.SERV.MESTRE:/dir/archiving/%f %p' O erro que você vê não apareceria nunca mais. Como estão as permissões do diretório onde gravas o archive?Dentro o diretório pg_xlog tenho o diretório chamado archive_status onde não e gravado nada, nem no master e nem no slave cujo a permissão e ambos esta: drwx-- 2 postgres postgres Ok. Já dentro do diretório pg_xlog posso muitos logs gerado pelo postgres, exemplo abaixo. 000100100070 Estes foi criado no master e foi replicado para o slave, o mesmo acontece com algums outros. O erro que você está vendo significa que o servidor slave está precisando do arquivo: 1) ainda no mestre, conforme wal_keep_segments OU; 2) no diretório de archiving, para recuperação via restore_command. A presença do arquivo no slave significa que o slave criou o arquivo e, agora, precisa dos dados via streaming ou restore_command para fazer um restart point. Cheque se, na exata hora que o erro aparece, se o *mestre* ainda tem o arquivo. Se não, ressincronize tudo e aumente wal_keep_segments. Minha sugestão é usar archive_command mandando os logs pro escravo. No mínimo, mantenha uma cópia no mestre acessível pelo escravo. É o que tenho em todos os meus 9.0 em hot-standby (já são 5 em produção). []s Flavio ___ 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] Streaming replication + Vaccum DB Servidor Remoto
Em 23 de maio de 2011 12:19, gilmarli...@agrovale.com.br escreveu: Entendi. O diretório para arquivar os logs poderia ser? pg_xlog/archive_status Não. Use um diretório fora do cluster (aka $PGDATA). []s ___ 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 + Vaccum DB Servidor Remoto
Pode ser dentro dentro do data? exemplo crio um diretório chamado pg_archives ?Agradeço novamente Em 23 de maio de 2011 12:19, gilmarli...@agrovale.com.br escreveu: Entendi. O diretório para arquivar os logs poderia ser? pg_xlog/archive_status Não. Use um diretório fora do cluster (aka $PGDATA). []s ___ 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 + Vaccum DB Servidor Remoto
Você tambem define o archive_mode = on Agradeço novamente Em 23 de maio de 2011 12:19, gilmarli...@agrovale.com.br escreveu: Entendi. O diretório para arquivar os logs poderia ser? pg_xlog/archive_status Não. Use um diretório fora do cluster (aka $PGDATA). []s ___ 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 + Vaccum DB Servidor Remoto
Em 23 de maio de 2011 14:47, gilmarli...@agrovale.com.br escreveu: Você tambem define o archive_mode = on Agradeço novamente respondendo 2 em 1: 1) Não faça archive dentro do diretório de dados do PostgreSQL, em lugar algum. Você vai dificultar seu backup de base e ainda por cima pode fazer uma baita confusão na hora de mandar seus dados pro servidor remoto. Faça seu archive em outro diretório qualquer, à sua escolha. 2) Sim, você é obrigado a fazer archive_mode=on senão o PostgreSQL vai emitir um erro dizendo que você colocou um archive_command e não ligou o archive_mode. []s Flavio ___ 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 + Vaccum DB Servidor Remoto
Blz agradeçoFlávio comecei a realizar algums testes.Realmente o primeiro teste que fiz foi subir o wal_keep_segments = 5000 e por enquanto fiz o vaccum várias vezes e não deu o erro antes informado.Depois de fazer mais testes irei fazer esta maneira que você me informou.Agradeço a todos que me ajudaram. Em 23 de maio de 2011 14:47, gilmarli...@agrovale.com.br escreveu: Você tambem define o archive_mode = on Agradeço novamente respondendo 2 em 1: 1) Não faça archive dentro do diretório de dados do PostgreSQL, em lugar algum. Você vai dificultar seu backup de base e ainda por cima pode fazer uma baita confusão na hora de mandar seus dados pro servidor remoto. Faça seu archive em outro diretório qualquer, à sua escolha. 2) Sim, você é obrigado a fazer archive_mode=on senão o PostgreSQL vai emitir um erro dizendo que você colocou um archive_command e não ligou o archive_mode. []s Flavio ___ 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] Streaming replication + Vaccum DB Servidor Remoto
Em 23 de maio de 2011 17:51, gilmarli...@agrovale.com.br escreveu: Blz agradeço Flávio comecei a realizar algums testes. Realmente o primeiro teste que fiz foi subir o wal_keep_segments = 5000 e por enquanto fiz o vaccum várias vezes e não deu o erro antes informado. Depois de fazer mais testes irei fazer esta maneira que você me informou. Agradeço a todos que me ajudaram. Entendo que deva ter funcionado mesmo, só cuidado com esses 5000 que você colocou. Seu pg_xlog vai inchar em 16MB * 5000 = 78 GB !!! Que tal um valorzinho mais razoável? Você continua insistindo na solução mais fácil. Setar um archive_mode e archive_command pra guardar os logs de transação e tê-los acessíveis pelo escravo é muito mais vantajoso, além do que, você conseguirá fazer backups decentes. []s Flavio ___ 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 + Vaccum DB Servidor Remoto
Entendi o que você descreveu.Inclusive se retornar uma copia com este valor habilitado no postgres.conf ai sim o pg_xlog vira um monstro.Irei tambem fazer da maneira que você sugeriu.Por enquanto to fazendo testes. Em 23 de maio de 2011 17:51, gilmarli...@agrovale.com.br escreveu: Blz agradeço Flávio comecei a realizar algums testes. Realmente o primeiro teste que fiz foi subir o wal_keep_segments = 5000 e por enquanto fiz o vaccum várias vezes e não deu o erro antes informado.Depois de fazer mais testes irei fazer esta maneira que você me informou. Agradeço a todos que me ajudaram. Entendo que deva ter funcionado mesmo, só cuidado com esses 5000 que você colocou. Seu pg_xlog vai inchar em 16MB * 5000 = 78 GB !!! Que tal um valorzinho mais razoável? Você continua insistindo na solução mais fácil. Setar um archive_mode e archive_command pra guardar os logs de transação e tê-los acessíveis pelo escravo é muito mais vantajoso, além do que, você conseguirá fazer backups decentes. []s Flavio ___ 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
