Migrar seu banco de dados PostgreSQL usando despejar e restaurar

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Único Banco de Dados do Azure para PostgreSQL – Servidor Flexível

Use pg_dump para extrair um banco de dados PostgreSQL para um arquivo de despejo. O método para restaurar o banco de dados depende do formato do despejo escolhido. Se o dump for feito com o formato simples (que é o padrão -Fp, portanto, nenhuma opção específica precisa ser especificada), a única opção para restaurá-lo é usando psql, pois ele gera um arquivo de texto sem formatação. Para os outros três métodos de dump: custom, directory e tar, pg_restore devem ser usados.

Importante

As instruções e comandos fornecidos neste artigo são projetados para serem executados em terminais bash. Isso inclui ambientes como o Windows Subsystem for Linux (WSL), o Azure Cloud Shell e outras interfaces compatíveis com bash. Certifique-se de que você está usando um terminal bash para seguir as etapas e executar os comandos detalhados neste guia. Usar um tipo diferente de ambiente de terminal ou shell pode resultar em diferenças no comportamento do comando e pode não produzir os resultados pretendidos.

Neste artigo, nos concentramos nos formatos simples (padrão) e de diretório. O formato de diretório é útil, pois permite que você use vários núcleos para processamento, o que pode aumentar significativamente a eficiência, especialmente para grandes bancos de dados.

O portal do Azure simplifica esse processo por meio da folha Conectar, oferecendo comandos pré-configurados que são personalizados para seu servidor, com valores substituídos por seus dados de usuário. É importante observar que a folha Conectar só está disponível para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível e não para Servidor Único. Veja como você pode usar esse recurso:

1. Acessar portal do Azure: primeiro, vá para o portal do Azure e escolha a folha Conectar.

   

2. Selecione seu banco de dados: na folha Conectar, você encontra uma lista suspensa de seus bancos de dados. Selecione o banco de dados do qual você deseja executar um dump.

   

3. Escolha o método apropriado: Dependendo do tamanho do banco de dados, você pode escolher entre dois métodos:

   • pg_dump & psql - usando arquivo de texto singular: Ideal para bancos de dados menores, esta opção utiliza um único arquivo de texto para o processo de despejo e restauração.
   • pg_dump & pg_restore - usando vários núcleos: para bancos de dados maiores, esse método é mais eficiente, pois usa vários núcleos para manipular o processo de despejo e restauração.

   

4. Copiar e colar comandos: O portal fornece comandos prontos para uso pg_dump e psql /ou pg_restore disponíveis. Esses comandos vêm com valores já substituídos de acordo com o servidor e banco de dados que você escolheu. Copie e cole esses comandos.

Pré-requisitos

Se você estiver usando um Servidor Único ou não tiver acesso ao portal do Servidor Flexível, leia esta página de documentação. Ele contém informações semelhantes às apresentadas na folha Conectar para Servidor Flexível no portal.

Para seguir este guia de instruções, você precisa:

• Um Servidor de Banco de Dados do Azure para PostgreSQL com regras de firewall para a permissão do acesso.
• pg_dump, psql, pg_restore e pg_dumpall caso você queira migrar com funções e permissões, utilitários de linha de comando instalados.
• Decida o local para o despejo: Escolha o local de onde você deseja executar o despejo. Isso pode ser feito de vários locais, como uma VM separada, shell de nuvem (onde os utilitários de linha de comando já estão instalados, mas podem não estar na versão apropriada, então sempre verifique a versão usando, por exemplo, psql --version), ou seu próprio laptop. Tenha sempre em mente a distância e a latência entre o servidor PostgreSQL e o local a partir do qual você está executando o despejo ou a restauração.

Importante

É essencial usar os pg_dumputilitários , pg_restorepsqle pg_dumpall que são da mesma versão principal ou uma versão principal superior ao servidor de banco de dados do qual você está exportando ou importando dados. Se isso não for feito, a migração de dados não será bem-sucedida. Se o servidor de destino tiver uma versão principal superior à do servidor de origem, use utilitários que sejam a mesma versão principal ou superior ao servidor de destino.

Observação

É importante estar ciente de que pg_dump pode exportar apenas um banco de dados por vez. Essa limitação se aplica independentemente do método escolhido, seja usando um arquivo singular ou vários núcleos.

Despejando usuários e funções com pg_dumpall -r

pg_dump é usado para extrair um banco de dados PostgreSQL em um arquivo de despejo. No entanto, é crucial entender que pg_dump não despeja funções ou definições de usuários, pois eles são considerados objetos globais dentro do ambiente PostgreSQL. Para uma migração abrangente, incluindo usuários e funções, você precisa usar pg_dumpall -ro . Esse comando permite que você capture todas as informações de função e usuário do seu ambiente PostgreSQL. Se você estiver migrando dentro de bancos de dados no mesmo servidor, sinta-se à vontade para ignorar esta etapa e mover para a seção Criar um novo banco de dados .

