Técnicas de Replicação em MySQL em um Sistema com Banco de Dados Distribuído

em

1. Introdução

Em um sistema de banco de dados distribuídos, a replicação é uma estratégia de armazenamento de informações contidas em um banco de dados em locais distintos, mantendo cópias dos dados assegurando a redundância, alta disponibilidade e ou balanço das informações entre vários servidores de banco de dados sob uma rede de computadores.

A replicação deve ser um processo transparente para o usuário final em um sistema de dados, proporcionando validade no conjunto de dados.


2. Replicação no MySQL

A replicação mestre-escravo (master-slave) consiste em dois ou mais objetos onde um dos objetos é considerado o mestre no qual as operações de alterações e leitura de dados só poderão ser realizadas nele, cada objeto possui apenas um dono. No mesmo só existiram cópia primárias. Os objetos subsequentes, lembrando que poderá ser um ou mais, são os escravos e neles a operação permitida somente será a de leitura, este armazenará cópias secundárias. O fluxo de informações deste modelo de replicação seguirá sempre do nó objeto mestre aos objetos escravos, no caso de uma configuração de uma arquitetura mais simples, podendo ser desenvolvida uma arquitetura com o cascateamento entre nós escravos. Há também a possibilidade da aplicação de um nó que possua as duas funcionalidades, mestre e escravo. Uma desvantagem desta abordagem é que uma falha no objeto mestre ocorrerá em falha na replicação dos dados aos outros objetos escravos.
A replicação síncrona também chamada de Active Replication (AR) é um recurso somente presente no MySQL Cluster, foi usado anteriormente como um sinônimo para Hot Standby, ou seja replicação ativa é a mesma que replicação síncrona.


3. Replicação Síncrona

Na replicação síncrona, cada transação é dada como concluída quando todos os nós confirmam que a transação local foi bem sucedida, este recurso não está presente no MySQL 5.5 é uma característica encontrada no MySQL Cluster.


4. Replicação Assíncrona

A replicação assíncrona, operações de escrita local e de escrita distante são independentes.
O nó principal executa a transação enviando confirmação ao nó escravo encaminhando então a transação aos demais nós. O serviço de replicação não espera pela resposta do nó distante para autorizar a aplicação e aceitar as escritas seguintes. Este modo apresenta a vantagem de penalizar menos as aplicações. Como inconveniente, tem o fato de apresentar conjuntos de dados diferentes num dado instante e de não garantir a coerência dos dados a cada momento.
A replicação do MySQL, por padrão é assíncrona. O nó mestre escreve eventos em seu log binário, porém não há um controle da escrita em nós escravos, podendo resultar um failover em cascata, onde os recursos do nó que apresentou falha são igualmente distribuídos para todos os outros nós.


5. Replicação Semi-Síncrona

O MySQL 5.5 suporta uma interface para a replicação semi-síncrona através de um plugin.
A replicação semi-síncrona pode ser usada como alternativa de minimizar possíveis failover em relação ao modo assíncrono.
Um nó escravo indica ao seu mestre a capacidade de replicação semi-síncrona, ativando o mesmo modo no lado mestre, caso o mesmo esteja configurado para tal. Assim feito, ao ser executada uma transação de commit, o nó mestre espera até que pelo menos um nó escravo reconheça o recebimento de todos os eventos da transação ou até que o tempo limite preestabelecido ocorra, caso contrário, automaticamente o nó mestre voltará ao modo de replicação assíncrona, somente retornando ao modo semi-assíncrono quando pelo menos um nó escravo finalizar a escrita em log. O nó escravo reconhece o recebimento dos eventos de uma transação só após a escrita em seu log de retransmissão e que libere os dados para o disco. Enquanto o nó mestre está aguardando a confirmação de um nó escravo, ele não retorna para a sessão que realizou a transação, comprometendo as transações subsequentes.
O modo de replicação semi-síncrona deverá estar ativo em todos os nós, sendo eles mestres ou escravos, caso contrário o modo de replicação usado pelo mestre será assíncrona.
O bloqueio também ocorre após rollbacks que são escritos no log binário, que ocorre quando uma operação que modifica as tabelas não transacionais é revertida. A transação desfeita é registrada mesmo que ele não tem efeito para tabelas transacionais, pois as modificações nas tabelas não transacionais não podem ser revertidas e devem ser enviadas aos nós escravos.


