Zac B's questions

Contexto:

Atualmente, executamos o PostgreSQL 8.4 em produção e estamos testando o 9.2 internamente para uma atualização futura. Algumas questões surgiram em relação às datas. Os servidores que executam 8.4 versus 9.2 são idênticos em todos os aspectos, exceto nas versões e configurações do PostgreSQL. Os mesmos dados exatos são armazenados em ambos os conjuntos de servidores; ele é transferido usando pg_dumpe pg_restore.

Em uma parte de nosso banco de dados, armazenamos datas em um campo do tipo timestamp without time zone.

Problema:

Ao acessar as datas desse campo, uma extract(epoch..)requisição retorna resultados bem diferentes dependendo da versão do Postgres, assim:

#On Postgres 8.4. entered_timestamp is a "timestamp without time zone" type column:
SELECT entered_timestamp, extract(epoch from entered_timestamp) AS entered_timestamp from <table row>

 entered_timestamp      | entered_timestamp
 ----------------------------+-------------------
 2012-11-01 06:01:39.699612 |  1351774899.69961

Mas...

#On Postgres 9.2. All tables, schema, and data are identical, the SELECT statement is identical to the previous one:
SELECT entered_timestamp, extract(epoch from entered_timestamp) AS entered_timestamp from <table row>

 entered_timestamp      | entered_timestamp
 ----------------------------+-------------------
 2012-11-01 06:01:39.699612 |  1351749699.69961

Como você pode ver, os timestamps retornados são idênticos, mas os números de época retornados não são; na verdade, eles estão fora por várias horas. As datas do servidor e os fusos horários do Linux em ambos os servidores são idênticos (com uma diferença de um segundo). Os fusos horários do Postgres também são idênticos: a execução SELECT current_setting('timezone')em ambos os servidores também retorna os mesmos dados. A execução SELECT now()em ambos os servidores retorna valores quase idênticos.

Pergunta:

1. Como o comportamento de extract(epoch...)campos do tipo timestamp without time zonemudou entre o PostgreSQL 8.4 e o PostgreSQL 9.2?

2. Por que essa mudança ocorreu?

3. Existe alguma maneira de evitar essa alteração sem alterar meu esquema ou alterar dados anteriores (ou seja, uma correção baseada em configuração)?

TL;DR: O postmaster imparável e inutilizável está sendo gerado quando o Postgres é iniciado logo após a restauração de seu diretório de dados de um backup básico do WAL. Por quê?

Contexto:

Rodamos o postgresql 8.4, no CentOS 6, usando os pacotes PGDG. Temos um script para uso em ambientes de teste do desenvolvedor que restaura um backup noturno do diretório de dados do nosso servidor de produção (criado entre chamadas para pg_start_backupe pg_stop_backup). O script descompacta o arquivo e usa restore_commandpara reaplicar quaisquer WALs que foram gerados durante o tempo em que o backup foi feito na produção.

Geralmente funciona bem e restaura centenas de vezes mais rápido do que uma restauração baseada em SQL de um arquivopg_dump 'ed.

Problema:

Às vezes, depois de descompactar o diretório de dados, o script inicia o postgres executando /etc/init.d/postgresql start(que é um link simbólico para /etc/init.d/postgresql-8.4. Isso o torna um script init previsível para quando eventualmente atualizarmos para 9.*). Ele relata "OK", como em: iniciou corretamente. Então os WALs não são restaurados; ele trava indefinidamente esperando um recovery.donearquivo aparecer.

O que eu tentei:

Quando corri /etc/init.d/postgresql statusdurante o travamento indefinido, o script init relata dead but pid file exists.

Então eu corri ps -ef | grep post. Estranhamente, o processo postmaster e os arquivadores, etc., estavam em execução. Todos os parâmetros de invocação estavam corretos (datadir correto etc etc).

Quando executei psql, ele detectou um postmaster em execução e um banco de dados inicializado postgres, mas não detectou o banco de dados principal - aquele que queremos restaurar por meio do script WAL.

Em seguida, verifiquei as permissões no diretório de dados e tudo parecia OK.

A execução /etc/init.d/postgresql stoprelatou "OK" e matou os processos do arquivador/observador, mas o postmaster continuou em execução.

A mesma coisa aconteceu quando tentei killall -r '*.postmaster*.'.

A única coisa que funcionou para retomar a restauração WAL travada foi um killall -s 3 -r '.*postmaster.*'(Sinal 3 é SIGQUIT) e, em seguida, um arquivo /etc/init.d/postgresql start.

Eu verifiquei pg_startup.loge os arquivos diários pg_logdurante o estado incontrolável, e tudo parecia bem. pg_startup.logregistrou um início bem-sucedido como a última entrada.

Causas Possíveis:

Algumas coisas (acho que menores) não são padrão em nossa configuração.

• Nosso script init é vinculado simbolicamente, como eu disse antes, a um script independente de versão em /etc/init.d/postgresql. Isso aponta para onde queremos. Atualmente aponta para /etc/init.d/postgresql-8.4.

• Nosso postgresql.confarquivo reside /etc/(com um proprietário e grupo do usuário postmaster) e possui um link simbólico para o diretório de dados. Nosso script de restauração do WAL garante que o link simbólico seja recriado antes de tentar iniciar o postgres.

