Menu fechado

Categoria: binlog

Por que Replicação Atrasa no MySQL?

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 . . .

Gostou ? Ajude e Compartilhe!

Como Funciona A Replicação No MySQL?

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, . . .

Gostou ? Ajude e Compartilhe!

Got a packet bigger than ‘slave_max_allowed_packet’ bytes and binlog_format = STATEMENT | MIXED

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 . . .

Gostou ? Ajude e Compartilhe!

MySQL 5.6 replicação com GTID – Global Transaction ID

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 . . .

Gostou ? Ajude e Compartilhe!

Replicação em MySQL – Master – Slave

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 . . .

Gostou ? Ajude e Compartilhe!