Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Replicação no MySQL 5.5 - SQL Magazine 83
Este artigo trata do assunto que é o mais aguardado por todos os administradores de bancos de dados que lidam com o servidor de bancos de dados MySQL: replicação síncrona e semi-síncrona. Além disso, passaremos levemente por conceitos como habilitação do log binários, criação de usuário e concessão de privilégios e sua configuração, para o leitor que seguir os passos descritos no artigo, de uma replicação MASTER => SLAVE simples.
SQL Magazine 83
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 83
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 83
Replicação no MySQL 5.5
Configurando o Recurso Semi-synchronous Replication
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 ino-vaçõ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 or-ganizaçõ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 inte-ressa à 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 S-LAVE, o MySQL criou um plugin que possibilita o recurso denominado semi-synchronous replication que é um pouco diferente do sistema de replicação nativo, embo-ra se utilize dele. Antes de nos aprofundarmos no assunto, temos que passar pelos con-ceitos 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 su-porte 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.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Configurando o Recurso Semi-synchronous Replication
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 ino-vaçõ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 or-ganizaçõ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 inte-ressa à 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 S-LAVE, o MySQL criou um plugin que possibilita o recurso denominado semi-synchronous replication que é um pouco diferente do sistema de replicação nativo, embo-ra se utilize dele. Antes de nos aprofundarmos no assunto, temos que passar pelos con-ceitos 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 su-porte 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.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
0 COMENTÁRIO
Você está em:
canal SQL
Publicidade
Wagner Bianchi
Space do autor
Wagner Bianchi é Tecnólogo em Gerenciamento de Bancos de Dados pela Faculdade Infórium de Tecnologia, Pós-Graduando em Administração Estratégica de Empresas (Executivo Jr.) pela Fundação Getúlio Vargas no Minas Business Institute, Consultor em Desenvolvimento de Sistemas pela INFODBA C&T, empresa on...
Space do autor
0
0
