Como Configurar a Replicação em Grupo do MySQL no Ubuntu 20.04

Introdução

A replicação do MySQL espelha de forma confiável os dados e operações de uma base de dados para outra. A replicação convencional envolve um servidor primário configurado para aceitar operações de escrita no banco de dados, com servidores secundários que copiam e aplicam ações do log do servidor primário em seus próprios conjuntos de dados. Esses servidores secundários podem ser usados para leituras, mas geralmente não podem executar gravações de dados.

A replicação em grupo é uma maneira de implementar um mecanismo de replicação mais flexível e tolerante a falhas. Esse processo envolve o estabelecimento de um pool de servidores, cada um envolvido em garantir que os dados sejam copiados corretamente. Se o servidor primário apresentar problemas, as eleições de membros podem selecionar um novo servidor primário do grupo. Isso permite que os nós restantes continuem operando, mesmo diante de problemas. A negociação de adesão, detecção de falhas e entrega de mensagens são fornecidas por meio de uma implementação do algoritmo de consenso Paxos.

Neste tutorial, você irá configurar a replicação em grupo do MySQL usando um conjunto de três servidores Ubuntu 20.04. Note que três é o número mínimo de instâncias do MySQL que você precisa implantar para replicação em grupo no MySQL, enquanto nove é o máximo. Conforme você avança neste tutorial, terá a opção de configurar o grupo como um grupo de replicação de único primário ou de múltiplos primários.

Pré-requisitos

Para completar este guia, você precisará:

• Três servidores executando o Ubuntu 20.04. Cada um deve ter um usuário administrativo não root com privilégios sudo e um firewall configurado com UFW. Siga nosso guia de configuração inicial do servidor para o Ubuntu 20.04 para configurar cada servidor.
• O MySQL instalado em cada servidor. Este guia assume que você está usando a versão mais recente do MySQL disponível nos repositórios padrão do Ubuntu, que, até o momento desta escrita, é a versão 8.0.28. Para instalar isso em todos os seus servidores, siga nosso guia sobre Como Instalar o MySQL no Ubuntu 20.04 para cada máquina.

Para ajudar a manter as coisas claras, este guia se referirá aos três servidores como member1, member2 e member3. Nos exemplos ao longo deste guia, esses membros terão os seguintes endereços IP:

Qualquer comando que precise ser executado em member1 terá um fundo azul, como este:

Da mesma forma, qualquer comando que precise ser executado em member2 terá um fundo vermelho:

E qualquer comando que precise ser executado em member3 terá um fundo verde:

Por último, qualquer comando que precise ser executado em cada um dos três servidores terá um fundo padrão:

Passo 1 — Gerando um UUID para Identificar o Grupo MySQL

Antes de abrir o arquivo de configuração do MySQL para configurar as definições de replicação em grupo, você precisa gerar um UUID que possa usar para identificar o grupo MySQL que irá criar.

No membr1, use o comando uuidgen para gerar um UUID válido para o grupo:

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

Copie o valor que receber, pois precisará referenciá-lo em breve ao configurar um nome de grupo para seu conjunto de servidores.

Passo 2 — Configurando a Replicação em Grupo no Arquivo de Configuração do MySQL

Agora você está pronto para modificar o arquivo de configuração do MySQL. Abra o arquivo de configuração principal do MySQL em cada servidor MySQL usando seu editor de texto preferido. Aqui, vamos usar o nano:

sudo nano /etc/mysql/my.cnf

No Ubuntu, o MySQL vem instalado com uma série de arquivos diferentes que você pode usar para definir várias mudanças de configuração. Por padrão, o arquivo my.cnf é apenas usado para incluir arquivos adicionais de subdiretórios. Você terá que adicionar sua própria configuração abaixo das linhas !includedir. Isso permitirá que você substitua qualquer configuração dos arquivos incluídos.

