InnoDB

InnoDB é um mecanismo de armazenamento para o MySQL.^[1] O MySQL 5.5, e versões posteriores, o utilizam por padrão. Ele fornece as funcionalidades padrões de transação complacentes com ACID, juntamente com o suporte a chave estrangeira (Integridade Referencial Declarativa). Ele é incluso como padrão na maioria dos binários distribuídos pela MySQL AB, sendo a exceção algumas versões OEM.

O InnoDB tornou-se um produto da Oracle Corporation após sua aquisição do Innobase Oy em outubro de 2005.^[2] O software possui uma licença dual e é distribuído sob a GNU General Public License, mas também pode ser licenciado para partes que desejam combinar o InnoDB em software proprietário.^[3]

MariaDB e Percona Server usam uma bifurcação do InnoDB chamada XtraDB por padrão. XtraDB é mantido pela Percona. Alterações no InnoDB da Oracle são regularmente importadas no XtraDB e algumas correções de bug e funcionalidades extras são adicionadas.

Sua principal melhoria diante do mecanismo de armazenamento MyISAM é oferecer transações do tipo ACID.^[4]

Para alcançar a durabilidade dos dados, precisamos armazenar todos os dados de transações no armazenamento do disco rígido. Mas considere, em um sistema ocupado, para cada confirmação de transação, se o InnoDB tentar liberar (gravar) dados para um disco de execução lenta, o que acontecerá ?, Então, como gerenciamos esta situação, onde precisamos armazenar cada dado de transação e em ao mesmo tempo mantendo o bom desempenho do sistema.

O InnoDB fornece a solução para esta situação, com base em seu sistema, você pode informar ao InnoDB quando deseja descarregar (gravar) dados no disco. Por exemplo, você pode dizer ao InnoDB para funcionar conforme mencionado abaixo:

O InnoDB suporta:

• Transações SQL e XA
• Espaços de tabela
• Chaves estrangeiras
• Índices de TEXTO COMPLETO, desde o MySQL 5.6 e MariaDB 10.0
• Operações espaciais, seguindo o padrão OpenGIS
• Colunas virtuais, apenas no MariaDB
• Buffer Pool - Mecanismo de gerenciamento de buffer de dados

A partir de agora será necessário entender bem como funcionam algumas estruturas do InnoDB, já que as tabelas geradas antes, agora serão controladas por um motor mais robusto, com integridade referencial, logs para suporte à transação, níveis de isolamento e muitos outros recursos que coloca o MySQL como uma opção robusta para uso crítico. Como padrão em mecanismo de gerenciamento de buffer o InnoDB faz uso extenso de gerenciamento de dados, o InnoDB Buffer Pool é uma estrutura que pode ser configurada através da variável innodb_buffer_pool_size e a quantidade de memória atribuída pode chegar a um número entre 70% e 80% da memória de um host.

Na configuração desta variável , deve-secuidar para que essa área não fique grande demais e então seja mal aproveitada pelos dados ; há fragmentação prevista.

Alguns recursos valiosos para evitar tal desproporção ao configurar o InnoDB Buffer Pool são as variáveis de status e também a saída do comando SHOW ENGINE INNODB STATUS.

Tanto um quanto o outro poderão orientar o administrador de bancos de dados a ajustar melhor o Buffer Pool. Abaixo, mostro uma parte muito importante da saída do comando SHOW ENGINE INNODB STATUS, que reporta toda a alocação de memória atual pelo InnoDB.

Segundo o manual online, 3/8 do Buffer Pool é destinado aos dados que pertencem à sublista de dados mais antigos; quando um novo dado chega ao buffer pool, ele é inserido em um ponto denominado “midpoint”, que é localizado no topo da sublista do final.

Isso é interessante, pois uma operação qualquer iniciada pelo usuário poderá ler tal dado de maneira sequencial chamada read-ahead, que automaticamente realizada pelo InnoDB.

As páginas de dados que são modificados em memória são registrados no log buffer pool, que de tempos em tempos realiza um processo denominado “flush”, atualizando os dados do disco com os dados da memória. Tudo que foi modificado dentro do buffer pool agora será gravado em disco.

Esse comportamento é gerenciado pelo InnoDB com base no valor configurado na variável de ambiente innodb_flush_log_at_trx_commit que tem como seus posíveis valores:

• 0, os logs em memória são escritos em nos arquivos em disco uma vez a cada segundo, mas nada é feito no momento do COMMIT (este que é registrado no transaction log ao final de cada transação realizada com sucesso);
• 1, os logs em memória são escritos nos arquivos em disco a cada COMMIT;
• 2, os logs são escritos para os arquivos de log em disco a cada segundo e a cada COMMIT.

Em um ambiente de replicação, recomenda-se que que a variável innodb_flush_log_at_trx_commit seja configurada com o valor 1 e também sync_binlog seja igual a 1. Isso fará com que as alterações estejam armazenadas no log binário o mais breve possível para que esta seja entregue ao servidor SLAVE.

Um outro fato que se deve tomar bastante cuidado é que, caso se configure tal variável igual o 0, dados poderão ser perdidos caso o sistema tenha um “crash” antes do próximo “flush”.

Referências

• Página oficial
• Mysqltutorial.org, InnoDB e outros tipos de tabelas em MySQL
• Not-so-well-known differences between MyISAM and InnoDB MySQL server storage engines
• The InnoDB Storage Engine, no manual do MySQL.
• InnoDB no manual do MySQL

Este artigo sobre banco de dados é um esboço. Você pode ajudar a Wikipédia expandindo-o. v d e