MySQL Fabric é uma ferramenta que está inclusa no MySQL Utilities que ajuda a gerenciar servidores MySQL. Ele funciona basicamente adicionando uma nova camada entre a aplicação e os servidores MySQL, que auxilia no processo de sharding e alta disponibilidade. Para instalar nosso ambiente com MySQL Fabric, vamos precisar de 4 servidores, eu utilizei os seguintes nomes e IPs: fabric1 (192.168.0.200) – fabric mysql1 (192.168.0.201) – mysql master mysql2 (192.168.0.202) – mysql slave mysql3 (192.168.0.203) – mysql slave Obs.: Estou rodando CentOS 6.5 em todos os servidores. 1. Adicione o repositório mysql nos 4 servidores, leia Instalar a versão mais recente do MySQL via yum para mais informações: rpm -i http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm yum update 2. Instale os pacotes mysql mysql-server mysql-utilities: yum install mysql mysql-server mysql-utilities chkconfig mysqld on /etc/init.d/mysqld start . . .
Hoje vamos falar sobre uma excelente ferramenta que todo DBA MySQL precisa ter em mãos, estou falando do MySQL Sandbox. MySQL Sandbox é desenvolvido por Giuseppe Maxia (The Data Charmer), esta ferramenta auxilia na instalação de servidores para testes. Se você precisa testar algum bug, algum caso especifico relacionado a replicação(suporta master/slave e master/master) esta é a ferramenta que tens que conhecer. INSTALAÇÃO: Vá até http://mysqlsandbox.net/ e baixe a versao mais atual (Pode ser via launchpad): yum install perl perl-ExtUtils-MakeMaker perl-Test-Simple wget https://launchpad.net/mysql-sandbox/mysql-sandbox-3/mysql-sandbox-3/+download/MySQL-Sandbox-3.0.44.tar.gz tar -zxvf MySQL-Sandbox-3.0.44.tar.gz cd MySQL-Sandbox-3.0.44 perl Makefile.PL make make test make install CRIANDO UMA INSTÂNCIA: Para criar uma única instância, tudo o que precisamos é o pacote (tar.gz .rpm .deb) da versão do MySQL que desejamos instalar e o comando make_sandbox: [root@localhost ~]# make_sandbox mysql-5.6.17-linux-glibc2.5-i686.tar.gz unpacking /root/mysql-5.6.17-linux-glibc2.5-i686.tar.gz Executing . . .
Dando continuidade ao post anterior vamos ver um exemplo de como configurar 2 masters e 1 slave utilizando multi-source replication. Como foi dito anteriormente, por enquanto esta funcionalidade esta disponível somente na versão labs. A configuração em si é muito simples, vamos precisar de 2 masters utilizando GTID(veja este outro post e aprenda como configurar) e o slave com as opções para garantir o chamado “crash-safe”. Master 1 e 2: gtid-mode=on enforce-gtid-consistency Slave master_info_repository=TABLE relay_log_info_repository=TABLE gtid-mode=on enforce-gtid-consistency Vamos primeiro criar o usuário para replicação: master1 [localhost] {msandbox} ((none)) > GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’127.0.0.1’ IDENTIFIED BY ‘123’; master2 [localhost] {msandbox} ((none)) > GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’127.0.0.1’ IDENTIFIED BY ‘123’; Vamos configurar o slave normalmente, com apenas um novo detalhe, foi introduzida a opção FOR CHANNEL. . . .
Na semana passada, durante o evento MySQL Connect, foi lançada a versão de testes do MySQL 5.7 (MySQL 5.7.2 DRM), dentre as novas funcionalidades, uma que chamou bastante a minha atenção foi a replicação de múltiplos masters (multi source replication). Atualmente o MySQL não possui uma funcionalidade oficialmente (build-in) , pode se conseguir esse resultado com alguns hacks, como, a cada x segundos executar um change master to no slave para ficar trocando de master, mas como o nome diz, isso é um “hack”. Veja como configurar aqui Não confundam muti source replication com multi master, veja as figura abaixo para entender a diferença: Multi Master Replication – Na figura acima, temos 2 master’s e 1 slave, onde que o master 1 é master do master 2, master 2 é . . .
Recentemente respondi algumas questões referente a lag(atraso) na replicação, o que percebi é que muita gente não intende corretamente como este processo funciona internamente no MySQL e o porque do lag acontecer: MySQL replication: most important config parameters for performance on slave server? mysql replication delay very serious Veja a figura abaixo, ela representa replicação assíncrona no MySQL, recomendo que você leia meu outro post sobre o assunto: “Como Funciona A Replicação No MySQL?” Como pode ser visto, existe uma grade diferença quanto ao ponto de entrada de dados no master e no slave, enquanto o master possui múltiplas threads inserindo/alterado/deletando dados ao mesmo tempo, no slave, existe somente uma única thread responsável por aplicar todas essas transações no banco de dados. Vamos imaginar que uma transação(UPDATE por exemplo) demorou . . .
Veja a figura abaixo, ela representa como a replicação assíncrona funciona no MySQL: Levando em consideração a numeração na figura, entenda como o processo funciona: Item numero 1 na figura representa os clientes executando queries no master, note que o master é capaz de processar múltiplas conexões simultaneamente (que pode ser configurado pela variável max_connections). O Master executa essas queries, e salva elas em forma de log (item numero 2 na figura) para que o(s) slave(s) possa(m) replica-las e assim ter os mesmo dados que o servidor Master. O slave por sua vez, trabalha com 2 threads para replicar os dados do servidor Master: IO_THREAD – responsável por conectar-se ao Master, e buscar as novas transações do binary log (item numero 3 na figura) e gravar-las em seu log(relay log, . . .
Desde a versão 5.1.64, o MySQL introduziu um nova variável chamada slave_max_allowed_packet, que foi introduzida para permitir um volume grande de dados quando inserindo ou atualizando registros utilizando replicação baseada em linha (row-based), fazendo com que a replicação não pare caso tu exceda o valor extipulado na variável max_allowed_packet. O problema é que se tu utiliza a variável binlog_format=STATEMENT ou binlog_format=MIXED, MySQL ignora essa nova opção e continua utilizando max_allowed_packet como limite máximo, mas ele continua a reportar o problema em slave_max_allowed_packet (que por default vem configurada a 1Gb), o que causa a IO_THREAD fornecer a mensagem de erro errada. Solução: Rode a seguinte query no master: master> SHOW VARIABLES LIKE 'binlog_format'; Se tu receber como retorno STATEMENT ou MIXED, tu precisa ajustar o valor da variável max_allowed_packet, uma boa . . .
Fala galera, No inicio deste mês, a Oracle lançou a nova versão do MySQL, a versão 5.6, uma das melhorias foi a introdução do GTID (ID de transação Global). GTID é um identificador único que sera adicionado a cada transação executada no servidor, e vai ter grande utilidade para o slave, garantindo que mais de uma thread nao execute a mesma transação e também auxiliar quanto a posição que o slave busca e executa dados do master (previamente tínhamos que setar MASTER_LOG_FILE e MASTER_LOG_POS quando iniciavamos o slave). Vamos intender algumas novas configuracoes que teremos que adicionar no nosso arquivo de configuracao: gtid-mode : vai habilitar GTID, temos que habilitar log-bin e log-slave-updates para esta opcao funcionar enforce-gtid-consistency : vai garantir que somente comandos que podem ser replicados sejam executados . . .
Hoje vamos dar continuidade a replicação, você pode ler o primeiro post sobre este tema aqui Primeiramente vamos criar os certificados SSL: Certificado CA: openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem Certificado do servidor openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem Certificado do Cliente openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem copy ca-cert.pem, client-req.pem, client-cert.pem to slave server Vamos ajustar o arquivo de configuração do MySQL: ssl ssl-ca=/etc/mysql/sslcerts/ca-cert.pem ssl-cert=/etc/mysql/sslcerts/server-cert.pem ssl-key=/etc/mysql/sslcerts/server-key.pem Não esqueça de reiniciar o serviço do MySQL, vamos verificar se esta tudo . . .
Para explicar a replicação, iremos utilizar o artigo Instalando MySQL 5.5 Parte 2 – Múltiplas instâncias pois iremos precisar de 2 instâncias rodando no nosso servidor. Iremos ativar os logs binários do nosso servidor, criando um arquivo my_rep.cnf com o seguinte conteúdo: [mysqld_multi] mysqld = /mysql/mysql/bin/mysqld_safe mysqladmin = /mysql/mysql/bin/mysqladmin [mysqld1] port = 3306 datadir = /mysql/3306/data socket = /mysql/3306/mysql.sock log-error = /mysql/3306/logs/mysqld.log pid-file = /mysql/3306/mysqld.pid server_id = 1 #LOGS log-bin = /mysql/3306/logs/server1_bin.log log-bin-index = /mysql/3306/logs/server1_log-bin.index expire_logs_days = 7 binlog-format = MIXED [mysqld2] port = 3307 datadir = /mysql/3307/data socket = /mysql/3307/mysql.sock log-error = /mysql/3307/logs/mysqld.log pid-file = /mysql/3307/mysqld.pid server_id = 2 #LOGS relay-log = /mysql/3307/logs/server2.relay_log relay-log-index = /mysql/3307/logs/server2.relay_log_index expire_logs_days = 7 Feito isso vamos iniciar o serviço conforme o artigo: cd /mysql/mysql mysqld_multi –defaults-file=/mysql/my_rep.cnf start Agora vamos conectar no servidor 3306 . . .