O princípio de realização da atomicidade, consistência e durabilidade da transação

Prefácio

Todo mundo sabe que as transações têm quatro características:

• Atomicidade

  Atomicidade significa que toda a transação do banco de dados é uma unidade de trabalho indivisível. Somente se todas as operações do banco de dados na transação forem executadas com sucesso, a transação inteira será considerada bem-sucedida. Se a execução de qualquer instrução SQL na transação falhar, a instrução SQL que foi executada com êxito também deve ser cancelada e o estado do banco de dados deve retornar ao estado anterior à execução da transação.

• Consistência

  Consistência significa que uma transação transforma o banco de dados de um estado para o próximo estado consistente. Antes do início e após o término da transação, as restrições de integridade do banco de dados não foram destruídas.

• Isolamento

  O impacto de uma transação não é visível para outras transações até que a transação seja confirmada - isso é obtido por meio de bloqueio.

• Durabilidade (durabilidade)

  Depois que a transação é confirmada, o resultado é permanente. Mesmo se ocorrer uma falha, como um tempo de inatividade, o banco de dados pode recuperar dados.

Para a realização do isolamento, você pode consultar este meu artigo: Uma breve análise dos bloqueios e transações do InnoDB

Este artigo fala principalmente sobre como os outros três recursos são alcançados: por meio do refazer e desfazer do banco de dados . Se este artigo não contém instruções especiais, o padrão se refere ao mecanismo de armazenamento InnoDB do mysql.

alcançar

Conhecimento básico

1. O status físico de cada página (página) muda registrada no log de redo
2. O log de desfazer e refazer o registro do log físico não é o mesmo, é um log lógico. Pode-se considerar que quando um registro é excluído, um registro de inserção correspondente é registrado no log de undo, e vice-versa, quando um registro é atualizado, ele registra um registro de atualização correspondente.
3. LSN é chamado de número de seqüência de log (número de seqüência de log) .No mecanismo de armazenamento innodb, lsn ocupa 8 bytes. O valor de LSN aumentará gradualmente conforme o registro é gravado. A operação de atualização na transação irá gerar um novo LSN. LSN não existe apenas no log de redo, mas também existe na página de dados.
4. checkpoint checkpoint , o que significa quando páginas sujas são gravadas no disco

Processo geral

Ambos os logs e dados são modificados no buffer e então sincronizados com o disco.

1. Após o início da transação, se os dados modificados não estiverem no buffer de log, eles serão lidos do disco para o buffer de log

2. Antes de modificar os dados na memória, grave os dados originais no log de desfazer

3. Modifique a página de dados na memória, registre o LSN na página de dados da memória e chame-o de data_in_buffer_lsn por enquanto

4. Escreva redo log para redo log no buffer enquanto modifica a página de dados (quase ao mesmo tempo), e registre o LSN correspondente, que é chamado redo_log_in_buffer_lsn por enquanto;

5. Liberação de registro e liberação de dados

   As regras para liberação de log são

   • Quando a ação de confirmação é emitida

   • Escove uma vez por segundo

   • Quando a memória usada no buffer de log excede a metade

   • Quando há um posto de controle

   As regras para liberação de dados são

   • Quando há um posto de controle

   O número de liberação de log é maior do que a liberação de dados. Além disso, mesmo durante o ponto de verificação, o innoDB ** garantirá que o log precisa ser escrito antes de gravar os dados. Este método é chamado de registro Write-Ahead (Registro Write-Ahead, WAL). ** O mecanismo de armazenamento InnoDB garante a integridade da transação pré-gravando o log.

   O motivo pelo qual o método de registro write-ahead pode garantir a integridade é que existem LSNs nas páginas de registro e dados, e a ordem dos registros de dados nas páginas de registro e dados pode ser comparada por meio do LSN. O arquivo de log é o núcleo real.

Instância

Fonte: análise detalhada do log de transações do MySQL (redo log e undo log)

Na figura acima, as linhas horizontais de cima para baixo representam: o eixo do tempo, o LSN registrado na página de dados no buffer (data_in_buffer_lsn), o LSN registrado na página de dados no disco (data_page_on_disk_lsn) e o LSN registrado no redo log do buffer. redo_log_in_buffer_lsn), o LSN registrado no arquivo de redo log do disco (redo_log_on_disk_lsn) e o LSN registrado pelo ponto de verificação (checkpoint_lsn).

Supondo que no início (12h00), todas as páginas de log e de dados tenham sido liberadas e o LSN do ponto de verificação também tenha sido registrado.Neste momento, seus LSNs estão completamente consistentes.

Suponha que uma transação seja iniciada neste momento, e uma operação de atualização seja executada imediatamente. Após a execução ser concluída, a página de dados e o registro de redo no buffer registram o valor LSN atualizado, que é considerado 110. Neste momento, se você executar show engine innodb status para visualizar o valor de cada LSN, ou seja, o status da posição em ① na figura, o resultado será:

log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at

Em seguida, uma instrução de exclusão foi executada e o LSN aumentou para 150. Espere até 12:00:01, acione as regras de liberação de log de redo (uma das quais é que a frequência de liberação de log padrão controlada por innodb_flush_log_at_timeout é de 1 segundo), então o LSN no arquivo de log de redo no disco será atualizado para e redo log O LSN de no buffer é o mesmo, então eles são todos iguais a 150. Nesse momento, mostrar o status do innodb do motor, que é a posição de ② na figura, resultará em:

