Neste artigo, veremos como migrar da replicação tradicional para o GTID,
discutiremos como fazer isso totalmente online. Primeiro, vamos discutir algumas opções de configuração relacionadas ao GTID. O modo GTID determina se o servidor usa GTIDs ou não, isso afeta não apenas o login binário de replicação também porque os logs binários terão GTIDs neles. A opção forçar consistência do GTID garante que o servidor permita apenas instruções seguras para execução no modo GTID. Instruções que não são seguras para serem executadas são como criar tabela como selecionar, existem mais algumas por aí, para o valor gtid_owned, elas podem monitorar os GTIDs em transações em andamento. Isso é muito útil quando eles estão desativando os GTIDs online.
Vamos discutir alguns e, para ser exato, é apenas uma variável de status relacionada ao GTID. O ONGOING_ANONYMOUS_TRANSACTION_ COUNT é a contrapartida do GTID de propriedade, mas em caso de migração quanto ao ONGOING_ANONYMOUS_TRANSACTION_COUNT, é chamado de transação anônima porque não possui um identificador que é o GTID.
Todas as operações precisam ser feitas em um dos nós na topologia de replicação e, eventualmente, em todos os nós. A melhor prática é fazer o escravo primeiro e o mestre, mas no caso de muitas operações, a ordem não importa, desde que sejam executadas em cada instância da topologia de replicação.
Neste ambiente, tenho três máquinas virtuais, duas delas são bancos de dados e uma delas é a máquina sysbench para gerar tráfego, então vamos começar.
Mestre:192.168.66.5
Escravo: 192.168.66.7
No nó sysbench vamos executar o comando preparado para criar um banco de dados sysbench, você pode simplesmente copiar e colar a partir de baixo.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password= password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare
No nó sysbench executa alguma carga de trabalho no mestre que estávamos executando durante a tarefa.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --rate=10 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run
Vamos iniciar o cliente MySQL em todos os nós, todos os nós do banco de dados. Vamos verificar a lista de processos de exibição no mestre para que você possa ver que isso está sendo executado aqui.
mysql> show processlist; +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 2350 | Waiting on empty queue | NULL | | 8 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 15 | syncstndby | 192.168.66.7:47894 | NULL | Binlog Dump | 156 | Master has sent all binlog to slave; waiting for more updates | NULL | | 17 | sbtest_user | 192.168.66.6:38130 | sbtest | Sleep | 0 | | NULL | | 18 | sbtest_user | 192.168.66.6:38132 | sbtest | Sleep | 1 | | NULL | | 19 | sbtest_user | 192.168.66.6:38134 | sbtest | Sleep | 0 | | NULL | | 20 | sbtest_user | 192.168.66.6:38136 | sbtest | Sleep | 0 | | NULL | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ 7 rows in set (0.00 sec)
Ok, a partir de agora vamos trabalhar com a pomada primeiro e o mestre.
Então, primeiro vamos definir enforcement_gtid_consistency =‘warn’ no slave, para slave master.
Escravo 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Mestre 192.168.66.5
set global enforce_gtid_consistency = 'warn';
terminamos aqui e verificaremos o erro do MySQL, veja o log de erros, isso deve ficar bem; você não verá nenhum erro no log de erros. As próximas etapas são executar set global enforcement_gtid_consistency='on' em todos os lugares e, em seguida, verificar a seta novamente.
Escravo 192.168.66.7
set global enforce_gtid_consistency='on';
Mestre 192.168.66.5
set global enforce_gtid_consistency='on';
Então, o próximo passo é definir global gtid_mode='off_permissive'; então, novamente, vou iniciar o cliente MySQL e configurá-lo. E então verificamos o log de erros
Escravo 192.168.66.7
set global gtid_mode='off_permissive';
Mestre 192.168.66.5
set global gtid_mode='off_permissive';
Em cada servidor vamos definir o gtid_mode='on_permissive'; para que possamos gerar transações GTID neste momento.
Escravo 192.168.66.7
set global gtid_mode='on_permissive';
Mestre 192.168.66.5
set global gtid_mode='on_permissive';
Então, está definido em todos os lugares. Vamos verificar os logs de erros
Tudo bem, agora vamos verificar se algum dos nós tem transações anônimas em andamento, porque se tiver, quando definirmos gtid_mode='on', o servidor não aceitará mais transações anônimas e receberemos erros.
Escravo 192.168.66.7
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.22 sec)
Mestre 192.168.66.5
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.04 sec)
Portanto, ambos os servidores não têm, o que significa que estamos prontos para ativar os GTIDs. Vou habilitar gtid_mode =on.
Mestre 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Escravo 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Agora nos escravos, precisamos reinicializar a replicação para usar master-auto-position=1
Escravo 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Então, o que isso faz, esse “change master” aqui, se o thread salve já estava configurado, então se algum parâmetro não for tocado pelo comando change master, ele ficará apenas no valor atual.
Vamos verificar o status do escravo nos escravos e mostrar o status do mestre no mestre. tudo que eu deveria estar funcionando bem.
mysql> show salve status\G; mysql> show master status;
Agora a migração está feita:
Como sabemos, nenhuma atualização é bem-sucedida se você não tiver um plano de reversão, para reverter, clique no link abaixo para ler o próximo artigo.
Reverter para a replicação tradicional do GTID