• Recentemente, atualizamos nossa infraestrutura do Postgresql 8.4.11 para 8.4.12. Estamos testando a nova versão para estabilidade. Nossos servidores de produção estão executando 8.4.11. No entanto, estamos extraindo dados deles por meio de pg_dump, depurando-os e, em seguida, 'empacotando-os' para restauração WAL em outro lugar (em 8.4.12), portanto, não estamos restaurando WALs em versões incompatíveis do Postgres.

Pergunta:

Por que está fazendo isso? Uma das possíveis causas listadas abaixo é possivelmente a culpada?

Contexto:

Executamos o Slony 2.0 com Postgres 8.4 em dois servidores CentOS 6 - um mestre e um escravo. Nosso banco de dados tem cerca de 30 GB de tamanho, o que não é incomum, mas temos algumas tabelas com mais de 5 GB cada.

Recentemente, precisávamos reconstruir nosso cluster Slony. Desliguei o Slony, restaurei instantâneos de banco de dados idênticos no master e no slave, configurei meu slony.conf e slon_tools.conf, iniciei os slons, executei slonik_init_cluster | slonik, então slonik_create_set 1 | slonik(só temos um conjunto de replicação) e finalmente slonik_subscribe_set 1 2 | slonik. Tudo parecia bem e pude observar o progresso da assinatura nos logs.

Em seguida, o servidor parou de responder. Reiniciei-o e vi "Pânico do Kernel - não sincronizando: sem memória e sem processos que podem ser eliminados" depois de ter matado tudo o que podia.

O que eu tentei:

Primeiro, eliminei o banco de dados completamente, executei novamente initdbe, em seguida, restaurei os instantâneos idênticos novamente. Mesmo kernel panic. Então estraguei tudo, desinstalei o Postgres e o Slony e os reinstalei. Eu verifiquei novamente todas as nossas configurações baseadas em memória em postgresql.conf, e elas estão todas nos níveis padrão/recomendado (isto shared_buffersé, em 1/4 da RAM etc etc). Executei um VACUUM ANALYZE FULLno banco de dados antes de inicializar o cluster Slony. Mesmo resultado todas as vezes: kernel panic, sem memória.

Não há chance de alterações de configuração aleatórias/manuais terem causado isso: todas as nossas configurações de Postgres e Slony são gerenciadas por Puppet e não são alteradas há meses.

Pergunta:

Por que isso está acontecendo?

Nosso banco de dados cresceu bastante linearmente nos últimos meses (no início do ano era cerca de 23 GB, agora é 30), e todas as outras vezes que tive que reinicializar o cluster Slony nesses mesmos servidores, funcionou multar.

Posso alimentar algum SQL que crie uma visão para o Slony?

Eu tenho algum SQL que faz CREATE OR REPLACE VIEW name_of_viewe assim por diante, passa para slonik_execute_scripte, em seguida, tenta executar slonik_create_setum conjunto Slony temporário contendo apenas essa exibição.

Eu sou rejeitado com ERROR: Slony-I: table "public"."name_of_view" has no primary keyerro. Que eu saiba, as exibições não oferecem suporte a chaves primárias.

Isso significa que não há como, usando os scripts de administração do Slony, adicionar uma exibição à replicação e que devo apenas instalá-la manualmente em todos os membros do meu cluster de replicação?

Usando o PostgreSQL 8.4/CentOS 6: se eu definir o archive_modeparâmetro como onin postgresql.conf, mas na verdade não armazenar os arquivos WAL gerados em nenhum lugar por meio do archive_commandparâmetro, haverá algum impacto no desempenho?

Isso é para testar o potencial de uso do arquivamento WAL em um servidor de produção de alto rendimento: Espero definir archive_modecomo on, e definir archive_commandcomo algo como

echo `date` %f %p >> archive_log.txt

para que eu possa monitorar quantos arquivos WAL seriam criados durante um determinado período de tempo sem realmente copiá-los e correr o risco de saturação de espaço em disco. Isso afetará o desempenho do meu servidor de alguma forma?

Contexto:

Digamos que, ao usar Streaming Replication/Hot Standby em um cluster Postgres 9.1, um nó de standby fica inativo. Ele permanece inativo por um dia, durante o qual ocorre uma grande quantidade de DML no mestre. O recovery.conf do standby não contém uma entrada 'restore_command' (para restauração de arquivos de diário WAL), mas contém uma string 'primary_conninfo' (para replicação de streaming).

Pergunta:

Se eu iniciar o modo de espera novamente após um dia de alterações no mestre. Ele irá "recuperar o atraso" (eventualmente entrará em um estado que espelha o mestre) usando apenas a replicação de streaming? Ou devo habilitar o arquivamento de arquivos WAL e deixá-lo aplicar os arquivos arquivados durante a interrupção para garantir a moeda?

Eu verifiquei o documento de arquivamento/replicação de streaming do WAL aqui e ele diz que você não precisa habilitar o arquivamento do WAL e a replicação de streaming, mas não está claro se o catch-up acontecerá ou não sem o arquivamento do arquivo WAL ativado.

Obrigado!