Diário de transações MySQL

Você está definitivamente no caminho certo aqui.

Sempre que o InnoDB faz uma transação que precisa ser confirmada, ela é feita como uma confirmação de duas fases. A transação é gravada primeiro nesses logs. Então, eles são comprometidos a partir daí.

Isso ajuda muito no caso de travamento do MySQL ou travamento do servidor.

Quando você reinicia o mysql, todas as entradas não confirmadas em ib_logfile0 e ib_logfile1 são reproduzidas como parte da recuperação de falha do InnoDB para trazer o InnoDB para um estado harmonioso (Estas são partes consistentes e duráveis de Conformidade com ACID )

Se você excluir ib_logfile0 e ib_logfile1 e iniciar o mysql, qualquer transação não confirmada contida nesses arquivos será perdida. Durante o ciclo de recuperação de falhas, se os arquivos de log estiverem ausentes, eles serão regenerados com base no innodb_log_file_size contexto.

Consulte a Documentação do MySQL para obter uma explicação do InnoDB .

@karatedog a parte MVCC do InnoDB acontece dentro do tablespace do sistema, mais conhecido como ibdata1. Quaisquer dados que pareçam estar antes do início de uma transação são registrados para permitir que outras pessoas que acessam as linhas necessárias tenham uma visão dos dados antes que qualquer atualização seja imposta. Isso permite o que é chamado de REPEATABLE-READ. Isso se enquadra no I de conformidade com ACID, ou seja, Isolamento. Escrevi posts sobre isso no DBA StackExchange em relação a vários cenários em que o isolamento de transações é bom, ruim ou feio.

Quanto ao MyISAM, a recuperação de falhas não é automática. Ele trava com bastante facilidade . É por isso que o comando SQL REPAIR TABLE existe. É também por isso que o utilitário MySQL myisamchk tem o -r opção para executar REPAIR TABLE para tabelas MyISAM que não estão online.

MariaDB e Aria houve tentativas de criar um mecanismo de armazenamento seguro contra falhas como substituto do MyISAM.