Quinta-feira, 31 de janeiro de 2008 às 08h30

MARIA, o novo Storage Engine do MySQL!

Faltam -1 dias! Inscreva-se agora! O maior encontro de profissionais web da américa latina.

Este artigo tem um caráter diferente de todos os outros que já publiquei aqui no iMasters. Uma das características de meus artigos é a de passar primeiramente todo o conceito e posteriormente mostrar como se faz na prática, com as imagens. Não deixarei de mostrar a prática, mas nesse, como se trata de uma feature digamos, fresquinha, buscarei explicar primeiramente toda a necessidade que levou à sua implementação e depois alguma prática.

Falo do mais novo Stored Engine, anunciado por um dos pais do MySQL, Michael "Monty" Widenius, que tem o nome de sua terceira filha, MARIA. O MARIA foi anunciado no tão esperado blog de Monty que demorou mas conseguiu criar o seu blog chamado "Monty Says". Neste mesmo blog ele salienta que "MARIA é um storage engine que ele (Monty), Guilhem, Sanja e Sergei vieram trabalhando nas últimas dois anos". Para mais detalhes sobre o que disse Monty no anuncio do MARIA, acesse seu blog e também o Planet MySQL.

O MARIA é uma proposta interessante e o interesse da implementação deste engine vem dos problemas que ocorrem com MyISAM com crash-recovery, que é um recurso bem interessante para a recuperação de danos à estrutura de dados, baseado em logs, bem utilizada pelo InnoDB, por exemplo.

O MARIA, será muito bem vindo para substituir o MyISAM pois tem características as quais são bastante aguardadas. A promessa é manter os recursos do engine anterior como a rapidez na leitura, mas adicionando algumas outras features, tais como:

Recovery Support

Um grande problema com banco de dados que utilizam o engine MyISAM, é o crash do banco de dados. Uma queda abrupta do sistema com, por exemplo, uma queda de energia pode comprometer tabelas (isso pode acontecer até com o ORACLE). Pensando nisso é, Monty e seus amigos trabalham no MARIA para tentar minimizar o estrago quando o SGBD retornar ao trabalho.

A primeira coisa a pensar é: "Usaremos o MARIA com a mesma normalidade na qual utilizávamos o MyISAM, só que, agora com mais segurança". Vejamos um exemplo com MyISAM (esse exemplo foi exibido na Linux Conference Australia durante uma mini-conferência do MySQL):

mysql > drop table if exists t1;
Query OK, 0 rows affected (1.14 sec)

mysql > create  table t1 (id int, b longblob) engine=myisam;
Query OK, 0 rows affected (0.00 sec)

mysql > insert into t1 values (1, repeat('a',1000000));
Query OK, 1 row affected (0.02 sec)

mysql > insert into t1 select * from t1;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;
Query OK, 2 rows affected (0.10 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;
Query OK, 4 rows affected (0.13 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;
Query OK, 8 rows affected (0.26 sec)
Records: 8  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;
Query OK, 16 rows affected (1.17 sec)
Records: 16  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;
Query OK, 32 rows affected (2.13 sec)
Records: 32  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;
Query OK, 64 rows affected (4.77 sec)
Records: 64  Duplicates: 0  Warnings: 0

mysql > insert into t1 select * from t1;

Bom, nesse ponto, enquanto o servidor MySQL se ocupada de inserir os dados do último INSERT, em outro terminal, entramos com o comando de interrupção abrupta do MySQL para causar o crash:

$ kill -9 `pgrep mysqld`

Acabamos de causar um desastre, pois se olharmos no outro terminal, aquele que se ocupava com a conexão ao MySQL Server que por sua vez se ocupava com o INSERT, teremos a seguinte mensagem:

ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql > exit
Bye

Então, acompanhando a lógica de raciocínio, temos que iniciar o MySQL, pois o crash, mesmo que simulado, já ocorreu. Após iniciar o servidor, utilizaremos o CHECK TABLE para checagem da tabela, como segue abaixo:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.23-maria-alpha Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql > check table t1;
+---------+-------+----------+-----------------------------------------------------------+
| Table   | Op    | Msg_type | Msg_text                                                  |
+---------+-------+----------+-----------------------------------------------------------+
| test.t1 | check | warning  | 1 client is using or hasn't closed the table properly     | 
| test.t1 | check | warning  | Size of datafile is: 256004096       Should be: 128002048 | 
| test.t1 | check | error    | Record-count is not ok; is 256   Should be: 128           | 
| test.t1 | check | warning  | Found 256 parts                Should be: 128 parts       | 
| test.t1 | check | error    | Corrupt                                                   | 
+---------+-------+----------+-----------------------------------------------------------+
5 rows in set (0.62 sec)

Podemos facilmente observar que a tabela foi corrompida com a queda do servidor abruptamente durante um trabalho de inserção de dados. Fazendo exatamente a mesma coisa, só que agora com tabelas MARIA, podemos constatar ao final que teremos esse resultado:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.23-maria-alpha Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql > check table t1;
+---------+-------+----------+----------+
| Table   | Op    | Msg_type | Msg_text |
+---------+-------+----------+----------+
| test.t1 | check | status   | OK       | 
+---------+-------+----------+----------+
1 row in set (0.73 sec)

Full Logging: O Full Logging na versão MARIA é mais abrangente, registrado declarações tais como CREATE, DROP, RENAME e o mais interessante, o TRUNCATE. Os formatos de linhas são aqueles que já existem no MyISAM e mais alguns específicos do MARIA (PAGES on transactional tables).

Ao criar uma tabela MARIA no MySQL, 3 arquivos também serão citados no diretório de dados, dentro do banco de dados ao qual as tabelas pertencem:

mysql> CREATE TABLE maria (id int) ENGINE=Maria;
  • maria.frm -- o arquivos .frm que é o padrão, contendo a definição da tabela;
  • maria.MAD -- o arquivos de dados dessa tabela;
  • maria.MAI -- o arquivo de índice dessa tabela.

Em adição a isso, são criados mais dois arquivos no mesmo diretório:

maria.log.xxxxxxx que é um arquivo de log e o maria_log_control que armazena informações dos diferentes arquivos de log que estão sendo utilizados no momento.

Conclusão

O novo Storage Engine pode ser "degustado" em sua fase ainda bem inicial, no MySQL 5.1.23 Download, mas ainda não aconselho a utilização do mesmo em produção. Torço para que seja mais uma inovação dos recursos do MySQL.

Fiquem atentos, muitas coisas estão por vir, Happy MySQL'ing!

1 comentário

 Helton Eduardo Ritter
01/02/2008 08h07

ótimo!

Não vejo a hora de poder usar essa nova engine em ambiente de produção. Obrigado pela boa notícia.

Cancelar resposta

Qual a sua opinião?

Faça login abaixo ou cadastre-se rapidamente.


Sobre o Autor
Wagner Bianchi é Tecnólogo em Gerenciamento de Banco de Dados pela Faculdade Infórium de Tecnologia, cursando o MBA em Administração de Empresas pela Fundação Getúlio Vargas, Consultor em Desenvolvimento de Sistemas/Banco de Dados, Analista de Sistemas em projetos OpenSource e especialista em SGBD MySQL. Atua também como Analista de Sistemas em Projetos da UFMG/ICEX, onde participa do desenvolvimento de produtos voltados para a área de CMS e Gestão da Informação. Certificado MySQL 5.0 Developer (CMDEV I e II), Certificado MySQL 5.0 Database Administrator I (CMDBA I) e MCDBA.

2001 - iMasters FFPA Informática Ltda - Todos os direitos reservados.