KSletmoe's questions

Imagine que eu tenho 3 bancos de dados PostgreSQL 9.3 (A, B e C) configurados em um cenário de replicação de streaming em cascata (ou seja, NÃO estou enviando arquivos WAL manualmente, estou fazendo com que o Postgres os envie por TCP internamente) assim:

A --> B
      |
      V
      C

onde A é o mestre de replicação para B e B é o mestre de replicação para C.

Se B falhar (fica offline, mas não faz failover ) e eu preciso fazer C usar A como mestre de replicação o mais rápido possível, é seguro pular a reconstrução de C de A e apenas configurar A como mestre de replicação de C? Eu faria isso desativando o serviço Postgres em C, modificando o host mestre no arquivo replication.conf em C para apontar para A e, em seguida, iniciando o serviço Postgres em C. Fiz isso na prática e C replica fora de A sem nenhuma perda de dados em meus testes, mas há alguns casos em que isso pode resultar em corrupção de dados em C?

Intuitivamente, esta deve ser uma operação segura. Como nem B nem C fazem um failover, eles permanecerão na mesma linha do tempo de A e, como o novo mestre para C é "upstream" do mestre anterior, C nunca pode estar à frente da posição WAL do novo mestre.

Pergunta de acompanhamento (a ser respondida se a operação descrita anteriormente for considerada "segura"): Imagine que eu execute as etapas acima, B volte a ficar online, reconstrua-o a partir de A e inicie a replicação de streaming binário de A, de modo que agora tenho o seguinte cenário:

A --> B 
|
V
C

onde A é o mestre de replicação para B e C.

Quero fazer com que B se torne o mestre de replicação de C novamente e, como antes, quero minimizar o tempo de inatividade de C. Posso interromper o serviço Postgres em C, garantir que a posição de reprodução do WAL em B esteja mais adiante do que a de C (esperando que B alcance C se C estiver "à frente" de B na reprodução do WAL) e, em seguida, alterne a replicação host mestre para C apontar para B no arquivo recovery.conf e iniciar o serviço Postgres?

Mais uma vez, fiz isso na prática e parece funcionar, mas quero ter certeza de que não há cenários que resultem em corrupção de dados em C. Nesse segundo caso, suponha que a replicação de A para B seja verificado que está funcionando corretamente quando o Postgres em C está desligado (se a replicação de A para B for interrompida enquanto C ainda estiver replicando de A, pode haver divergência entre os bancos de dados de C e B, o que obviamente causará problemas). Esta é uma operação segura?

Estou tentando configurar o PostgreSQL 9.3 em uma caixa Centos 6.6 para manter os arquivos de configuração (postgresql.conf, pg_hba.conf, pg_ident.conf) em um diretório diferente do diretório de dados. De acordo com a documentação , devo ser capaz de definir a variável PGDATA para o diretório que contém o postgresql.conf e, em seguida, especificar o data_directory de dentro do postgresql.conf para apontar para o diretório que contém meus dados.

Eu instalei o PostgreSQL 9.3 através destas instruções .

Etapas que segui para configurar o Postgres ( /dataé uma partição diferente do sistema operacional):

