Os logs binários (binlogs) contêm registros de todas as alterações nos bancos de dados. Eles são necessários para replicação e também podem ser usados para restaurar dados após um backup. Um servidor de log binário é basicamente um repositório de log binário. Você pode pensar nisso como um servidor com um propósito dedicado para recuperar logs binários de um mestre, enquanto os servidores escravos podem se conectar a ele como se conectariam a um servidor mestre.
Algumas vantagens de ter um servidor de log binário sobre o mestre intermediário para distribuir a carga de trabalho de replicação são:
- Você pode alternar para um novo servidor mestre sem que os escravos percebam que o servidor mestre real mudou. Isso permite uma configuração de replicação mais altamente disponível em que a replicação é de alta prioridade.
- Reduza a carga no mestre servindo apenas o servidor binlog do Maxscale em vez de todos os escravos.
- Os dados no log binário do mestre intermediário não são uma cópia direta dos dados recebidos do log binário do mestre real. Dessa forma, se o commit de grupo for usado, isso pode causar uma redução no paralelismo dos commits e uma conseqüente redução no desempenho dos servidores escravos.
- O escravo intermediário precisa reexecutar cada instrução SQL que potencialmente adiciona latência e atrasos na cadeia de replicação.
Nesta postagem de blog, veremos como substituir um mestre intermediário (uma retransmissão de host escravo para outros escravos em uma cadeia de replicação) por um servidor de log binário em execução no MaxScale para melhor escalabilidade e desempenho .
Arquitetura
Nós basicamente temos uma configuração de replicação MariaDB v10.4 de 4 nós com um MaxScale v2.3 sobre a replicação para distribuir as consultas recebidas. Apenas um escravo está conectado a um mestre (mestre intermediário) e os outros escravos replicam do mestre intermediário para atender às cargas de trabalho de leitura, conforme ilustrado no diagrama a seguir.
Vamos transformar a topologia acima nesta:
Basicamente, vamos remover a função de mestre intermediário e substituí-la por um servidor binlog rodando em MaxScale. O mestre intermediário será convertido em um escravo padrão, assim como outros hosts escravos. O serviço binlog estará escutando na porta 5306 no host MaxScale. Esta é a porta à qual todos os escravos se conectarão para replicação posterior.
Configurando MaxScale como um Binlog Server
Neste exemplo, já temos um MaxScale no topo de nosso cluster de replicação atuando como um balanceador de carga para nossos aplicativos. Caso não tenha um MaxScale, você pode usar o ClusterControl para implantar basta ir em Cluster Actions -> Add Load Balancer -> MaxScale e preencher as informações necessárias conforme a seguir:
Antes de começarmos, vamos exportar a configuração atual do MaxScale para um arquivo de texto para backup. MaxScale tem um sinalizador chamado --export-config para esta finalidade, mas deve ser executado como usuário maxscale. Assim, o comando para exportar é:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleNo MariaDB master, crie um usuário slave de replicação chamado 'maxscale_slave' para ser usado pelo MaxScale e atribua a ele os seguintes privilégios:
$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';Para usuários do ClusterControl, vá para Manage -> Schemas and Users para criar os privilégios necessários.
Antes de prosseguirmos com a configuração, é importante revisar o estado atual e a topologia de nossos servidores de back-end:
$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0 │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Como podemos ver, o mestre atual é DB_757 (192.168.0.90). Anote essas informações, pois vamos configurar o servidor de log binário para replicar a partir deste mestre.
Abra o arquivo de configuração MaxScale em /etc/maxscale.cnf e adicione as seguintes linhas:
[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master
[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0Um pouco de explicação - Estamos criando dois componentes - serviço e ouvinte. Serviço é onde definimos a característica do servidor binlog e como ele deve ser executado. Detalhes sobre cada opção podem ser encontrados aqui. Neste exemplo, nossos servidores de replicação estão sendo executados com replicação semi-síncrona, portanto, temos que usar semisync=true para que ele se conecte ao mestre por meio do método de replicação semi-síncrona. O listener é onde mapeamos a porta de escuta com o serviço binlogrouter dentro do MaxScale.
Reinicie o MaxScale para carregar as alterações:
$ systemctl restart maxscaleVerifique se o serviço de log binário foi iniciado via maxctrl (veja a coluna Estado):
$ maxctrl show service replication-serviceVerifique se MaxScale agora está escutando uma nova porta para o serviço de log binário:
$ netstat -tulpn | grep maxscale
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:5306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscaleAgora estamos prontos para estabelecer um link de replicação entre o MaxScale e o mestre.
Ativando o Servidor Binlog
Faça login no servidor mestre MariaDB e recupere o arquivo binlog atual e a posição:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Use a função BINLOG_GTID_POS para obter o valor GTID:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+De volta ao servidor MaxScale, instale o pacote do cliente MariaDB:
$ yum install -y mysql-client
Conecte-se ao listener do servidor binlog na porta 5306 como usuário maxscale_slave e estabeleça um link de replicação para o mestre designado. Use o valor GTID recuperado do mestre:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.0.90
Master_User: maxscale_slave
Master_Port: 3306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 38001
Master_Info_File: /var/lib/maxscale/binlogs/master.ini
Slave_SQL_Running_State: Slave running
Gtid_IO_Pos: 0-38001-31Observação:a saída acima foi truncada para mostrar apenas linhas importantes.
Apontando Slaves para o Servidor Binlog
Agora em mariadb2 e mariadb3 (os escravos finais), altere o master apontando para o servidor binlog MaxScale. Como estamos executando com a replicação semi-síncrona habilitada, precisamos desativá-los primeiro:
(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update itObservação:a saída acima foi truncada para mostrar apenas linhas importantes.
Dentro do my.cnf, temos que comentar as seguintes linhas para desabilitar a semi-sincronização no futuro:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONNeste ponto, o mestre intermediário (mariadb1) ainda está replicando do mestre (mariadb0) enquanto outros escravos estão replicando do servidor binlog. Nossa topologia atual pode ser ilustrada como no diagrama abaixo:
A parte final é alterar o apontamento mestre do mestre intermediário (mariadb1 ) depois que todos os escravos que costumavam se conectar a ele não estão mais lá. Os passos são basicamente os mesmos com os outros escravos:
(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32Observação:a saída acima foi truncada para mostrar apenas linhas importantes.
Não se esqueça de desabilitar a replicação semi-sincronizada em my.cnf também:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONPodemos verificar se o serviço do roteador binlog tem mais conexões agora via maxctrl CLI:
$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Servers │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service │ readwritesplit │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service │ readconnroute │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘Além disso, comandos comuns de administração de replicação podem ser usados dentro do servidor binlog MaxScale, por exemplo, podemos verificar os hosts escravos conectados usando este comando:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003 | 192.168.0.92 | 3306 | 9999 | |
| 38002 | 192.168.0.91 | 3306 | 9999 | |
| 38004 | 192.168.0.93 | 3306 | 9999 | |
+-----------+--------------+------+-----------+------------+Neste ponto, nossa topologia está parecendo o que prevíamos:
Nossa migração da configuração mestre intermediária para a configuração do servidor de log binário está concluída.