log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at

Depois disso, uma instrução de atualização é executada e o LSN no cache aumentará para 300, que é a posição de ③ na figura.

Supondo que o ponto de verificação apareça posteriormente, que é a posição de ④ na figura, conforme mencionado anteriormente, o ponto de verificação acionará a página de dados e a limpeza da página de registro, mas leva um certo tempo para ser concluída, portanto, antes que a limpeza da página de dados seja concluída, verifique O LSN do ponto ainda é o LSN do último ponto de verificação, mas neste momento o LSN da página de dados e da página de registro no disco aumentou, a saber:

log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at

No entanto, o tamanho do log liberado e as páginas liberadas não podem ser determinados, porque a liberação do log pode ser mais rápida do que a liberação de dados, ou pode ser igual ou mais lenta. No entanto, o mecanismo de ponto de verificação protege que a velocidade de liberação de dados é mais lenta do que a liberação de log: quando a velocidade de liberação de dados excede a liberação de log, a liberação de dados será temporariamente interrompida e aguardando que o progresso de liberação de log exceda a liberação de dados.

Quando a página de dados e a página de registro são esvaziadas, ou seja, quando a posição ⑤ é alcançada, todos os LSNs são iguais a 300.

Com o passar do tempo, chega a 12:00:02, que é a posição na figura, que aciona a regra de liberação do log, mas, neste momento, o LSN do log no buffer é o mesmo que o LSN do log no disco, então a descarga do log não é realizada. Disco, ou seja, todos os lsns são iguais no status show engine innodb neste momento.

Em seguida, uma instrução de inserção é executada, assumindo que o LSN no buffer aumentou para 800, que é a posição ⑦ na figura. Neste momento, o tamanho e a posição dos vários LSNs são os mesmos.

Execução subsequente da ação de envio, ou seja, posição ⑧. Por padrão, a ação de envio acionará a liberação de log, mas não acionará a liberação de dados, portanto, o resultado de show engine innodb status é:

log sequence number = log flushed up to > pages flushed up to = last checkpoint at

Finalmente, com o passar do tempo, o checkpoint reapareceu, ou seja, a posição ⑨ na figura. No entanto, este ponto de verificação não acionará a limpeza do log, porque o LSN do log foi sincronizado antes de ocorrer o ponto de verificação. Supondo que a velocidade de flash dos dados seja extremamente rápida desta vez, ela será concluída em um momento e a mudança de status não pode ser capturada, então o resultado de mostrar status do innodb do motor será o mesmo LSN.

restaurar

A estratégia de recuperação do mysql é:

1. Ao recuperar, primeiro refaça todas as transações de acordo com o redo, incluindo transações não confirmadas
2. Em seguida, reverta as transações não confirmadas de acordo com desfazer.

Por meio dessa estratégia, a atomicidade, consistência e durabilidade da transação são garantidas.

Além disso, o mecanismo de ponto de verificação é introduzido e, ao restaurar, você só precisa restaurar a partir da posição do ponto de verificação.

Impressões

1. Muitos conteúdos na Internet podem ser imprecisos. Mesmo este artigo que escrevi pode ter imprecisão. A melhor maneira de resolver esse problema é ler o código-fonte.
2. Técnicas diferentes podem alcançar resultados diferentes, mas os princípios básicos são frequentemente interligados, e esses princípios básicos são geralmente construídos com base no conhecimento sobre
3. O conhecimento de aprendizagem pode aprender diferentes profundidades. Depois de ler " MySQL Technical Insider: InnoDB Storage Engine ", você pode obter uma compreensão geral do uso do mysql, mas o entendimento não é profundo. Com a redação desses dois artigos, o entendimento do MySQL é mais aprofundado Alguns, se você precisar ir mais fundo, realmente precisam olhar o código-fonte.Isso parece que leva mais tempo. Portanto, você precisa saber qual nível você precisa entender e usar o tempo limitado para fazer coisas mais econômicas . A escolha é muito importante.

dados

1. Estudo aprofundado das transações MySQL: o princípio de realização dos recursos do ACID
2. Análise detalhada dos registros de transações do MySQL (redo log e undo log)
3. https://blog.csdn.net/suerge_storm/article/details/90484944
4. https://blog.csdn.net/qq_41151659/article/details/99559397

Finalmente

Se você gosta do meu artigo, pode seguir minha conta pública (Programador Mala Tang)

Revisão de artigos anteriores:

1. O princípio de realização da atomicidade, consistência e durabilidade da transação
2. Como exercitar sua memória
3. Explicação detalhada do processo de solicitação de CDN
4. Reflexões sobre o desenvolvimento da carreira de programadores
5. A história do serviço de blog sendo destruída
6. Técnicas comuns de cache
7. Como conectar-se com eficiência a pagamentos de terceiros
8. Versão concisa da estrutura de gim
9. Pensando em revisão de código
10. Uma breve análise dos bloqueios e transações do InnoDB
11. Tipo de recomendação do editor de Markdown