Para começar, inicie uma nova seção incluindo um cabeçalho [mysqld] e depois adicione as configurações necessárias para habilitar a replicação de grupo, conforme destacado no exemplo a seguir. Observe que essas configurações são modificadas a partir das configurações mínimas necessárias para a replicação de grupo, conforme delineado na documentação oficial do MySQL. O prefixo loose- permite que o MySQL lide com opções que não reconhece de forma graciosa e sem falhas. Você precisará preencher e personalizar algumas dessas configurações em breve:

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Para explicar todas essas opções de configuração com maior clareza, elas foram divididas nas seguintes subseções. Leia atentamente, pois algumas seções apresentam opções sobre como deseja implantar seu grupo de replicação ou exigem que você insira detalhes específicos de sua própria configuração.

Configurações Básicas de Replicação de Grupo

A primeira seção contém configurações gerais necessárias para a replicação em grupo que não requerem modificação:

. . .
# Configurações gerais de replicação
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

Um requisito específico para a replicação em grupo no MySQL é que os dados devem ser armazenados no mecanismo de armazenamento InnoDB. A documentação do MySQL recomenda desativar explicitamente o uso de outros mecanismos de armazenamento que possam causar erros de forma semelhante à primeira linha não comentada nesta seção.

As configurações restantes ativam os IDs de transação globais, configuram o log binário necessário para a replicação em grupo e configuram SSL para o grupo. Esta configuração também define alguns outros itens que ajudam na recuperação e inicialização. Você não precisa modificar nada nesta seção e ela deve ser idêntica em todos os três de seus servidores, então você pode prosseguir após adicioná-la.

Configurações Compartilhadas de Replicação em Grupo

A segunda seção configura as configurações compartilhadas para o grupo. Você terá que personalizar isso uma vez e depois usar as mesmas configurações em cada um de seus nós. Especificamente, você deve adicionar o UUID do grupo (que você criou na etapa anterior), uma lista de membros do grupo autorizados e os membros de seed para entrar em contato para obter os dados iniciais ao ingressar no grupo.

Defina o loose-group_replication_group_name para o valor UUID que você gerou anteriormente com o comando uuidgen. Certifique-se de colocar o UUID entre o par de aspas duplas vazio.

Em seguida, defina loose-group_replication_ip_whitelist para uma lista de todos os endereços IP do seu servidor MySQL, separados por vírgulas. A configuração loose-group_replication_group_seeds deve ser quase a mesma que a lista branca, mas deve anexar uma porta de replicação de grupo designada ao final de cada membro. Para os fins deste guia, use a porta de replicação de grupo recomendada, 33061:

. . .
# Configuração compartilhada do grupo de replicação
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Esta seção deve ser a mesma em cada um dos seus servidores MySQL, então certifique-se de copiá-la cuidadosamente em cada um.

Escolhendo Primário Único ou Múltiplo

Em seguida, você precisa decidir se deseja configurar um primário único ou um grupo múltiplo primário. Em uma configuração de primário único, o MySQL designa um único servidor primário (quase sempre o primeiro membro do grupo) para lidar com operações de gravação. Um grupo múltiplo primário permite que qualquer um dos membros do grupo execute gravações.

Se desejar configurar um grupo multi-primário, descomente as diretivas loose-group_replication_single_primary_mode e loose-group_replication_enforce_update_everywhere_checks. Isso configurará um grupo multi-primário. Para um grupo de um único primário, deixe essas duas linhas comentadas:

. . .
# Modo único ou multi-primário? Descomente estas duas linhas
# para o modo multi-primário, onde qualquer host pode aceitar gravações
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Essas configurações devem ser as mesmas em cada um dos seus servidores MySQL.

Você pode alterar essa configuração posteriormente, mas após fazê-lo, será necessário reiniciar cada membro do seu grupo MySQL. Para mudar para a nova configuração, será necessário parar cada uma das instâncias do MySQL no grupo, iniciar cada membro com as novas configurações e, em seguida, reiniciar a replicação do grupo. Isso não afetará nenhum dos seus dados, mas exigirá uma pequena janela de tempo inativo.