pg_dumpall -r -h <server name> -U <user name> > roles.sql

Por exemplo, se você tiver um servidor nomeado mydemoserver e um usuário nomeado myuser , execute o seguinte comando:

pg_dumpall -r -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql

Se você estiver usando um Servidor Único, seu nome de usuário incluirá o componente de nome do servidor. Portanto, em vez de myuser, use myuser@mydemoserver.

Despejando funções de um servidor flexível

Em um ambiente de Servidor Flexível, as medidas de segurança aprimoradas significam que os usuários não têm acesso à tabela pg_authid, que é onde as senhas de função são armazenadas. Essa restrição afeta como você executa um despejo de funções, pois o comando padrão pg_dumpall -r tenta acessar essa tabela para senhas e falha devido à falta de permissão.

Ao despejar funções de um Servidor Flexível, é crucial incluir a --no-role-passwords opção em seu pg_dumpall comando. Essa opção impede pg_dumpall a tentativa de acessar a tabela, que não pode ser lida devido a pg_authid restrições de segurança.

Para despejar funções com êxito de um servidor flexível, use o seguinte comando:

pg_dumpall -r --no-role-passwords -h <server name> -U <user name> > roles.sql

Por exemplo, se você tiver um servidor chamado , um usuário chamado mydemoservermyuser, execute o seguinte comando:

pg_dumpall -r --no-role-passwords -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql

Limpando o despejo de funções

Ao migrar, o arquivo roles.sql de saída pode incluir determinadas funções e atributos que não são aplicáveis ou permitidos no novo ambiente. Aqui está o que você precisa considerar:

• Removendo atributos que podem ser definidos apenas por superusuários: se estiver migrando para um ambiente onde você não tem privilégios de superusuário, remova atributos como NOSUPERUSER e NOBYPASSRLS do despejo de funções.

• Excluindo usuários específicos do serviço: Excluir usuários do serviço Servidor Único, como azure_superuser ou azure_pg_admin. Estes são específicos para o serviço e serão criados automaticamente no novo ambiente.

Use o seguinte sed comando para limpar o despejo de funções:

sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql

Esse comando exclui linhas que contêm azure_superuser, , , linhas começando com CREATE ROLE replication e , azure_pg_adminazuresue remove os NOSUPERUSER atributos e NOBYPASSRLSALTER ROLE replicationdas ALTER ROLE instruções.

Criar um arquivo de despejo que contenha os dados a serem carregados

Para exportar seu banco de dados PostgreSQL existente no local ou em uma VM para um arquivo de script sql, execute o seguinte comando em seu ambiente existente:

pg_dump & psql - usando arquivo de texto singular

pg_dump <database name> -h <server name> -U <user name> > <database name>_dump.sql

Por exemplo, se você tiver um servidor chamado , um usuário nomeado myuser e um banco de dados chamado mydemoservertestdb, execute o seguinte comando:

pg_dump testdb -h mydemoserver.postgres.database.azure.com -U myuser > testdb_dump.sql

pg_dump & pg_restore - usando vários núcleos

pg_dump -Fd -j <number of cores> <database name> -h <server name> -U <user name> -f <database name>.dump

Nesses comandos, a -j opção representa o número de núcleos que você deseja usar para o processo de despejo. Você pode ajustar esse número com base em quantos núcleos estão disponíveis no servidor PostgreSQL e quantos você gostaria de alocar para o processo de despejo. Sinta-se à vontade para alterar essa configuração dependendo da capacidade do servidor e dos requisitos de desempenho.

Por exemplo, se você tiver um servidor chamado , um usuário nomeado myuser e um banco de dados chamado mydemoservertestdb, e desejar usar dois núcleos para o despejo, execute o seguinte comando:

pg_dump -Fd -j 2 testdb -h mydemoserver.postgres.database.azure.com -U myuser -f testdb.dump

Se você estiver usando um Servidor Único, seu nome de usuário incluirá o componente de nome do servidor. Portanto, em vez de myuser, use myuser@mydemoserver.

Restaurar os dados no banco de dados de destino

Restaurar funções e usuários

Antes de restaurar os objetos de banco de dados, verifique se você despejou e limpou corretamente as funções. Se você estiver migrando dentro de bancos de dados no mesmo servidor, talvez não seja necessário despejar as funções e restaurá-las. No entanto, para migrações entre diferentes servidores ou ambientes, essa etapa é crucial.

Para restaurar as funções e os usuários no banco de dados de destino, use o seguinte comando:

psql -f roles.sql -h <server_name> -U <user_name>

Substitua pelo <server_name> nome do servidor de destino e <user_name> pelo nome de usuário. Esse comando usa o utilitário para executar os comandos SQL contidos no arquivo, restaurando efetivamente as funções e os usuários para o psqlroles.sql banco de dados de destino.

