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
ByeEntã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;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!
Não vejo a hora de poder usar essa nova engine em ambiente de produção. Obrigado pela boa notícia.
2001 - iMasters FFPA Informática Ltda - Todos os direitos reservados.