Configurações Específicas do Host

A quarta seção contém configurações que serão diferentes em cada um dos servidores, incluindo:

• O ID do servidor
• O endereço para vincular
• O endereço para relatar aos outros membros
• O endereço local de replicação e porta de escuta

A diretiva server_id deve ser definida como um número único. Para o primeiro membro, defina isso como 1 e incremente o número em cada host adicional. Defina bind-address e report_host para o endereço IP respectivo do servidor para que a instância do MySQL escute conexões externas e reporte corretamente seu endereço para outros hosts. O loose-group_replication_local_address também deve ser definido como o endereço IP atual do servidor com a porta de replicação de grupo (33061) anexada ao endereço IP.

Como exemplo, aqui está esta parte da configuração para member1 usando seu endereço IP de exemplo:

. . .
# Configuração de replicação específica do host
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Complete este processo em cada um dos seus servidores MySQL. Aqui está a configuração para member2:

. . .
# Configuração de replicação específica do host
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

E aqui está a configuração para member3:

. . .
# Configuração de replicação específica do host
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Certifique-se de atualizar cada endereço IP destacado para o do servidor cuja configuração você está editando.

Quando terminar, verifique se as configurações de replicação compartilhadas são iguais em cada host e se as configurações específicas do host estão personalizadas para cada host. Salve e feche o arquivo em cada host quando terminar. Se você usou o nano para editar o arquivo, pode fazê-lo pressionando CTRL + X, Y e depois ENTER.

Cada um dos arquivos de configuração do MySQL dos seus servidores agora contém as diretivas necessárias para inicializar a replicação de grupo do MySQL. Para aplicar as novas configurações à instância do MySQL, reinicie o serviço em cada um dos seus servidores com o seguinte comando:

sudo systemctl restart mysql

Com isso, você pode prosseguir para habilitar o acesso remoto atualizando as regras de firewall de cada um dos seus servidores.

Passo 3 — Atualizando as Regras UFW de Cada Servidor

Supondo que você tenha seguido o guia de configuração inicial do servidor como pré-requisito, você terá configurado um firewall em cada um dos servidores nos quais instalou o MySQL e habilitado o acesso para o perfil OpenSSH do UFW. Esta é uma medida de segurança importante, pois esses firewalls atualmente bloqueiam conexões para qualquer porta em seus servidores, exceto conexões ssh que apresentam chaves que se alinham com aquelas no arquivo authorized_keys respectivo de cada servidor.

No arquivo de configuração do MySQL, você configurou o serviço para ouvir conexões externas na porta padrão 3306. Você também definiu 33061 como a porta que os membros devem usar para a coordenação da replicação.

Em cada um dos seus servidores membros, você precisa abrir acesso a ambas as portas para os outros membros deste grupo, para que todos possam se comunicar entre si. Para abrir acesso a essas portas no member1 para o member2, execute os seguintes comandos ufw no member1:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Certifique-se de alterar member2_server_ip para refletir o endereço IP real do seu servidor member2. Em seguida, para abrir as mesmas portas para o member3, execute esses comandos:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Em seguida, atualize as regras do firewall para seus outros dois servidores. Execute os seguintes comandos no member2, garantindo que você altere os endereços IP para refletir os de member1 e member3, respectivamente:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Por fim, execute esses dois comandos no member3. Novamente, certifique-se de inserir os endereços IP corretos para cada servidor:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Após adicionar essas regras UFW, cada uma das suas três instâncias MySQL terá acesso permitido às portas usadas pelo MySQL nos outros dois servidores.

Com acesso às portas do MySQL aberto, você pode agora criar um usuário de replicação e habilitar o plugin de replicação de grupo.

Passo 4 — Configurando Usuários de Replicação e Habilitando o Plugin de Replicação de Grupo

