Início / dba / Perguntas / 6395
Accepted
francs
Asked: 2011-10-01 17:45:11 +0800 CST

Sobre "Contorno de ID de transação"

  • 772

Agora, eu li o documento sobre "Transaction ID Wraparound", mas há algo que eu realmente não entendo, o documento é o seguinte url http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html#VACUUM-FOR-WRAPAROUND

23.1.4. Prevenção de falhas de contorno de ID de transação

A semântica de transação MVCC do PostgreSQL depende da capacidade de comparar números de ID de transação (XID): uma versão de linha com um XID de inserção maior que o XID da transação atual é "no futuro" e não deve ser visível para a transação atual. Mas, como os IDs de transação têm tamanho limitado (32 bits), um cluster que executa por um longo período (mais de 4 bilhões de transações) sofreria uma quebra de ID de transação: o contador XID volta a zero e, de repente, as transações que estavam no passado parecem estar no futuro - o que significa que sua produção se torna invisível. Resumindo, perda de dados catastrófica. (Na verdade, os dados ainda estão lá, mas isso é um consolo se você não conseguir obtê-los.) Para evitar isso, é necessário limpar todas as tabelas em todos os bancos de dados pelo menos uma vez a cada dois bilhões de transações.

Eu não entendo as declarações "sofreria a volta do ID da transação: o contador XID chega a zero e, de repente, as transações que estavam no passado parecem estar no futuro - o que significa que sua saída se torna invisível"

Alguém pode explicar isso? Por que, depois que o banco de dados sofre um wraparound de ID de transação, as transações que estavam no passado parecem estar no futuro? Resumindo, quero saber se o PostgreSQL entrará na situação de "perda de dados" após o wraparound do ID da transação pelo autovacuum。

Para minhas visões pessoais, podemos obter o ID da transação atual usando a função txid_current () cuja saída é de 64 bits e não será alternada. pela função txid_current(). Exceto que você usará pg_resetxlog reset reset ID da transação após desligar o PostgreSQL Server. Estou certo ? Obrigado

postgresql

2 respostas

  1. Best Answer

    Por que, depois que o banco de dados sofre um wraparound de ID de transação, as transações que estavam no passado parecem estar no futuro?

    Eles não. O texto citado apenas explica por que o postgres precisa usar o módulo 2 31 aritmático (o que significa que as transações podem ser agrupadas, desde que as transações antigas sejam 'congeladas' com antecedência suficiente):

    Os XIDs normais são comparados usando a aritmética módulo-2^31. Isso significa que, para cada XID normal, existem dois bilhões de XIDs "antigos" e dois bilhões "mais recentes".

    para ser específico:

    as versões de linha antigas devem ser reatribuídas ao XID FrozenXID antes de atingirem a marca de dois bilhões de transações

    ou envolver o XID faria com que as coisas quebrassem. Para evitar isso, o postgres começará a emitir avisos e, eventualmente, desligará e se recusará a iniciar novas transações, se necessário:

    Se, por algum motivo, o autovacuum falhar ao limpar XIDs antigos de uma tabela, o sistema começará a emitir mensagens de aviso como esta quando os XIDs mais antigos do banco de dados atingirem dez milhões de transações a partir do ponto de contorno:

    WARNING:  database "mydb" must be vacuumed within 177009986 transactions 
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb".

    (Um VACUUM manual deve corrigir o problema, conforme sugerido pela dica; mas observe que o VACUUM deve ser executado por um superusuário, caso contrário, ele falhará ao processar os catálogos do sistema e, portanto, não poderá avançar o datfrozenxid do banco de dados.) Se esses avisos forem ignorados, o sistema será encerrado e se recusará a iniciar novas transações quando houver menos de 1 milhão de transações restantes até a finalização

    Em outras palavras, "transações que estavam no passado parecem estar no futuro" e "perda de dados" são totalmente teóricas e não serão causadas pelo retorno do ID da transação na prática.

    • 10

  2. O bloco que você colou parece responder à pergunta. Tudo depende da lógica que é usada para ocultar transações 'futuras'.

    O contador de ID da transação (XID) é limitado a 32 bits e, se atingir o próximo número, em vez de substituir a antiga transação máxima, ele começa do zero.

    Bem, agora é zero, então o PostgreSQL está escondendo todas as transações > 0 dele. Portanto, embora a transação nº 2.147.483.633 tenha ocorrido 20 segundos atrás, o PostgreSQL acredita que isso não acontecerá por mais 2.147.483.633 transações.

    • 5

relate perguntas