6. Formatos de replicação

Como vimos anteriormente a replicação funciona com os eventos sendo gravados em um log binário lidos e em seguida executado nos nós escravos. Estes eventos são registrados em diferentes formatos de acordo com seu tipo.
O formato de replicação originalmente conhecido é chamado statement-based replication ou SBR em versões anteriores do MySQL somente este formato era conhecido.
Outro formato hoje é aplicado, chama-se row-based replication ou RBR, onde o nó mestre escreve eventos no log binário que indicam a modificação em linhas individuais de uma tabela.
O formato de escrito em log de um servidor é controlado pela configuração da variável de sistema binlog_format. Esta variável pode ser definida para a sessão (não vista pelas outras) ou em no escopo global. A mudança da mesma requer a reinicialização do serviço no servidor.
Os formatos de replicação têm diferentes problemas e limitações. Em uma ampla visão o formato misto pode ser o mais conveniente a ser usado, porém há a necessidade de se analisar as vantagens e desvantagens dos formatos SBR e RBR para determinar o uso nas necessidades específicas do usuário.


7. Granulosidade de replicação

Granularidade diz respeito ao nível de detalhe ou de resumo contido nas unidades de dados existentes. Quanto maior o nível de detalhes, menor o nível de granularidade. O nível de granularidade afeta diretamente o volume de dados armazenado e ao mesmo tempo o tipo de consulta que pode ser respondida.
No MySQL podemos usar três tipos de níveis de granulosidade na replicação, eles são Database-Level, Table-Level e Rule Application. Estes métodos são definidos através de variáveis definidas no nó mestre.
As opções de configuração em nível de banco de dados como --replicate-do-db e --replicate-ignore-db são verificadas primeiro, caso estas não existam são verificadas as opções em nível de tabela que são --replicate-do-table ou --replicate-wild-do-table, assim como --replicate-ignore-table ou --replicate-wild-ignore-table.
Mais especificamente no nível de banco de dados (Database-Level) ao avaliar as opções de replicação, o nó escravo começa verificando para ver se há algum --replicate-dodb ou --replicate-ignore-db a aplicar, caso a configuração seja feita utilizando --binlog-dodb ou --binlog-ignore-db, o processo é semelhante, mas as opções são verificadas no nó mestre. Este procedimento de verificação de replicação em nível de banco de dados é mostrado na figura 1 e detalhado na tabela 1:
Figura 1. Procedimento da Replicação Database-Level
 Figura 1. Procedimento da Replicação Database-Level
Tabela 1. Passos da execução em Database-Level
1. Há a opção --replicate-do-db?
· Se sim – O banco de dados corresponde a nenhum deles?
· Se sim – Execute a atualização e saia.
· Se não – Vá para a etapa 2.
2. Há a opção --replicate-ignore-db?
· Se sim – O banco de dados corresponde a nenhum deles?
· Se sim – Ignore a atualização e saia.
· Se não – Vá para a etapa 3.
3. Verifique as há opções no nível de tabela.

 No nível de tabela (Table-Level), como condição primária, o escravo verifica se a replicação baseada em declaração esta ativa, caso afirmativo verifica se a declaração ocorre dentro de uma função armazenada, então o nó escravo executa e sai, caso contrário, a condição não é aplicada. Chegando a este ponto, se não há opções de nível de tabela, o nó escravo simplesmente executa todos os eventos. Se houver algum --replicate-do-table ou --replicate-wild-do-table nas opções, todos os eventos são executados, exceto aqueles que corresponderem a qualquer uma destas opções. Como podemos ver na figura 2 e seu detalhamento na tabela 2.
Figura 2. Procedimento da Replicação Table-Level
Figura 2. Procedimento da Replicação Table-Level

 Tabela 2. Passos da execução em Table-Level