Para estabelecer conexões com os outros servidores no grupo de replicação, cada instância do MySQL deve ter um usuário de replicação dedicado.

Em cada um dos seus servidores MySQL, faça login na sua instância do MySQL com o usuário administrativo para iniciar uma sessão interativa:

sudo mysql

Como cada servidor terá seu próprio usuário de replicação, você precisa desativar o registro binário durante o processo de criação. Caso contrário, uma vez iniciada a replicação, o grupo tentaria propagar o usuário de replicação do primário para os outros servidores, criando um conflito com o usuário de replicação já existente. Execute o seguinte comando no prompt do MySQL em cada um dos seus servidores:

SET SQL_LOG_BIN=0;

Agora você pode executar uma declaração CREATE USER para criar seu usuário de replicação. Execute o seguinte comando, que cria um usuário chamado repl. Este comando especifica que o usuário de replicação deve se conectar usando SSL. Além disso, certifique-se de usar uma senha segura no lugar de senha ao criar este usuário de replicação:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

Em seguida, conceda ao novo usuário privilégios de replicação no servidor:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Depois, atualize os privilégios para implementar as alterações:

FLUSH PRIVILEGES;

Depois disso, reative o registro binário para retomar as operações normais:

SET SQL_LOG_BIN=1;

Em seguida, defina o canal group_replication_recovery para usar seu novo usuário de replicação e sua senha associada. Cada servidor usará então essas credenciais para autenticar-se no grupo:

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Com o utilizador de replicação configurado, pode ativar o plugin group_replication para preparar a inicialização do grupo:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Verifique se o plugin está ativo executando o seguinte comando:

SHOW PLUGINS;

O plugin group_replication aparecerá no final da lista, pois é o plugin mais recentemente adicionado:

Output
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

Esta saída confirma que o plugin foi carregado e está atualmente ativo. Antes de prosseguir para o próximo passo, certifique-se de que executou cada comando nesta secção em cada uma das suas instâncias do MySQL.

Passo 5 — Iniciar a Replicação em Grupo

Agora que cada servidor MySQL tem um utilizador de replicação configurado e o plugin de replicação em grupo ativado, pode começar a trazer o seu grupo para cima.

Iniciar o Primeiro Nó

Para iniciar o grupo, siga os seguintes passos em um único membro do grupo. Para fins de demonstração, este guia concluirá estes passos em membro1.

Os membros do grupo dependem dos membros existentes para enviar dados de replicação, listas de membros atualizadas e outras informações ao ingressar inicialmente no grupo. Por causa disso, você precisa usar um procedimento ligeiramente diferente para iniciar o membro do grupo inicial para que ele saiba que não deve esperar essas informações de outros membros em sua lista de sementes.

Se definido, a variável group_replication_bootstrap_group diz a um membro que ele não deve esperar receber informações de seus pares e, em vez disso, deve estabelecer um novo grupo e se eleger como membro primário. Você pode ativar essa variável com o seguinte comando:

SET GLOBAL group_replication_bootstrap_group=ON;

Em seguida, você pode iniciar a replicação para o membro inicial do grupo:

START GROUP_REPLICATION;

Depois disso, você pode definir a variável group_replication_bootstrap_group de volta para OFF, já que a única situação em que isso é apropriado é quando não há membros existentes no grupo:

SET GLOBAL group_replication_bootstrap_group=OFF;

O grupo será iniciado com este servidor como o único membro. Verifique isso verificando as entradas na tabela replication_group_members no banco de dados performance_schema:

SELECT * FROM performance_schema.replication_group_members;

Esta consulta retornará uma única linha representando o host atual:

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)

O valor ONLINE para MEMBER_STATE indica que este nó está totalmente operacional dentro do grupo.

Em seguida, crie um banco de dados de teste e uma tabela com alguns dados de amostra. Uma vez que mais membros são adicionados a este grupo, esses dados serão replicados automaticamente para eles.

