pg_rewind

pg_rewind — sincroniza um diretório de dados do PostgreSQL com outro diretório de dados que foi bifurcado a partir dele

Sinopse

pg_rewind [opção...] { -D | --target-pgdata= } diretório_de_dados { --source-pgdata=diretório_de_dados | --source-server=cadeia_de_caracteres_de_conexão }

Descrição

O utilitário pg_rewind é uma ferramenta que permite sincronizar uma instância do PostgreSQL com uma cópia dessa mesma instância, após as linhas do tempo dessas instâncias divergirem. O contexto típico é a reativação do servidor primário antigo após a comutação (failover), colocando-o como um servidor em-espera replicando o novo servidor primário.

Após a sincronização bem-sucedida, o estado do armazenamento de dados do destino é análogo a uma cópia de segurança base do armazenamento de dados da origem. Diferentemente de fazer uma nova cópia de segurança base, ou usar uma ferramenta como rsync, o utilitário pg_rewind não requer comparação ou cópia de blocos de relação não alterados na instância. Somente blocos alterados dos arquivos de relação existentes são copiados; todos os outros arquivos, incluindo os novos arquivos de relação, arquivos de configuração, e segmentos de WAL, são copiados por inteiro. Como tal, a operação de sincronização é muito mais rápida do que outras abordagens quando o banco de dados é grande, e apenas uma pequena fração dos blocos difere entre as instâncias.

O utilitário pg_rewind examina os históricos de linha do tempo das instâncias de origem e de destino para determinar o ponto em que divergiram, e espera encontrar o WAL no diretório pg_wal da instância de destino, para refazer todo o caminho de volta ao ponto de divergência. O ponto de divergência pode ser encontrado na linha do tempo do destino, na linha do tempo da origem, ou no ancestral comum. No contexto de comutação típico, em que a instância de destino foi parada logo após a divergência, isto não é um problema, mas se a instância de destino foi executada por um longo período após a divergência, seus arquivos de WAL antigos poderão não estar mais presentes. Neste caso, pode-se copiá-los manualmente do arquivamento de WAL para o diretório pg_wal, ou executar o utilitário pg_rewind com a opção -c para recuperar automaticamente do arquivamento de WAL. O uso do utilitário pg_rewind não está limitado à comutação, por exemplo, um servidor em-espera pode ser promovido, executar algumas transações de escrita e, em seguida, retroceder para se tornar um servidor em-espera novamente.

Após executar o utilitário pg_rewind, a reprodução do WAL precisa ser concluída para que o diretório de dados fique em um estado consistente. Quando o servidor de destino for ativado novamente, ele entrará em recuperação do arquivamento, e reproduzirá todo o WAL gerado no servidor de origem desde o último ponto de verificação antes do ponto de divergência. Se algum arquivo de WAL não estava mais disponível no servidor de origem quando pg_rewind foi executado, e, portanto, não pôde ser copiado pela sessão do pg_rewind, ele deverá ser disponibilizado quando o servidor de destino for ativado. Isto pode ser feito criando o arquivo recovery.signal no diretório de dados de destino, e configurando o restore_command adequado no arquivo postgresql.conf.

O utilitário pg_rewind requer que o servidor de destino tenha a opção wal_log_hints ativa no arquivo postgresql.conf, ou somas de verificação de dados ativas quando a instância foi inicializada com o initdb (o padrão). A definição de full_page_writes também deve estar definida como on, mas está ativa por padrão.

Aviso: Falhas durante o rebobinamento

Se o utilitário pg_rewind falhar durante o processamento, a pasta de dados de destino provavelmente não estará em um estado que possa ser recuperado. Neste caso, se recomenda fazer uma nova cópia de segurança.

Como o utilitário pg_rewind copia os arquivos de configuração por inteiro da origem, poderá ser necessário corrigir a configuração usada para a recuperação antes de ativar o servidor de destino, especialmente se o servidor de destino for ser reintroduzido como um servidor em-espera do servidor de origem. Se o servidor for ativado após a conclusão da operação de sincronização, mas sem configurar a recuperação, o servidor de destino poderá divergir novamente do servidor primário.

