Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Entre os recursos dos produtos de gerenciamento de bancos de dados que mais chamam a atenção de qualquer administrador de bancos de dados (DBA) estão as inovações realizadas nas áreas de escalabilidade e alta-disponibilidade. Para o MySQL, a escalabilidade, ou Scale-Out, é um conceito que está presente desde a sua concepção e utilização em maior escala em meio ao pacote denominado LAMP (Linux, Apache, MySQL, PHP/Perl/Phynton). Isso antes do produto penetrar com muita força em organizações de pequeno, médio e grande porte, para armazenar informações produzidas por usuários, operadores dos mais variados tipos de sistemas como ERP, CRM, WMS, EDI e outros.

Fato é que há muito se fala em replicação de dados entre servidores de bancos de dados localizados em máquinas diferentes e/ou geograficamente posicionadas em pontos diferentes para se obter redundância dos dados e um pouco do conceito de alta-disponibilidade. Hoje em, dia são muitas as empresas que utilizam o MySQL tanto para sistemas menores quanto para sistemas de missão crítica (aqueles que não podem parar e são de suporte 24x7 às operações). As empresas confiam no produto MySQL por saber que por trás do mesmo existe uma empresa sólida e com anos de experiência na engenharia de softwares para gestão e armazenamento de dados.

Um dos desafios observados seria escalar o ambiente horizontalmente, com máquinas baratas (como manda o conceito de escalabilidade horizontal) e configurar tais servidores de bancos de dados MySQL em uma tolopogia de replicação que mais interessa à regra de negócios do cliente e não deixar que a sincronização da informação entre os servidores chamados de MASTER e SLAVE conte com o fator “delay”, que é um atraso já conhecido pelo usuário.

Isso é um pouco preocupante quando se tem uma estratégia de dividir as escritas de dados (INSERT, DELETE, REPLACE e UPDATE) para o servidor MySQL MASTER e as leituras (SELECT) para o servidor SLAVE. Mesmo não sendo esse um problema muito costumeiro, ou seja, que não acontece em todas as implementações, é de se preocupar quando o cliente precisa de dados para tomar as suas decisões e toda a informação necessária para executar tal processo ainda está no servidor MySQL MASTER e não foi replicada para um dos servidores MySQL SLAVE, que é o servidor de leitura de dados.

Perceba que estamos dissertando sobre a replicação nativa do MySQL, aquela que por padrão é assíncrona, ou seja, é um processo independente que não impede que as outras tarefas continuem sendo realizadas. Por isso, poderá atrasar na entrega dos dados devido a alguns fatores como latência da rede e ocupação extrema dos servidores de bancos de dados MySQL envolvidos na topologia.

Para resolver o problema do delay ou atraso na entrega dos dados ao MySQL SLAVE, o MySQL criou um plugin que possibilita o recurso denominado semi-synchronous replication que é um pouco diferente do sistema de replicação nativo, embora se utilize dele. Antes de nos aprofundarmos no assunto, temos que passar pelos conceitos fundamentais que giram em torno do recurso de replicação entre servidores de bancos de dados MySQL para entendermos todos os pontos discutidos até aqui. Serão abordados neste artigo os principais conceitos que norteam o DBA para a implementação do sistema de replicação assíncrona e semi-síncrona com servidores de bancos de dados MySQL na versão 5.5. Em um próximo artigo previsto para a edição seguinte, aplicaremos estes conceitos a um estudo de caso que buscará explorar algumas técnicas relacionadas com a escalabilidade horizontal com servidor de bancos de dados MySQL.

Conceitos básicos da replicação assíncrona

Não é nenhuma novidade para os profissionais que lidam com bancos de dados que os produtos de gerenciamento de bases de dados, de alguma forma, ofereçam suporte a algum tipo de replicação de dados entre servidores de bancos de dados. Muitos deles replicam dados de uma instância para ela mesma ou para várias outras disponíveis em pontos geograficamente posicionados.

A real intenção de uma topologia de replicação pode passar por vários motivos e estratégias, desde se buscar uma solução de failover manual (operação na qual você passa a apontar os seus aplicativos para outro servidor, localizados em meio a uma topologia de replicação) facilitado, ter um backup do banco de dados para dar suporte ao principal sistema da empresa ou ainda realizar a estratégia de divisão de carga de trabalho (também conhecido por workload), dividindo leituras e escritas em bases de dados localizadas em servidores diferentes. Tanto uma estratégia de backup quanto aquela em que se deseja obter menos workload em uma só instância do MySQL, contemplará uma boa opção para um failover manual.

O servidor de bancos de dados MySQL é uma boa opção desde as suas primeiras versões por dar suporte a este recurso de forma assíncrona, ou seja, não existe uma forma de se programar ou controlar quando o evento de replicação acontecerá. Naturalmente, o evento de sincronização de dados ocorre de maneira muito rápida, de forma quase instantânea quando o SLAVE ou o servidor escravo se conecta ao servidor MASTER para verificar quais são as novas entradas no log binário desde a última leitura.

Perceba que o servidor MASTER deverá ter o log binário habilitado e um usuário para que a replicação se torne uma realidade entre os servidores de bancos de dados envolvidos na topologia. O SLAVE se conectará ao MASTER através de um usuário XPTO, tendo este usuário somente o privilégio REPLICATION SLAVE para ler as últimas entradas do log binário. Os comandos lidos no MASTER são armazenados no SLAVE em um arquivo denominado “relay.log” e seu conteúdo executado para realização da sincronização. A execução das consultas que modificaram dados no MASTER e agora se encontram no relay.log do SLAVE é realizada por 2 threads que se encontram permanentemente rodando no servidor SLAVE:

• THREAD I/O: essa é a thread responsável por estabelecer um canal de comunicação entre o servidor SLAVE e o servidor MASTER para que sejam trafegadas as últimas consultas que alteraram o banco de dados no MASTER e que precisam ser replicadas para o SAVE. Uma vez que as consultas são lidas no log binário do servidor MASTER, elas são depositadas no relay.log no servidor SLAVE;

• THREAD SQL: essa thread é a responsável por ler o conteúdo do ...