Início / dba / Perguntas / 125769
Accepted
Brooks
Asked: 2016-01-10 19:20:45 +0800 CST

PostgreSQL: Restaurando 1 arquivo de um despejo de formato de diretório

  • 772

Eu tenho um banco de dados PostgreSQL grande (> 700 GB). Estou trabalhando para importá-lo para o AWS RDS. Sei que existem módulos que causarão problemas, estamos lidando com isso separadamente, então, por enquanto, estou apenas trabalhando na migração dos dados para o RDS.

Estou migrando de e para PostgreSQL 9.4.5 usando pg_dump e pg_restore 9.4.5.

Após várias horas de transferência (pg_dump para pg_restore com um formato de diretório), verifiquei o log e percebi que há uma coisa (possivelmente uma tabela?) De propriedade do usuário Postgres que eu desconhecia.

Encontrei a linha no arquivo toc.dat que fez a chamada e descompactei o arquivo .dat.gz para descobrir que ele contém apenas "\." (sem as aspas) nele.

Portanto, minha pergunta é, além de interromper a transferência e recomeçar, existe uma maneira de simplesmente transferir esse comando e arquivo específicos assim que a importação for concluída?

Aqui estão os detalhes relevantes.

O comando pg_dump:

pg_dump -h localhost -p 5432 -d DBNAME -U USERNAME -F d -f /mnt/backup -j 7

O comando pg_restore:

pg_restore --dbname=DBNAME --no-tablespaces --host=HOSTNAME --port=5432 --username=USERNAME --verbose -F d -j 6 /mnt/backup

A seção do arquivo toc.dat. Percebo que o formato do diretório é gerado em formato binário, mas espero que o fato de isso ser identificável signifique que há uma maneira de voltar e corrigir esse erro.

^@^F^@^@^@public^A^A^@^@^@^@^H^@^@^@postgres^@^E^@^@^@false^@^C^@^@^@173^A^A^@^@^@^@    ^@^@^@10393.dat^@W<^@^@^@^A^@^@^@^@^A^@^@^@0^@^E^@^@^@26106^@^N^@^@^@search_name_66^@
^@^@^@TABLE DATA^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@]^@^@^@COPY search_name_66 (place_id, search_rank, address_rank, name_vector, centroid) FROM stdin;

O erro real relatado por pg_restore:

pg_restore: [archiver (db)] Error from TOC entry 10393; 0 16787 TABLE DATA spatial_ref_sys postgres
postgresql postgresql-9.4

1 respostas

  1. Best Answer

    Encontrei a linha no arquivo toc.dat que fez a chamada e descompactei o arquivo .dat.gz para descobrir que ele contém apenas "\." (sem as aspas) nele.

    \.não é um comando, ele marca o fim dos dados em um fluxo COPY. Se o arquivo de dados correspondente dentro do dump contiver apenas isso, a tabela de origem estava vazia.

    Observe também que você pode pg_restore --listlistar o conteúdo de um despejo no diretório ou no formato compactado.

    Você também pode restaurar o conteúdo de uma tabela individual em um arquivo SQL em vez de no banco de dados de destino, modificar esse arquivo conforme conveniente e reproduzi-lo no destino. Veja a página de manual pg_restore para mais.

    • 6

relate perguntas