Comece criando um banco de dados de amostra chamado playground:

CREATE DATABASE playground;

A seguir, crie um exemplo de tabela chamada equipamento dentro do banco de dados playground com o seguinte comando:

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

Esta tabela contém as seguintes quatro colunas:

• id: Esta coluna conterá valores inteiros que aumentam automaticamente, o que significa que você não precisará especificar valores para esta coluna ao carregar a tabela com dados de exemplo
• tipo: Esta coluna conterá valores de string descrevendo que tipo de equipamento de playground a linha representa
• quant: Esta coluna conterá valores inteiros para representar a quantidade do tipo de equipamento de playground especificado
• cor: Esta coluna conterá valores de string especificando a cor do equipamento fornecido

Também, observe que a coluna id é especificada como a chave primária desta tabela. No MySQL, toda tabela replicada para um grupo deve ter uma coluna designada como a chave primária da tabela.

Por último, execute o seguinte comando para inserir uma linha de dados na tabela:

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Consulte a tabela para garantir que os dados foram inseridos corretamente:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

Após verificar que este servidor é um membro do grupo e que possui capacidades de gravação, os outros servidores podem se juntar ao grupo.

Iniciando os Nós Restantes

Em seguida, inicie a replicação em grupo em member2. Como você já possui um membro ativo, não é necessário inicializar o grupo e este membro pode se juntar imediatamente:

START GROUP_REPLICATION;

No member3, inicie a replicação em grupo da mesma maneira:

START GROUP_REPLICATION;

Verifique a lista de membros novamente em qualquer um dos três servidores. Desta vez, haverá três servidores listados na saída:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

Todos os membros devem ter um valor de MEMBER_STATE como ONLINE. Para um novo grupo, se algum dos nós for listado como RECOVERING por mais do que alguns segundos, geralmente é um indicativo de que ocorreu um erro ou algo foi configurado incorretamente. Verifique os logs em /var/log/mysql/error.log para obter informações adicionais sobre o que deu errado.

Em seguida, verifique se as informações do banco de dados de teste foram replicadas nos novos membros:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

Se os dados estiverem disponíveis nos novos membros, significa que a replicação em grupo está funcionando corretamente.

Passo 6 — Testando as Capacidades de Escrita dos Novos Membros do Grupo

Em seguida, você pode tentar escrever no banco de dados a partir dos novos membros do grupo de replicação. Se isso terá sucesso ou não é uma função de se você escolheu configurar um grupo de replicação com um único primário ou múltiplos primários.

Testando Gravações em um Ambiente de Primário Único

Em um grupo de primário único, você deve esperar que quaisquer operações de gravação de um servidor não primário sejam rejeitadas por motivos de consistência. Você pode encontrar o primário atual a qualquer momento executando a seguinte consulta em qualquer membro do seu grupo de replicação:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

O valor da consulta será um ID_DO_MEMBRO que você pode relacionar com um host consultando a lista de membros do grupo como você fez antes:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Como indica a saída de exemplo, o host em 203.0.113.1 — member1 — é atualmente o servidor primário. Se você tentar gravar no banco de dados a partir de outro membro, a operação falhará:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Isso é esperado, uma vez que o grupo está atualmente configurado com um único primário capaz de escrita. Se o servidor primário tiver problemas e sair do grupo, o grupo automaticamente elegerá um novo membro para ser o primário e aceitará gravações.

Testando Gravações em um Ambiente de Múltiplos Primários

Para grupos que foram configurados em uma orientação de múltiplos primários, qualquer membro deve ser capaz de confirmar gravações no banco de dados.

Você pode verificar se o seu grupo está operando no modo multi-primário verificando o valor da variável group_replication_primary_member novamente:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

Se a variável estiver vazia, isso significa que não há um host primário designado e que qualquer membro deve ser capaz de aceitar escritas.

