- Pelo que li sobre o WAL, é um arquivo somente de acréscimo, onde todas as operações no banco de dados são gravadas antes que as operações sejam realmente executadas nos dados.
- Há também o conceito de "ponto de verificação", que é quando o banco de dados realmente grava os dados no disco a partir da memória e acrescenta uma entrada de ponto de verificação especial no final do WAL.
- Agora, se o banco de dados travar em algum momento, ele poderá ler o WAL a partir da última entrada do ponto de verificação e refazer todas as operações subsequentes.
- Mas como o BD garante que a entrada do WAL no ponto de verificação e a liberação real dos dados no disco aconteçam de forma transacional?
- E se os dados forem liberados, mas o banco de dados travar antes que a entrada do ponto de verificação seja feita no WAL?
- Por outro lado, se o WAL for modificado primeiro, o que acontece se o banco de dados travar após a entrada do ponto de verificação, mas antes que os dados sejam realmente liberados?
Por exemplo, considere o seguinte caso:
- Temos uma tabela fictícia
Person(name, age, salary). - Tem uma entrada
John, 25, 100. - No momento T1, uma nova transação chega
UPDATE Person SET salary += 100 WHERE name='John'. - Suponha que antes do T1, todos os dados foram liberados e a entrada do ponto de verificação foi anexada ao WAL.
- Agora, após essa transação, o BD primeiro anexará o log com a instrução de transação exata
UPDATE Person SET salary += 100 WHERE name='John'. - Agora os dados se tornam
John, 25, 200. - Então, depois de algum tempo, digamos que o banco de dados decida liberar os dados para o disco no momento T2.
- Então, no momento T3 (logo após T2), o BD tenta gravar a entrada do ponto de verificação no WAL.
- Entretanto, antes que pudesse terminar, houve uma queda de energia entre T2 e T3.
- Agora, quando o banco de dados for reiniciado e tentar se recuperar, ele notará que há uma transação após o último ponto de verificação e tentará executá-la:
UPDATE Person SET salary += 100 WHERE name='John' - Mas como a transação já foi executada antes da queda, desta vez o salário assumirá o valor 300, embora devesse ser 200.
Como o banco de dados evita essas atualizações redundantes durante a recuperação?
Parece que você entendeu mal.
O WAL não contém
UPDATE Person SET salary += 100 WHERE name='John', então ele não "executa" isso novamente e obtém o resultado errado.Ele contém apenas novas versões de quaisquer linhas/páginas que foram modificadas por essa declaração. Então, tudo o que ele precisa fazer para fazer o checkpoint é gravar todas essas páginas no arquivo principal. Ele sempre pode fazer isso de novo, pois é idempotente, então um segundo roll-forward na recuperação não afeta nada.