O utilitário pg_rewind irá falhar imediatamente se encontrar arquivos nos quais não pode escrever diretamente. Isto pode acontecer, por exemplo, quando a origem e o servidor de destino usam o mesmo mapeamento de arquivo para chaves e certificados SSL de leitura-apenas. Se estes arquivos estiverem presentes no servidor de destino, é recomendável removê-los antes de executar o utilitário pg_rewind. Após fazer a sincronização, alguns desses arquivos podem ter sido copiados da origem, caso em que pode ser necessário remover os arquivos copiados e restaurar o conjunto de ligações (links) usados antes da sincronização.

Opções

O utilitário pg_rewind aceita os seguintes argumentos de linha de comando:

-D diretório_de_dados
--target-pgdata=diretório_de_dados

Especifica o diretório de dados de destino que será sincronizado com a origem. O servidor de destino deverá ser parado corretamente antes de executar o utilitário pg_rewind

--source-pgdata=diretório_de_dados

Especifica o caminho do sistema de arquivos para o diretório de dados do servidor de origem com o qual sincronizar o destino. Esta opção requer que o servidor de origem seja parado corretamente.

--source-server=cadeia_de_caracteres_de_conexão

Especifica uma cadeia de caracteres de conexão libpq para se conectar ao servidor PostgreSQL de origem para sincronizar o destino. A conexão deve ser uma conexão normal (sem replicação) com uma função de banco de dados (role) com permissões suficientes para executar as funções usadas pelo utilitário pg_rewind no servidor de origem (veja a seção Notas para obter detalhes), ou uma função de banco de dados de superusuário. Esta opção requer que o servidor de origem esteja ativo e aceitando conexões.

-R
--write-recovery-conf

Cria o arquivo standby.signal, e anexa as configurações de conexão ao arquivo postgresql.auto.conf no diretório de saída. O parâmetro dbname será registrado somente se dbname tiver sido especificado explicitamente na cadeia de caracteres de conexão ou na variável de ambiente. A opção --source-server é obrigatória com esta opção.

-n
--dry-run

Faz tudo, exceto modificar o diretório de destino.

-N
--no-sync

Por padrão, o utilitário pg_rewind irá aguardar que todos os arquivos sejam escritos com segurança no disco. Esta opção faz com que o utilitário pg_rewind retorne sem esperar, o que é mais rápido, mas significa que uma falha subsequente do sistema operacional poderá deixar o diretório de dados corrompido. Geralmente, esta opção é útil para testes, mas não deve ser usada em uma instalação de produção.

-P
--progress

Ativa o relatório de progresso, que fornece um relatório de progresso aproximado ao copiar os dados da instância de origem.

-c
--restore-target-wal

Usa o restore_command, definido na configuração da instância de destino, para recuperar os arquivos de WAL do arquivamento de WAL, se estes arquivos não estiverem mais disponíveis no diretório pg_wal.

--config-file=nome_do_arquivo

Usa o arquivo de configuração do servidor principal especificado para a instância de destino. Afeta o utilitário pg_rewind quando este usa internamente o comando postgres para a operação de rebobinamento nesta instância (ao recuperar restore_command com a opção -c/--restore-target-wal e ao forçar a conclusão da recuperação de falhas).

--debug

Mostra uma saída de depuração detalhada, que é mais útil para a depuração pelos desenvolvedores do utilitário pg_rewind.

--no-ensure-shutdown

O utilitário pg_rewind requer que o servidor de destino seja parado corretamente antes de sincronizar. Por padrão, se o servidor de destino não foi parado corretamente, o pg_rewind primeiro inicia o servidor de destino no modo de usuário único para concluir a recuperação da falha, e o interrompe. Ao usar esta opção, o pg_rewind pula esta parte, gerando erros imediatamente se o servidor não foi parado corretamente. Neste caso, espera-se que os usuários lidem com esta situação por conta própria.

