pg_resetxlog [-f] [-n] [-ooid ] [-x xid ] [-e xid_epoch ] [-m mxid ] [-O mxoff ] [-l timelineid,fileid,seg ] diretório_de_dados
O utilitário pg_resetxlog limpa o log de escrita prévia (WAL) e, opcionalmente, redefine algumas outras informações de controle armazenadas no arquivo pg_control. Algumas vezes este utilitário é necessário quando estes arquivos ficam danificados. Deve ser utilizado apenas como último recurso, quando o servidor não iniciar devido a estes arquivos estarem danificados.
Após executar este comando deve ser possível iniciar o servidor, mas deve-se ter em mente que o banco de dados poderá conter dados inconsistentes devido a transações parcialmente efetivadas. Deve ser feita, imediatamente, uma cópia de segurança dos dados, executar o initdb e recarregar os dados. Após a recarga as inconsistências devem ser verificadas e corrigidas conforme necessário.
Este utilitário pode ser executado apenas pelo usuário que instalou o servidor, porque requer acesso de leitura/escrita no diretório de dados. Por motivo de segurança, o diretório de dados deve ser especificado na linha de comando. O pg_resetxlog não utiliza a variável de ambiente PGDATA.
Se o pg_resetxlog informar que não está conseguindo determinar os dados válidos para pg_control, pode ser forçado a prosseguir assim mesmo especificando a chave -f (forçar). Neste caso, são utilizados valores plausíveis para os dados que estão faltando. Pode-se esperar que a maioria dos campos correspondam, mas pode ser necessário auxílio manual para os campos próximo OID, próximo ID e época de transação, próximo ID e deslocamento de multitransação, endereço inicial do WAL e idioma do banco de dados. Os seis primeiros podem ser definidos usando as chaves discutidas abaixo. O próprio ambiente do pg_resetxlog é a fonte para os campos de idioma; deve-se cuidar para que LANG e as demais variáveis de ambiente análogas correspondam ao ambiente em que o initdb foi executado. Se não for possível determinar o valor correto para todos estes campos a chave -f ainda poderá ser utilizada, mas o banco de dados recuperado deverá ser tratado como ainda mais suspeito que o usual: uma imediata cópia de segurança e sua recarga é imperativa. Não deve ser executada nenhuma operação que modifique os dados do banco de dados antes de ser feita a cópia de segurança, porque uma atividade deste tipo pode piorar ainda mais a situação.
As chaves -o, -x, -e, -m, -O e -l permitem definir manualmente o próximo OID, o próximo ID de transação, a época do próximo ID de transação, o próximo ID de multitransação, o próximo deslocamento de multitransação, e o endereço inicial do WAL. Estas chaves somente são necessárias quando o pg_resetxlog não é capaz de determinar os valores apropriados por meio da leitura do arquivo pg_control. A seguir são mostrados como podem ser determinados valores seguros:
Pode ser determinado um valor seguro para o próximo identificador de transação (-x) descobrindo o nome de arquivo com o maior valor numérico no diretório pg_clog sob o diretório de dados, somando um, e depois multiplicando por 1.048.576. Deve ser observado que os nomes dos arquivos estão em hexadecimal. Normalmente é mais fácil especificar o valor da chave em hexadecimal também. Por exemplo, se a maior entrada em pg_clog for 0011, então -x 0x1200000 servirá (cinco zeros à direita fornecem o multiplicador apropriado).
Pode ser determinado um valor seguro para o próximo identificador de multitransação (-m) descobrindo o nome de arquivo com o maior valor numérico no diretório pg_multixact/offsets sob o diretório de dados, somando um, e depois multiplicando por 65536. Da mesma maneira que no caso anterior os nomes dos arquivos estão em hexadecimal e, portanto, a forma mais fácil de fazer é especificar o valor da chave em hexadecimal adicionando quatro zeros.
Pode ser determinado um valor seguro para o próximo deslocamento de multitransação (-O) descobrindo o nome de arquivo com o maior valor numérico no diretório pg_multixact/members sob o diretório de dados, somando um, e depois multiplicando por 65536. Da mesma maneira que no caso anterior os nomes dos arquivos estão em hexadecimal e, portanto, a forma mais fácil de fazer é especificar o valor da chave em hexadecimal adicionando quatro zeros.
O endereço inicial do WAL (-l) deve ser maior que qualquer nome de arquivo existente no diretório /pg_xlog sob o diretório de dados. Estes nomes também estão em hexadecimal, e possuem três partes. A primeira parte é o "timeline ID" e deve, geralmente, ser mantido o mesmo. Não deve ser escolhido um valor maior que 255 (0xFF) para a terceira parte; em vez disso, a segunda parte deve ser incrementada e a terceira parte deve ser redefinida como 0. Por exemplo, se a maior entrada em pg_xlog for 00000001000000320000004A, -l 0x1,0x32,0x4B servirá; mas se a maior entrada for 000000010000003A000000FF, então deverá ser escolhido -l 0x1,0x3B,0x0 ou maior.
Não existe nenhuma forma mais fácil para determinar o próximo OID acima do maior existente no banco de dados, mas por sorte não é crítico definir o próximo OID corretamente.
A época do identificador de transação não é armazenada em nenhum lugar no banco de dados, com exceção do campo definido por pg_resetxlog, portanto qualquer valor servirá do ponto de vista do próprio banco de dados. Poderá ser necessário ajustar este valor para garantir que os sistemas de replicação, como o Slony-I, funcionem corretamente — se for o caso, poderá ser obtido um valor apropriado a partir do estado do banco de dados replicado.
A chave -n (nenhuma operação) faz o pg_resetxlog mostrar os valores reconstruídos a partir de pg_control e terminar em seguida, sem modificar nada. Esta é principalmente uma ferramenta de depuração, mas pode ser útil para fazer uma verificação de integridade antes de permitir que o pg_resetxlog realmente efetue a operação.
Este comando não deve ser usado quando o servidor estiver executando. O pg_resetxlog se recusa a iniciar quando encontra o arquivo de bloqueio do servidor no diretório de dados. Se o servidor caiu, então o arquivo de bloqueio pode ter sido deixado no diretório de dados; neste caso, o arquivo de bloqueio deverá ser removido para permitir que o pg_resetxlog execute, mas antes de remover o arquivo de bloqueio deve-se ter certeza que nenhum processo servidor ainda está executando.
