[pgbr-geral] Limite de procedimentos dentro de uma transação
Pessoal, Dentro de um processo de atualização da aplicação, considerando o seguinte cenário: BEGIN; INSERT UPDATE... CREATE... INSERT... COMMIT ou ROLLBACK; Existe algum limite de procedimentos dentro de uma transação? Considerando que ninguém estará acessando o banco, posso ter algum problema em relação ao tempo que a transação ficará aberta? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Limite de procedimentos dentro de uma transação
On 07-05-2015 20:29, Danilo Silva wrote: Existe algum limite de procedimentos dentro de uma transação? 2^32-2 comandos que escrevem (como por exemplo, INSERT, UPDATE e DELETE). Comandos SELECT não entram nesta contagem. Considerando que ninguém estará acessando o banco, posso ter algum problema em relação ao tempo que a transação ficará aberta? Transações longas não são recomendadas principalmente se o seu agrupamento de bancos de dados consumir muitos (bilhões) id de transação durante o tempo que a transação permanecer aberta. Normalmente isso pode levar meses ou anos. Para se ter uma ideia, um sistema com 1000 transações/s, 100 transações/s e 10 transações/s levariam, respectivamente, 46 dias, 1 ano 3 meses e 12 anos 8 meses para parar o postgres por falta de id de transação. -- 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
Re: [pgbr-geral] Prepare transaction
On 07-05-2015 19:39, Danilo Silva wrote: Gostaria de uma ajuda sobre o comando PREPARE TRANSACTION, para quê ele serve? É um comando para preparar uma transação do tipo two-phase commit (2PC) [1]. Você já leu a documentação [2]? O que não entendeu? Recomendo ler sobre banco de dados distribuídos (para entender o 2PC), se ainda não conhece o conceito. [1] http://en.wikipedia.org/wiki/Two-phase_commit_protocol [2] http://www.postgresql.org/docs/9.4/static/sql-prepare-transaction.html -- 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
Re: [pgbr-geral] PG_Basebackup não gera timeline history
2015-05-06 15:56 GMT-03:00 André Ormenese aormen...@gmail.com: gerei o pg_upgrade a partir do master da versão 9.3.4. Subi o banco na versão 9.4.1 como master. A partir deste banco (master) na versão 9.4.1, estou gerando o pg_basebackup e tentando subir um slave. Me parece que existe um bug no pg_basebackup que este não copia os arquivos .history, assumindo não ser necessário. Ajudei a resolver um caso exatamente igual ao seu esses dias no IRC. Não sei se foi reportado à -bugs ainda, mas provavelmente terá de ser, vou pesquisar isso. A solução no caso foi simplesmente executar o touch do arquivo .history na pg_xlog do primário. Irá resolver o problema de sincronização entre o primário e secundário, mas ficou uma dúvida se isso tem implicações futuras negativas (fiquei de analisar o código pra ver, mas não tive tempo ainda). Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] FATAL incorrect checksum in control file - restaurar em outro linux
Bom dia pessoal! Meu servidor de banco de dados deu problema no HD, ficava dando erro de IO, era Ubuntu 14.04LTS amd64. Copiei o diretorio DATA do postgres para outro linux, Debian 7.5 i386, compilei os mesmos fontes e quando vou startar o postgresql recebo a seguinte mensagem: *FATAL: incorrect checksum in control file* Segundo li na net, é pq mudou o SO e arctetura. De qualquer forma, gostaria de rodar o mesmo no SO atual. Meu BD é pequeno, 500MB, porem tem uns sistemas muito importantes. Tem como eu restaurar o DATA sem reinstalar o Ubuntu? Desde ja, obrigado. Abraços! -- #!/bin/bash name='Moises P. Sena' mail='moisespsena' mail=$m...@gmail.com echo $name $mail init 0 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Limite de procedimentos dentro de uma transação
Já passei por problemas de executar muitos comandos dentro de uma mesma transação, mas era em situações de atualização automatizada de clientes a 1 ~ 2 anos sem receber atualização de sistema. Devido a grande quantidade de registros que existiam na base de dados era impossível realizar uma atualização completa apenas com uma transação, visto que era modificado estrutura de dados, executado vários updates, inserts, creates, alters, copiados registros de uma estrutura de dados pra uma nova, chegava num certo momento que ficava tudo muito lento, a memória do servidor fica socada e travava tudo... enfim, nessa situação mesmo sem ninguém mais utilizando a base de dados, era impossível executar apenas numa transação, tinha que ir executando em partes. Como já havia previsto isso, projetei o atualizador para que pudesse executar os script's de atualização em transações menores quando ocorresse uma situação dessas. Mas era necessário muitas e muitas operações para chegar a este ponto. Em 7 de maio de 2015 20:29, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, Dentro de um processo de atualização da aplicação, considerando o seguinte cenário: BEGIN; INSERT UPDATE... CREATE... INSERT... COMMIT ou ROLLBACK; Existe algum limite de procedimentos dentro de uma transação? Considerando que ninguém estará acessando o banco, posso ter algum problema em relação ao tempo que a transação ficará aberta? []s Danilo ___ 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] Limite de procedimentos dentro de uma transação
2015-05-08 0:06 GMT-03:00 Euler Taveira eu...@timbira.com.br: On 07-05-2015 23:36, Danilo Silva wrote: Certo, se eu entendi, neste caso um insert gera um id, um update, outro id, um novo insert, outro id, e assim por diante? É o que eu tentei^H^H^H^H^H^H escrevi, não? Euler, eu não entendi a sua resposta de agora, você refere-se a sua resposta anterior, onde fala sobre os 2^32-2 ? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Limite de procedimentos dentro de uma transação
Em 7 de maio de 2015 22:35, Euler Taveira eu...@timbira.com.br escreveu: On 07-05-2015 20:29, Danilo Silva wrote: Existe algum limite de procedimentos dentro de uma transação? 2^32-2 comandos que escrevem (como por exemplo, INSERT, UPDATE e DELETE). Comandos SELECT não entram nesta contagem. Considerando que ninguém estará acessando o banco, posso ter algum problema em relação ao tempo que a transação ficará aberta? Transações longas não são recomendadas principalmente se o seu agrupamento de bancos de dados consumir muitos (bilhões) id de transação durante o tempo que a transação permanecer aberta. Normalmente isso pode levar meses ou anos. Certo, se eu entendi, neste caso um insert gera um id, um update, outro id, um novo insert, outro id, e assim por diante? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] checkpoint_segments - master
Ops! Outro assunto ficou melhor mesmo... :) On 07-05-2015 14:19, Matheus de Oliveira wrote: Novo assunto. Melhor... :) 2015-05-07 13:46 GMT-03:00 Edson F. Lidorio ed...@openmailbox.org mailto:ed...@openmailbox.org: 2015-05-07 12:45:25 BRT [3254-1] [desconhecido]@[desconhecido] LOG: pacote de inicialização incompleto 2015-05-07 12:46:48 BRT [3248-1] LOG: pontos de controle estão ocorrendo frequentemente (28 segundos) 2015-05-07 12:46:48 BRT [3248-2] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. [...] 2015-05-07 12:47:33 BRT [3248-5] LOG: pontos de controle estão ocorrendo frequentemente (27 segundos) 2015-05-07 12:47:33 BRT [3248-6] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. Esse parâmetro checkpoint_segments estava desabilitado, ai eu ativei e aumentei também, mais mesmo assim fica pedindo para aumentar. Valor atual: checkpoint_segments = 10 Como ajustar esse valor para ficar com um valor ideal? Você pode aumentar mais esse valor, o ideal é que o checkpoint_segments seja o suficiente para que a maioria das requisições sejam feitas por tempo (uma forma de analisar é pela view pg_stat_bgwriter, outra é pelo log habilitando o log_checkpoints). O efeito causado por aumentar esse valor é aumento no espaço ocupado no diretório pg_xlog, o que não deve ser um problema, em geral. O número de segmentos (sendo 16MB cada um) é de aproximadamente: (2 + checkpoint_completion_target) * checkpoint_segments. Agora, se acontecer apenas alguns checkpoints imediatos, em picos de alta atividade, não é um problema tão grave. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres http://www.dextra.com.br/postgres/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral No meu caso, apenas alguns horário que tenho bastante transações, na maior parte do tempo é tranquilo: Segue resultado da pg_stat_bgwriter: postgres=# table pg_stat_bgwriter; -[ RECORD 1 ]-+-- checkpoints_timed | 503 checkpoints_req | 180 checkpoint_write_time | 2247739 checkpoint_sync_time | 602931 buffers_checkpoint| 193432 buffers_clean | 6 maxwritten_clean | 0 buffers_backend | 2286448 buffers_backend_fsync | 0 buffers_alloc | 92711 stats_reset | 2015-04-30 23:57:29.423976-03 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Limite de procedimentos dentro de uma transação
On 07-05-2015 23:36, Danilo Silva wrote: Certo, se eu entendi, neste caso um insert gera um id, um update, outro id, um novo insert, outro id, e assim por diante? É o que eu tentei^H^H^H^H^H^H escrevi, não? -- 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
Re: [pgbr-geral] PG_Basebackup não gera timeline history
Li, ontem, numa outra discussão ( http://postgresql.nabble.com/Missing-timeline-history-file-after-execution-of-pg-upgrade-td5826326.html )que a solução seria essa mesmo. Acabei gerando o arquivo .history no pg_xlog do master e o problema sumiu. Só para constar... todo o problema surgiu pq eu estava tentando gerar meu slave através do backup feito no master. Agora mudei a forma de fazer isso. Estou gerando o pg_basebackup direto na máquina slave, apontando o host do master, e gerando como plain, não mais como tar. Depois e só copiar os arquivos de configuração e recovery, e o slave sobe, como read only, sem problema algum. O tempo para recriar meu slave diminuiu consideravelmente. Obrigado Matheus. Em 7 de maio de 2015 09:44, Matheus de Oliveira matioli.math...@gmail.com escreveu: 2015-05-06 15:56 GMT-03:00 André Ormenese aormen...@gmail.com: gerei o pg_upgrade a partir do master da versão 9.3.4. Subi o banco na versão 9.4.1 como master. A partir deste banco (master) na versão 9.4.1, estou gerando o pg_basebackup e tentando subir um slave. Me parece que existe um bug no pg_basebackup que este não copia os arquivos .history, assumindo não ser necessário. Ajudei a resolver um caso exatamente igual ao seu esses dias no IRC. Não sei se foi reportado à -bugs ainda, mas provavelmente terá de ser, vou pesquisar isso. A solução no caso foi simplesmente executar o touch do arquivo .history na pg_xlog do primário. Irá resolver o problema de sincronização entre o primário e secundário, mas ficou uma dúvida se isso tem implicações futuras negativas (fiquei de analisar o código pra ver, mas não tive tempo ainda). Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ 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] FATAL incorrect checksum in control file - restaurar em outro linux
Em 7 de maio de 2015 09:44, Moisés P. Sena moisesps...@gmail.com escreveu: Meu servidor de banco de dados deu problema no HD, ficava dando erro de IO, era Ubuntu 14.04LTS amd64. Copiei o diretorio DATA do postgres para outro linux, Debian 7.5 i386 Por que i386? Não é compatível com os dados AMD64. compilei os mesmos fontes Por que não usar o binário do Debian AMD64? Segundo li na net, é pq mudou o SO e arctetura. Só arquitetura, o SO é irrelevante. De qualquer forma, gostaria de rodar o mesmo no SO atual. Sem problemas, desde que seja na mesma arquitetura. Tem como eu restaurar o DATA sem reinstalar o Ubuntu? Tem, instale o Debian AMD64. -- 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
[pgbr-geral] Prepare transaction
Pessoal, Gostaria de uma ajuda sobre o comando PREPARE TRANSACTION, para quê ele serve? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Acesso base
Boa noite pessoal; Quando tento acessar uma aplicação web java que esta em servidor Tomcat e uma base de dados rodando no Postgres que está no mesmo servidor da aplicação web. Quando executo a aplicação me é retornado o seguinte erro: Erro ao estabelecer conexão com o Banco de Dados. Por favor verifique se o mesmo está ativo e acessível pelo servidor Biblivre. Ocorreu um erro de aplicação durante a execução deste pedido. Os detalhes deste erro não podem ser visualizados a partir de um computador remoto (por medidas de segurança), mas podem ser vistos através de um navegador executado a partir do computador onde o Biblivre está instalado. O servidor está ativo, porque tenho outra base no mesmo servidor e que está acessível e é acessada por outra aplicação. Pode ser um problema de configuração no Postgres? Att., Walison ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Acesso base
Por favor, evite mensagens formatadas, prefira texto simples e siga a RFC 1855 e correlatas. Tua mensagem ficou confusa com os erros de formatação. Em 7 de maio de 2015 18:00, Walison Jose de deus walison.joseded...@gmail.com escreveu: Erro ao estabelecer conexão com o Banco de Dados. Por favor verifique se o mesmo está ativo e acessível pelo servidor Biblivre. Siga as instruções. Por exemplo, teste com o usuário do tal servidor se o psql consegue acesso à base. Ocorreu um erro de aplicação durante a execução deste pedido. Os detalhes deste erro não podem ser visualizados a partir de um computador remoto (por medidas de segurança), mas podem ser vistos através de um navegador executado a partir do computador onde o Biblivre está instalado. E qual o resltado deste teste? O servidor está ativo, porque tenho outra base no mesmo servidor e que está acessível e é acessada por outra aplicação. Pode ser um problema de configuração no Postgres? Não vejo como. -- 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
Re: [pgbr-geral] restore_command standby
On 07-05-2015 09:07, Matheus de Oliveira wrote: 2015-05-06 23:14 GMT-03:00 Edson F. Lidorio ed...@openmailbox.org mailto:ed...@openmailbox.org: standby_mode=on primary_conninfo='host=192.168.0.100 user=replicador application_name= jessie-stby' trigger_file='/tmp/pgtrigger' restore_command = 'scp 192.168.0.100:/var/pg_archive/%f /var/lib/postgresql/9.4/main/%p' Só que estou com dúvidas no log de erros do servidor secundário: 2015-05-06 23:02:41 BRT [594-37] LOG: arquivo de log restaurado 000100010028 do arquivador [...] 2015-05-06 23:02:52 BRT [594-44] LOG: arquivo de log restaurado 00010001002F do arquivador scp: /var/pg_archive/000100010030: No such file or directory 2015-05-06 23:02:55 BRT [1036-1] LOG: iniciado fluxo de WAL do principal em 1/3000 na linha do tempo 1 É normal ele procurar esse arquivo e depois sincronizar novamente? scp: /var/pg_archive/000100010030: No such file or directory Sim é normal, ele busca todos arquivos, até os que não existem, somente quando o comando chamado pelo restore_command apresenta erro que o PostgreSQL identifica que não tem ainda este arquivo disponível no diretório, e então deixa de fazer archive recovery (definido pelo restore_command) e conecta no primário para entrar em streaming replication (definido pelo primary_conninfo), depois disso irá permanecer em streaming o tempo todo. A não ser que perca a sincronia, então voltará ao archive recovery até sincronizar todos os arquivos, quando essa mesma mensagem aparecer, e iniciar streaming replication novamente, e assim por diante. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres http://www.dextra.com.br/postgres/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Excelente explicação Matheus! Estava olhando também o log do master e esta assim: 015-05-07 12:45:24 BRT [2946-24] LOG: sistema de banco de dados está desligado 2015-05-07 12:45:25 BRT [3247-1] LOG: sistema de banco de dados foi desligado em 2015-05-07 12:45:24 BRT 2015-05-07 12:45:25 BRT [3251-1] LOG: inicializador do autovacuum foi iniciado 2015-05-07 12:45:25 BRT [3246-1] LOG: sistema de banco de dados está pronto para aceitar conexões 2015-05-07 12:45:25 BRT [3254-1] [desconhecido]@[desconhecido] LOG: pacote de inicialização incompleto 2015-05-07 12:46:48 BRT [3248-1] LOG: pontos de controle estão ocorrendo frequentemente (28 segundos) 2015-05-07 12:46:48 BRT [3248-2] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. 2015-05-07 12:47:06 BRT [3248-3] LOG: pontos de controle estão ocorrendo frequentemente (18 segundos) 2015-05-07 12:47:06 BRT [3248-4] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. 2015-05-07 12:47:28 BRT [3273-1] replicador@[desconhecido] LOG: erro de SSL: bad length 2015-05-07 12:47:31 BRT [3273-2] replicador@[desconhecido] LOG: não pôde receber dados do cliente: Conexão fechada pela outra ponta 2015-05-07 12:47:31 BRT [3273-3] replicador@[desconhecido] LOG: EOF inesperado na conexão do servidor em espera 2015-05-07 12:47:33 BRT [3248-5] LOG: pontos de controle estão ocorrendo frequentemente (27 segundos) 2015-05-07 12:47:33 BRT [3248-6] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. Esse parâmetro checkpoint_segments estava desabilitado, ai eu ativei e aumentei também, mais mesmo assim fica pedindo para aumentar. Como ajustar esse valor para ficar com um valor ideal? esta assim: checkpoint_segments = 10 -- Edson ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] restore_command standby
2015-05-07 12:54 GMT-03:00 Edson F. Lidorio ed...@openmailbox.org: Estava olhando também o log do master e esta assim: Este é um assunto diferente. Acho melhor iniciar outra mensagem para não bagunçar o histórico da lista. Ok? Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] checkpoint_segments - master
Boa tarde, Estava olhando o log do do servidor master e esta assim: 015-05-07 12:45:24 BRT [2946-24] LOG: sistema de banco de dados está desligado 2015-05-07 12:45:25 BRT [3247-1] LOG: sistema de banco de dados foi desligado em 2015-05-07 12:45:24 BRT 2015-05-07 12:45:25 BRT [3251-1] LOG: inicializador do autovacuum foi iniciado 2015-05-07 12:45:25 BRT [3246-1] LOG: sistema de banco de dados está pronto para aceitar conexões 2015-05-07 12:45:25 BRT [3254-1] [desconhecido]@[desconhecido] LOG: pacote de inicialização incompleto 2015-05-07 12:46:48 BRT [3248-1] LOG: pontos de controle estão ocorrendo frequentemente (28 segundos) 2015-05-07 12:46:48 BRT [3248-2] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. 2015-05-07 12:47:06 BRT [3248-3] LOG: pontos de controle estão ocorrendo frequentemente (18 segundos) 2015-05-07 12:47:06 BRT [3248-4] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. 2015-05-07 12:47:28 BRT [3273-1] replicador@[desconhecido] LOG: erro de SSL: bad length 2015-05-07 12:47:31 BRT [3273-2] replicador@[desconhecido] LOG: não pôde receber dados do cliente: Conexão fechada pela outra ponta 2015-05-07 12:47:31 BRT [3273-3] replicador@[desconhecido] LOG: EOF inesperado na conexão do servidor em espera 2015-05-07 12:47:33 BRT [3248-5] LOG: pontos de controle estão ocorrendo frequentemente (27 segundos) 2015-05-07 12:47:33 BRT [3248-6] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. Esse parâmetro checkpoint_segments estava desabilitado, ai eu ativei e aumentei também, mais mesmo assim fica pedindo para aumentar. Valor atual: checkpoint_segments = 10 Como ajustar esse valor para ficar com um valor ideal? -- Edson ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] restore_command standby
2015-05-06 23:14 GMT-03:00 Edson F. Lidorio ed...@openmailbox.org: standby_mode=on primary_conninfo='host=192.168.0.100 user=replicador application_name= jessie-stby' trigger_file='/tmp/pgtrigger' restore_command = 'scp 192.168.0.100:/var/pg_archive/%f /var/lib/postgresql/9.4/main/%p' Só que estou com dúvidas no log de erros do servidor secundário: 2015-05-06 23:02:41 BRT [594-37] LOG: arquivo de log restaurado 000100010028 do arquivador [...] 2015-05-06 23:02:52 BRT [594-44] LOG: arquivo de log restaurado 00010001002F do arquivador scp: /var/pg_archive/000100010030: No such file or directory 2015-05-06 23:02:55 BRT [1036-1] LOG: iniciado fluxo de WAL do principal em 1/3000 na linha do tempo 1 É normal ele procurar esse arquivo e depois sincronizar novamente? scp: /var/pg_archive/000100010030: No such file or directory Sim é normal, ele busca todos arquivos, até os que não existem, somente quando o comando chamado pelo restore_command apresenta erro que o PostgreSQL identifica que não tem ainda este arquivo disponível no diretório, e então deixa de fazer archive recovery (definido pelo restore_command) e conecta no primário para entrar em streaming replication (definido pelo primary_conninfo), depois disso irá permanecer em streaming o tempo todo. A não ser que perca a sincronia, então voltará ao archive recovery até sincronizar todos os arquivos, quando essa mesma mensagem aparecer, e iniciar streaming replication novamente, e assim por diante. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] FATAL incorrect checksum in control file - restaurar em outro linux
2015-05-07 9:44 GMT-03:00 Moisés P. Sena moisesps...@gmail.com: Meu servidor de banco de dados deu problema no HD, ficava dando erro de IO, era Ubuntu 14.04LTS amd64. Copiei o diretorio DATA do postgres para outro linux, Debian 7.5 i386, compilei os mesmos fontes e quando vou startar o postgresql recebo a seguinte mensagem: *FATAL: incorrect checksum in control file* Segundo li na net, é pq mudou o SO e arctetura. Exatamente. Não é possível mover um diretório de dados de 64bits para 32bits e vice-versa. Por isso também não é possível ter um primário e secundário (standby) em arquiteturas diferentes. De qualquer forma, gostaria de rodar o mesmo no SO atual. Meu BD é pequeno, 500MB, porem tem uns sistemas muito importantes. Tem como eu restaurar o DATA sem reinstalar o Ubuntu? Não. Você vai precisar de uma arquitetura compatível. Com um banco tão pequeno você pode até subir uma VM, fazer um dump e restaurar. Mas fica a dúvida se usar um SO 32bits para servidor é uma boa ideia, parece que você está regredindo aqui. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] checkpoint_segments - master
Novo assunto. Melhor... :) 2015-05-07 13:46 GMT-03:00 Edson F. Lidorio ed...@openmailbox.org: 2015-05-07 12:45:25 BRT [3254-1] [desconhecido]@[desconhecido] LOG: pacote de inicialização incompleto 2015-05-07 12:46:48 BRT [3248-1] LOG: pontos de controle estão ocorrendo frequentemente (28 segundos) 2015-05-07 12:46:48 BRT [3248-2] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. [...] 2015-05-07 12:47:33 BRT [3248-5] LOG: pontos de controle estão ocorrendo frequentemente (27 segundos) 2015-05-07 12:47:33 BRT [3248-6] DICA: Considere aumentar o parâmetro de configuração checkpoint_segments. Esse parâmetro checkpoint_segments estava desabilitado, ai eu ativei e aumentei também, mais mesmo assim fica pedindo para aumentar. Valor atual: checkpoint_segments = 10 Como ajustar esse valor para ficar com um valor ideal? Você pode aumentar mais esse valor, o ideal é que o checkpoint_segments seja o suficiente para que a maioria das requisições sejam feitas por tempo (uma forma de analisar é pela view pg_stat_bgwriter, outra é pelo log habilitando o log_checkpoints). O efeito causado por aumentar esse valor é aumento no espaço ocupado no diretório pg_xlog, o que não deve ser um problema, em geral. O número de segmentos (sendo 16MB cada um) é de aproximadamente: (2 + checkpoint_completion_target) * checkpoint_segments. Agora, se acontecer apenas alguns checkpoints imediatos, em picos de alta atividade, não é um problema tão grave. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