Por exemplo, se você tiver um servidor chamado , um usuário chamado mydemoservermyuser, execute o seguinte comando:

psql -f roles.sql -h mydemoserver.postgres.database.azure.com -U myuser

Se você estiver usando um Servidor Único, seu nome de usuário incluirá o componente de nome do servidor. Portanto, em vez de myuser, use myuser@mydemoserver.

Observação

Se você já tiver usuários com os mesmos nomes no servidor único ou no servidor local do qual está migrando e no servidor de destino, esteja ciente de que esse processo de restauração pode alterar as senhas dessas funções. Consequentemente, quaisquer comandos subsequentes que você precisa executar podem exigir as senhas atualizadas. Isso não se aplica se o servidor de origem for um Servidor Flexível, pois o Servidor Flexível não permite o despejo de senhas para usuários devido a medidas de segurança aprimoradas.

Criar um novo banco de dados

Antes de restaurar o banco de dados, talvez seja necessário criar um novo banco de dados vazio. Para fazer isso, o usuário que você está usando deve ter a CREATEDB permissão. Aqui estão dois métodos comumente usados:

1. Usando createdb o utilitário O createdb programa permite a criação de banco de dados diretamente da linha de comando bash, sem a necessidade de fazer login no PostgreSQL ou sair do ambiente do sistema operacional. Por exemplo:

   createdb <new database name> -h <server name> -U <user name>
   

   Por exemplo, se você tiver um servidor chamado , um usuário chamado mydemoservere o novo banco de dados que myuser você deseja criar for testdb_copy, execute o seguinte comando:

   createdb testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser
   

   Se você estiver usando um Servidor Único, seu nome de usuário incluirá o componente de nome do servidor. Portanto, em vez de myuser, use myuser@mydemoserver.

2. Usando o comando SQL Para criar um banco de dados usando um comando SQL, você precisará se conectar ao seu servidor PostgreSQL por meio de uma interface de linha de comando ou uma ferramenta de gerenciamento de banco de dados. Uma vez conectado, você pode usar o seguinte comando SQL para criar um novo banco de dados:

CREATE DATABASE <new database name>;

Substitua <new database name> pelo nome que você deseja dar ao seu novo banco de dados. Por exemplo, para criar um banco de dados chamado testdb_copy, o comando seria:

CREATE DATABASE testdb_copy;

Restaurando o despejo

Depois de criar o banco de dados de destino, você pode restaurar os dados nesse banco de dados a partir do arquivo de despejo. Durante a restauração, registre quaisquer erros em um errors.log arquivo e verifique se há erros em seu conteúdo depois que a restauração for concluída.

pg_dump & psql - usando arquivo de texto singular

psql -f <database name>_dump.sql <new database name> -h <server name> -U <user name> 2> errors.log

Por exemplo, se você tiver um servidor chamado , um usuário nomeado myuser e um novo banco de dados chamado mydemoservertestdb_copy, execute o seguinte comando:

psql -f testdb_dump.sql testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log

pg_dump & pg_restore - usando vários núcleos

pg_restore -Fd -j <number of cores> -d <new database name> <database name>.dump -h <server name> -U <user name> 2> errors.log

Nesses comandos, a -j opção representa o número de núcleos que você deseja usar para o processo de restauração. Você pode ajustar esse número com base em quantos núcleos estão disponíveis no seu servidor PostgreSQL e quantos você gostaria de alocar para o processo de restauração. Sinta-se à vontade para alterar essa configuração dependendo da capacidade do servidor e dos requisitos de desempenho.

Por exemplo, se você tiver um servidor chamado , um usuário nomeado myuser e um novo banco de dados chamado mydemoservertestdb_copy, e desejar usar dois núcleos para o despejo, execute o seguinte comando:

pg_restore -Fd -j 2 -d testdb_copy testdb.dump -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log

Verificação pós-restauração

Depois que o processo de restauração for concluído, é importante revisar o errors.log arquivo em busca de erros que possam ter ocorrido. Essa etapa é crucial para garantir a integridade e a integridade dos dados restaurados. Resolva quaisquer problemas encontrados no arquivo de log para manter a confiabilidade do banco de dados.

Otimizar o processo de migração

Ao trabalhar com grandes bancos de dados, o processo de despejo e restauração pode ser demorado e pode exigir otimização para garantir eficiência e confiabilidade. É importante estar atento aos diversos fatores que podem impactar o desempenho dessas operações e tomar medidas para otimizá-las.

Para obter orientações detalhadas sobre como otimizar o processo de despejo e restauração, consulte o artigo Práticas recomendadas para pg_dump e pg_restore . Esse recurso fornece informações e estratégias abrangentes que podem ser benéficas para lidar com grandes bancos de dados.

Próximas etapas

• Práticas recomendadas para pg_dump e pg_restore.
• Para obter mais informações de como migrar bancos de dados para o Banco de Dados do Azure para PostgreSQL, confira o Guia de Migração de Banco de Dados.