pg_rewind — sincroniza um diretório de dados do PostgreSQL com outro diretório de dados que foi bifurcado a partir dele
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
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.
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.
O utilitário pg_rewind aceita os seguintes argumentos de linha de comando:
-D diretório_de_dados--target-pgdata=diretório_de_dadosEspecifica 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_dadosEspecifica 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ãoEspecifica 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-runFaz 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--progressAtiva 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).
--debugMostra uma saída de depuração detalhada, que é mais útil para a depuração pelos desenvolvedores do utilitário pg_rewind.
--no-ensure-shutdownO 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--versionMostra as informações da versão, e termina.
-?--helpMostra a ajuda, e termina.
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.
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;
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:
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.
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.
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.
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.
Ao ativar o destino, o PostgreSQL irá reproduzir todo o WAL necessário, resultando em um diretório de dados em um estado consistente.