Atualiza o banco de dados Postgresql de 9.1 para 9.2 e 32 bits para 64 bits

Question

Como parte de uma atualização de servidor, estamos indo do Linux de 32 bits para o Linux de 64 bits (o Gentoo faz diferença) e do Postgresql 9.1 para o 9.2. Eu estou tendo um heck de um tempo atualizando o banco de dados com pg_upgrade ...

Minha primeira tentativa foi guardar o antigo diretório bin (& bin) de 32 bits do pgsql, atualizar o sistema e, em seguida, executar o sistema atualizado (64 bits):

pg_upgrade -b pgsql.old/bin -B /usr/lib64/postgresql-9.2/bin -d data.old -D data.new

Isso falha porque o pg_upgrade tenta executar o pgsql.old / bin / pg_ctl com a libpq.so.5 incorreta (a versão do sistema de 64 bits, não a versão de 32 bits do pgsql.old / lib). Se eu definir LD_LIBRARY_PATH para apontar para pgsql.old / lib, posso executar manualmente o antigo pg_ctl de 32 bits, mas isso não parece ajudar o pg_upgrade.

Então eu pensei em instalar o Postgresql 9.1 de 64 bits juntamente com o 9.2. Agora quando eu corro:

pg_upgrade -b /usr/lib64/postgresql-9.1/bin -B /usr/lib64/postgresql-9.2/bin -d data.old -D data.new

Os binários funcionam bem, mas a atualização falha cedo:

old and new pg_controldata alignments are invalid or do not match

que eu acho que é devido a problemas de alinhamento de 32 bits vs 64 bits no banco de dados?

Eu sei que o pg_dump / pg_restore funcionará bem, mas por questões de velocidade eu gostaria de usar o pg_upgrade, se possível. Este não é um negócio one-shot - temos algumas centenas de sistemas no campo que precisarão ser atualizados de forma automatizada (via pen drive inicializável com scripts apropriados).

    

Answer 1

Você não pode usar o pg_upgrade para atualizar de 32 bits para 64 bits ou, em geral, de qualquer plataforma OS / CPU / para qualquer outro SO / CPU / plataforma. Os arquivos de dados são dependentes da plataforma, e o pg_upgrade funciona apenas copiando (ou vinculando) os arquivos de dados inalterados. Então isso nunca vai funcionar.

Suas opções neste ponto são dump / restore, ou usando um sistema de replicação lógica para mover seus dados (Slony, Londiste, Bucardo).

    

Answer 2

Eu nunca faria do jeito que você está fazendo. Apenas para o registro, eu estive com o PostgreSQL desde, oh, 6.x dias (também conhecido como muitos, muitos anos).

Eu sempre, sem questionar, faço algo ao longo destas linhas:

1. Descarregar a versão antiga com o pg_dump
2. instale a nova versão, talvez ao lado da sua versão atual na sua situação. Eu sempre sym-link a localização padrão. Se, por exemplo, o pgsql acabar em / usr / local / pgsql, eu mudo isso para /usr/local/pgsql-v9.1.2 e então eu o vinculo sim com o pgsql, então meus scripts RC não precisam de muito ajuste nem meu LD_CONFIG
3. Inicie o novo ambiente de banco de dados com a nova versão recém-instalada
4. Restaure seus dados com o psql

Eu uso script RC personalizado para parar, iniciar e & reinicie o postmaster e dentro dele eu tenho configurações que apontam para os dados atuais & diretórios xlog.

Além disso, eu entendo que você está usando o gerenciador de pacotes de uma determinada distribuição. Eu evito isso e sempre construo o PostgreSQL a partir do código-fonte.