1. mkdir -p /data/pgsql/data && mkdir /data/pgsql/config && sudo chown -R postgres:postgres /data/pgsql
2. sudo su postgres -c '/usr/pgsql-9.3/bin/initdb -D /data/pgsql/data'
3. sudo mv /data/pgsql/data/postgresql.conf /data/pgsql/config/ && sudo mv /data/pgsql/data/pg_hba.conf /data/pgsql/config/ && sudo mv /data/pgsql/data/pg_ident.conf /data/pgsql/config/
4. Edite /data/pgsql/config/postgresql.conf, certificando-se de que essas variáveis ​​sejam definidas da seguinte forma:

   hba_file = '/data/pgsql/config/pg_hba.conf'`
   ident_file = '/data/pgsql/config/pg_ident.conf'
   data_directory = '/data/pgsql/data'
   

5. sudo sh -c 'echo "export PGDATA=/data/pgsql/config" > /etc/sysconfig/pgsql/postgresql-9.3'
6. sudo service postgresql-9.3 start

Isso resulta na mensagem de erro:

/data/pgsql/config está faltando. Use "service postgresql-9.3 initdb" para inicializar o cluster primeiro.

Eu olhei para o script init ( /etc/init.d/postgresql-9.3) e notei isso:

# Verifique a estrutura PGDATA
if [ -f "$PGDATA/PG_VERSION" ] && [ -d "$PGDATA/base" ]
então
    ...
senão
    # Nenhum PGDATA existente! Avise o usuário para initdb nele.

    eco
    echo "$PGDATA está ausente. Use \"service $NAME initdb\" para inicializar o cluster primeiro."
    echo_failure
    eco
    saída 1
fi

Eu adicionei um echo e PGDATA está definido como /data/pgsql/config, o que eu esperaria, mas não tenho certeza de como configurar PGDATA e data_directory poderia funcionar, porque o script init não está verificando postgresql.conf para obter o data_directory como a documentação diz deve. Estou fazendo algo errado? A documentação está errada?

Estou usando pg_dump / pg_restore para fazer backup e restaurar um banco de dados PostgreSQL, mas estou recebendo algumas mensagens de erro (e um status de saída diferente de zero) do pg_restore. Eu tentei um caso base super simples (descrito abaixo), mas ainda recebi esses erros:

pg_restore: [archiver (db)] Erro ao PROCESSAR TOC:
pg_restore: [archiver (db)] Erro da entrada 5 do TOC; 2615 2200 SCHEMA postgres público
pg_restore: [archiver (db)] não pôde executar a consulta: ERRO: o esquema "público" já existe
    O comando era: CREATE SCHEMA public;

Passos para reproduzir:

1. Instale uma nova distribuição do Ubuntu 14.04 (estou usando o Vagrant com esta caixa do Vagrant ).
2. Instale o PostgreSQL 9.3, configure para permitir conexões locais como usuário PostgreSQL "postgres" de qualquer usuário Linux.

3. Crie um banco de dados de teste. Estou apenas fazendo:

   vagrant@vagrant-ubuntu-trusty-64:~$ psql --username=postgres postgres
   psql (9.3.5)
   Digite "ajuda" para obter ajuda.
   
   postgres=# cria banco de dados mydb;
   CRIAR BANCO DE DADOS
   postgres=# \q
   vagrant@vagrant-ubuntu-trusty-64:~$ psql --username=postgres mydb
   psql (9.3.5)
   Digite "ajuda" para obter ajuda.
   
   mydb=# cria dados da tabela(entry bigint);
   CRIAR A TABELA
   mydb=# inserir em valores de dados(1);
   INSERIR 0 1
   mydb=# inserir em valores de dados(2);
   INSERIR 0 1
   mydb=# inserir em valores de dados(3);
   INSERIR 0 1
   meudb=# \q
   

4. Crie um backup do banco de dados assim:

   PGPASSWORD="postgres" pg_dump --dbname=mydb --username=postgres --format=custom > pg_backup.dump

5. Exclua algumas linhas da tabela de dados em mydb para que possamos saber se restauramos os dados com sucesso.

6. Restaure o banco de dados com:

   PGPASSWORD="postgres" pg_restore --clean --create --dbname=postgres --username=postgres pg_backup.dump

Os dados são restaurados, mas o comando pg_restore na etapa 6 sai com status 1e mostra a seguinte saída:

pg_restore: [archiver (db)] Erro ao PROCESSAR TOC:
pg_restore: [archiver (db)] Erro da entrada 5 do TOC; 2615 2200 SCHEMA postgres público
pg_restore: [archiver (db)] não pôde executar a consulta: ERRO: o esquema "público" já existe
    O comando era: CREATE SCHEMA public;



AVISO: erros ignorados na restauração: 1

Não posso simplesmente ignorar isso porque estou executando esse comando programaticamente e preciso usar o status de saída para determinar se a restauração falhou ou não. Inicialmente, me perguntei se esse problema era porque coloquei meu banco de dados em público (o esquema padrão). Eu raciocinei que public seria criado como resultado da --createopção por pg_restore antes que os dados fossem restaurados (o que poderia tentar criar esse esquema também, já que é onde está minha tabela), mas quando tentei as etapas acima com minha tabela em um esquema diferente, os resultados foram os mesmos e as mensagens de erro foram idênticas.

Estou fazendo algo errado? Por que estou vendo esse erro?