Teste isso no member2 tentando escrever alguns dados na tabela equipment:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

member2 confirmou a operação de escrita sem erros.

No member3, execute a seguinte consulta para verificar se o novo item foi adicionado:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Isto confirma que a escrita do member2 foi replicada com sucesso.

Agora, teste as capacidades de escrita no member3 executando a seguinte instrução INSERT:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

Voltando ao member1, verifique se as operações de escrita de ambos os novos membros foram replicadas de volta:

SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

Isto confirma que a replicação está funcionando em ambas as direções e que cada membro é capaz de realizar operações de escrita.

Passo 7 — Tragando o Grupo de Volta

Uma vez que o grupo está inicializado, os membros individuais podem entrar e sair sem afetar a disponibilidade, desde que haja membros suficientes para eleger servidores primários. No entanto, se certas mudanças de configuração forem feitas (como alternar entre ambientes de único e múltiplos primários), ou se todos os membros do grupo saírem, talvez seja necessário inicializar o grupo novamente da mesma maneira que foi feito inicialmente.

Em membro1, defina a variável group_replication_bootstrap_group como ON:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Então, inicialize o grupo:

START GROUP_REPLICATION;

Após isso, você pode definir a variável group_replication_bootstrap_group de volta para OFF:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Assim que o primeiro membro iniciar o grupo, outros membros podem entrar:

START GROUP_REPLICATION;

Siga este processo para quaisquer membros adicionais:

START GROUP_REPLICATION;

O grupo deve estar online agora com todos os membros disponíveis:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Este processo pode ser usado para iniciar o grupo novamente sempre que necessário.

Passo 8 — Entrar em um Grupo Automaticamente Quando o MySQL Inicia

Com as configurações atuais, se um servidor membro reiniciar, ele não se juntará automaticamente ao grupo na inicialização. Se desejar que os membros se juntem automaticamente ao grupo, você pode modificar ligeiramente o arquivo de configuração.

A configuração delineada neste passo é útil quando você deseja que os membros se juntem automaticamente ao iniciar. No entanto, há algumas coisas que você deve estar ciente. Primeiro, essa configuração só afeta quando a instância do MySQL em si é iniciada. Se o membro for removido do grupo devido a problemas de tempo limite, mas a instância do MySQL permanecer online, o membro não se juntará automaticamente novamente.

Em segundo lugar, ter essa configuração habilitada ao inicializar pela primeira vez um grupo pode ser prejudicial. Quando não há um grupo existente para se juntar, o processo do MySQL levará muito tempo para iniciar porque tentará entrar em contato com outros membros inexistentes para inicialização. Somente após um longo período de tempo limite, ele desistirá e iniciará normalmente. Depois, você terá que usar o procedimento delineado acima para inicializar o grupo.

Com as ressalvas acima em mente, se você deseja configurar nós para se juntarem automaticamente ao grupo quando o MySQL iniciar, abra o arquivo de configuração principal do MySQL:

sudo nano /etc/mysql/my.cnf

Dentro dele, encontre a variável loose-group_replication_start_on_boot e defina-a como ON:

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

Salve e feche o arquivo quando terminar. O membro deve tentar se juntar automaticamente ao grupo na próxima vez que sua instância do MySQL for iniciada.

Conclusão

Ao concluir este tutorial, você aprendeu como configurar a replicação de grupo do MySQL entre três servidores Ubuntu 20.04. Para configurações de única primária, os membros automaticamente elegerão uma primária capaz de escrita quando necessário. Para grupos de múltiplas primárias, qualquer membro pode realizar escritas e atualizações. A replicação de grupo fornece uma topologia flexível que permite que os membros entrem ou saiam a qualquer momento, ao mesmo tempo em que fornece garantias sobre a consistência dos dados e a ordem das mensagens. A replicação de grupo do MySQL pode ser um pouco mais complexa de configurar, mas fornece capacidades que não são possíveis na replicação tradicional.