Entenda o Storage Engine Blackhole
Por Wagner Bianchi
Desde alguns anos atrás, o
servidor de bancos de dados MySQL está baseado em um padrão em que, ao se
definir um projeto, primeiro se busca as características do sistema ou
subsistema que será desenvolvido, levantando informações em relação ao seu back-end e depois que tais pontos são
definidos, o administrador de bancos de dados pode definir qual Storage Engine
utilizar.
Os Storage Engines não passam de módulos que podem ser plugados ao MySQL para que certas características como possuir
transação ou não, integridade referencial ou não, MVCC, ACID, leitura e
escrita sequêncial e outras mais que sabemos que motores de armazenamentos
nativos como MyISAM, Archive, InnoDB, Federated, Memory e CSV possuem em uma
instalação padrão do servidor de bancos de dados de código fonte aberto mais
utilizado do mundo.
O poder que o MySQL deu aos seus usuários, os administradores de bancos de
dados, de escolherem quais motores de armazenamento ou Storage Engines utilizar,
atribuiu a ele o título de Plugable
Database, ou seja, você poderá escolher o motor que deseja utilizar em seu
projeto, considerando as suas principais características, para que, de forma
transparente, este gerencie as tabelas de seu banco de dados.
Além dos vários Storage Engines que estão disponíveis em uma instalação do
MySQL, que são os motores chamados de nativos, ainda podemos observar várias
outras empresas que escrevem seus próprios motores e plugam estes no servidor de bancos de dados MySQL, oferecendo
funcionalidades bem diferentes daquelas existentes em motores nativos. Destes
podemos citar Infobrigth, PBXT, XTradb, Drizzle, Amazon AW3, Google e vários
outros.
Este artigo surgiu da vontade de trazer à público uma dúvida levantada por
vários profissionais que me enviam por e-mail a mesma pergunta ao enviar o
comando SHOW ENGINES, através do mysql client ou mesmo
através de qualquer GUI: "O QUE É ESSE TAL DE BLACKHOLE?". A
resposta a essa pergunta se inicia agora.
Perceba que na saída do comando
SHOW ENGINES, temos a coluna comment que nos descreve as características, bem a
"grosso modo" em relação a cada motor nativo do MySQL. Quando chegamos
na descrição ou comentário na linha do BLACKHOLE, percebemos que, tudo que
escrevermos para uma tabela controlada por este motor de armazenamento vai
desaparecer. UAU?!?!?
Mas, para que serve isso? Muito bem!
mysql>
CREATE TABLE tab_blackhole (
->
id int not null auto_increment primary key,
->
nome char(40)
-> ) ENGINE=BLACKHOLE;
Query OK,
0 rows affected (0.00 sec)
mysql>
insert into tab_blackhole set nome ='IMASTERS';
Query OK,
1 row affected (0.01 sec)
mysql>
select id, nome from tab_blackhole;
Empty set
(0.00 sec)
A
tabela acima foi criada no banco de dados "test". Como sabemos que ao
criar um banco de dados no MySQL, um novo diretório é criado sob o DATADIR ou
diretório de dados, dentro do diretório "test", localizado em /var/lib/mysql,
foi criado um arquivo nome_da_tabela.frm. Para verificar as variáveis de
ambiente que estão setadas no arquivo de configurações my.cnf ou my.ini,
utilize o utilitário de linha de comando que é disponibilizado na insta;ação do
servidor de bancos de dados MySQL, my_print_defaults, que recebe como
parâmetro o agrupamento que desejamos verificar:
shell>
my_print_defaults mysqld
--default-character-set=latin1
--server-id=1
--tmpdir=/tmp
--basedir=/usr
--datadir=/var/lib/mysql
--key_buffer=512M
--read_buffer_size=32M
--read_rnd_buffer_size=16M
--sort_buffer_size=32M
--join_buffer_size=32M
--max_allowed_packet=128M
--table_cache=4000
--sort_buffer_size=512K
Em um
ambiente de replicação entre servidores de bancos de dados MySQL, tal Storage
Engine poderá ser muito útil quando necessitamos tirar dos usuários em um
determinado local as chances de lerem ou alterarem as informações do banco de
dados. É bem verdade que se este mesmo usuário "mexer" mais um pouco
ele acaba buscando alguma solução “sacana” para fazer alguma bagunça, mas com
algum planejamento, o BLACKHOLE lhe ajudará com este feito de esconder os dados
de usuários mal ou bem intencionados.
Imagine que a tabela que criamos no exemplo, a tabela tab_blackhole receba
vários dados e estes atualizam o estado do banco de dados, ou seja, alteram de
alguma forma os dados. Levando em consideração que o log binário esteja
habilitado no arquivo de configuração – my.cnf ou my.ini - por causa do esquema
de replicação, todos os comandos que atualizam o banco de dados vão ser
escritos neste log, sendo que, ao serem escritos, conseqüente mente serão lidos
pelo servidor SLAVE que por sua vez pode contar com tabelas MyISAM ou InnoDB,
estas que mantém os dados de forma normal. Localmente não temos os dados, já
que optamos por utilizar tabelas controladas pelo Storage Engine Blackhole, mas
no servidor de bancos de dados SLAVE nós temos acesso a estes.
No caso de possuirmos tabelas controladas pelo Storage Engine Blackhole em
nosso banco de dados, saiba que não faz sentido contar com TRIGGERS de DELETE
ou UPDATE, pois, nesta tabela não há linhas para atualizar ou excluir. O evento
da TRIGGER não é disparado, diferentemente de TRIGGERS para INSERT, que
trabalha como esperado. Para algumas operações em um ambiente replicado, este
motor de armazenamento poderá contribuir para o aumento de performance.
No próximo artigo, vamos falar mais de recursos interessante do MySQL.