1. Há alguma opção no nível de tabela?
· Se sim – Vá para etapa 2.
· Se não – Execute o evento e saia.
2. Há a opção --replicate-do-table?
· Se sim – A tabela não corresponde?
· Se sim – Execute a atualização e saia.
· Se não – Vá para a etapa 3.
· Se não – Vá para a etapa 3.
3. Há a opção --replicate-ignore-table?
· Se sim – A tabela não corresponde?
· Se sim – Ignore a atualização e saia.
· Se não – Vá para a etapa 4.
· Se não – Vá para a etapa 4.
4. Há a opção --replicate-wild-do-table?
· Se sim – A tabela não corresponde?
· Se sim – Execute a atualização e saia.
· Se não – Vá para a etapa 5.
· Se não – Vá para a etapa 5.
5. Há a opção --replicate-wild-ignore-table?
· Se sim – A tabela não corresponde?
· Se sim – Ignore a atualização e saia.
· Se não – Vá para a etapa 6.
· Se não – Vá para a etapa 6.
6. Há a opção --replicate-do-table ou --replicate-wild-do-table?
· Se sim – Ignore a atualização e saia.
· Se não – Execute a atualização e saia.

 No lado do nó escravo, há mais opções para a filtragem dos dados. Se um servidor mestre não escrever uma declaração em seu log binário, a declaração não é replicada. Se o servidor não registrar a declaração, a declaração é enviada para todos os escravos e cada escravo determina se a executá-la ou ignorá-la. Neste caso é usada a opção --replicate-* no nó escravo quando ele for inicializado. Estas especificações podem ser definidas através de linha de comando como também na escrita de um arquivo de opções, muitas delas podem ser realizadas em tempo real.


8. Conclusão

Este artigo apresentou técnicas para implementação da replicação de dados no SGBD MySQL. Os métodos e formatos de replicação no MySQL são práticos e simples e permitem uma gama de opções de configurações para o desenvolvimento de um sistema de alta performance, permitindo através dos filtros, o balanceamento de cargas, assim como garantir backup das informações de forma fácil e confiável.
Sendo o MySQL um software livre com base na GPL, os custos de implantações de um sistema utilizando a replicação de dados do SGBD MySQL serão bem reduzidos.
Na comparação entre os métodos de replicação suportados pelo MySQL 5.5 podemos observar que a replicação semi-síncrona oferece uma integridade de dados melhor, pois quando no sucesso de uma transação sabemos que os dados foram armazenados em pelo menos dois nós, sendo um deles o primário. Temos também a vantagem da comparação de log binários do mestre e o log de relay dos escravos permitindo assim um maior controle da estrutura de replicação. A desvantagem nesta arquitetura ficará por conta do tempo na troca de informações entre os nós, que na ótica da segurança de dados pode ser uma compensação.


9. Referências

[ORACLE AND/OR ITS AFFILIATES], “MySQL 5.5 Reference Manual”,
http://dev.mysql.com/doc/refman/5.5/en/replication.html.
[OZSU, M.T.; VALDURIEZ P. 1999], “Principles of Distributed Database Systems” (Second Edition), Pretince-Hall.

Abstract. The MySQL DBMS allows you to configure replication of data in a system where one or more servers are copied and kept in different nodes may be they masters or slaves within a distributed system. This article describes some techniques adopted in the DBMS MySQL replication, showing asynchronous replication and semi-asynchronous as well as rules for replication granularity and
formats that can be specified.
Resumo. O SGBD MySQL permite a configuração de replicação de dados em um sistema, onde um ou mais servidores são copiados e mantidos em diferentes nós podendo ser estes mestres ou escravos dentro de um sistema distribuído. Este artigo descreve algumas técnicas de replicação adotadas no SGBD MySQL, mostrando as replicações assíncrona e semi-assíncrona como também regras para granulosidade e formatos de replicação que podem ser especificados.

Victor Hugo Manata Pontes
Curso de Ciência da Computação – Universidade Católica de Minas Gerais campus de
Poços de Caldas (PUC Poços de Caldas)
Poços de Caldas – MG – Brazil
vhpontes @ gmail . com


👍Gostou? Deixe seu apoio com um JÓINHA, Comente e Siga!


⭐Inscreva-se em nosso Canal do Youtube: youtube.com/@dtudoumporco