--sync-method=método

Quando definido como fsync, que é o padrão, o utilitário pg_rewind irá abrir e sincronizar recursivamente todos os arquivos no diretório de dados. A busca por arquivos seguirá as ligações simbólicas para o diretório de WAL e para cada espaço de tabelas configurado.

No Linux, pode-se usar o syncfs em vez de solicitar ao sistema operacional que sincronize todo o sistema de arquivos que contém o diretório de dados, os arquivos de WAL e cada espaço de tabelas. Veja recovery_init_sync_method para obter informações sobre as precauções a serem tomadas ao usar o syncfs.

Esta opção não tem efeito quando é usado --no-sync.

-V
--version

Mostra as informações da versão, e termina.

-?
--help

Mostra a ajuda, e termina.

Variáveis de ambiente

Quando é usada a opção --source-server, o utilitário pg_rewind também usa as variáveis de ambiente com suporte pela libpq (veja Variáveis ​​de ambiente).

A variável de ambiente PG_COLOR especifica se devem ser usadas cores nas mensagens de diagnóstico. Os valores possíveis são always, auto e never.

Notas

Ao executar o utilitário pg_rewind usando uma instância ativa como origem, pode ser usada uma função de banco de dados (role) com permissões suficientes para executar as funções usadas por pg_rewind na instância de origem, em vez de um superusuário. A seguir está mostrado como criar esta função de banco de dados, chamada rewind_user aqui:

CREATE USER rewind_user LOGIN;
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;

Como funciona

A ideia básica é copiar todas as alterações no nível do sistema de arquivos da instância de origem para a instância de destino:

  1. Percorrer os registros do WAL da instância de destino, começando pelo último ponto de verificação antes do ponto em que o histórico da linha do tempo da instância de origem se ramificou da instância de destino. Para cada registro do WAL, registrar cada bloco de dados que foi tocado. Isto produz uma lista de todos os blocos de dados alterados na instância de destino, após a ramificação da instância de origem. Se alguns dos arquivos de WAL não estiverem mais disponíveis, deve-se tentar executar novamente o utilitário pg_rewind com a opção -c para procurar os arquivos ausentes no arquivamento de WAL.

  2. Copiar todos os blocos alterados da instância de origem para a instância de destino, usando acesso direto ao sistema de arquivos (--source-pgdata), ou SQL (--source-server). Os arquivos de relação estão agora em um estado equivalente ao momento do último ponto de verificação concluído antes do ponto em que as linhas de tempo do WAL da origem e do destino ramificaram, mais o estado atual na origem de quaisquer blocos alterados no destino após esta divergência.

  3. Copiar todos os outros arquivos, incluindo novos arquivos de relação, segmentos de WAL, o diretório pg_xact, e arquivos de configuração da instância de origem para a instância de destino. Da mesma forma que as cópias de segurança base, o conteúdo dos diretórios pg_dynshmem/, pg_notify/, pg_replslot/, pg_serial/, pg_snapshots/, pg_stat_tmp/, e pg_subtrans/ são omitidos dos dados copiados da instância de origem. Os arquivos backup_label, tablespace_map, pg_internal.init, postmaster.opts, postmaster.pid e .DS_Store, assim como qualquer arquivo ou diretório começando com pgsql_tmp, são omitidos.

  4. Criar o arquivo backup_label para iniciar a reprodução do WAL no ponto de verificação criado na comutação (failover), e configurar o arquivo pg_control com o LSN de consistência mínima definido como resultado de pg_current_wal_insert_lsn() ao sincronizar de uma origem ativa, ou o LSN do último ponto de verificação, ao sincronizar de uma fonte parada.

  5. Ao ativar o destino, o PostgreSQL irá reproduzir todo o WAL necessário, resultando em um diretório de dados em um estado consistente.