Configuração da Replicação de Grupo do MySQL (Mestre-Mestre)

Question

Estou prestes a começar a testar uma configuração master master usando o MySQL Group Replication. Eu configurei 2 (até agora) máquinas, provavelmente será um terceiro. Ambos possuem 2 nics, um para acesso a aplicativos e outro que possui apenas LAN IP para comunicação entre nós.

Eu vejo em alguns documentos onde menciona o uso de dois NICs, um para comunicação entre nós e um para comunicação com os aplicativos. Estou no ponto em que estou editando o arquivo /etc/mysql/my.cnf. Eu preciso entender essas configurações:

Digamos que meu aplicativo nic tenha um ip de 10.3.0.4 e o NIC de LAN apenas 10.3.1.4 Mesma configuração na máquina 2.

bind-address = "10.3.0.4"
report_host = "10.3.??" ??
loose-group_replication_local_address = "10.3.1.4:33061"

Qual IP o host de relatório pertence? Eu entendo que o loose-group_replication_local_address é essencialmente outro endereço de ligação, mas para a comunicação entre nós, mas não consigo encontrar nenhum exemplo de configurações multi-nic que também lidam com essas configurações. Todos os tutoriais que possuem essas linhas mostram colocar o mesmo ip devido a apenas um único nic.

Ambiente: Ubuntu 16.04 no Azure

Estou seguindo este guia para instalação: link

O pouco sobre dual nics vem de fragmentos de cerca de 6 páginas diferentes.

EDIT: @roothann endireitou-me sobre o que o host de relatórios deve fazer. Agora eu tenho um novo problemaOnce mysql foi reiniciado, porta 33061 não aparece no netstat, e eu recebo este erro nos logs: "Obtendo o nome do peer falhou ao conectar-se ao servidor 10.3.1.5 com erro 111 -Conexão recusada. [GCS] Erro ao abrir uma conexão para 10.3.1.5:33061 na porta local: 33061. Erro = 0 "Alguma idéia? Eu adicionei o plugin group_replication, mas quando eu faço este comando: mysql > START GROUP_REPLICATION; ERRO 3096 (HY000): O comando START GROUP_REPLICATION falhou porque houve um erro ao inicializar a camada de comunicação do grupo.

Isso é o que me fez verificar os logs e olhar para o netstat.

OUTRA EDIÇÃO: Conforme observado abaixo, por algum motivo, o comando de instalação segura não removeu a diretiva para apenas aceitar conexões localmente. Isso é fixo Novo problema é que os dados não estavam sendo sincronizados. O segundo nó saiu do grupo porque não conseguiu concluir a recuperação.

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | f0bcfc98-4255-11e8-b39f-000d3a1db637 | 10.3.1.4    |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

Então, por algum motivo, a replicação está tentando acontecer nas interfaces LAN, mas na porta mysql regular ao invés de 33061. Eu tentei consertar isso, e eu entendi isso:

mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PORT=33061, MASTER_PASSWORD='the password' FOR CHANNEL 'group_replication_recovery';

ERROR 3139 (HY000): CHANGE MASTER with the given parameters cannot be performed on channel 'group_replication_recovery'.

EDIT 17 de maio: Eu reconstruí o cluster a partir do zero, desta vez com 3 máquinas. Ainda o mesmo problema. O primeiro nó aparece. Os dois adicionais também aparecem, mas apenas mostram Recovering e, em seguida, são removidos do cluster.

no primeiro nó, eu obtenho isso no log:

2018-05-17T14:37:21.859153Z 27 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''.

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 38d4aa76-592f-11e8-814a-000d3a60e580 | 10.7.1.11   |       33061 | RECOVERING   | PRIMARY     | 8.0.11         |
| group_replication_applier | 3dbbb30f-592f-11e8-8fc7-000d3a603364 | 10.7.1.12   |       33061 | RECOVERING   | PRIMARY     | 8.0.11         |
| group_replication_applier | b0ff0148-592e-11e8-aa03-000d3a60e4cc | 10.7.1.10   |       33061 | ONLINE       | PRIMARY     | 8.0.11         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)

Eu recebo isso em logs de um dos outros servidores:

2018-05-17T14:57:17.970789Z 18 [ERROR] [MY-011583] [Repl] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'
2018-05-17T14:58:18.023898Z 18 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='10.7.1.10', master_port= 33061, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='10.7.1.10', master_port= 33061, master_log_file='', master_log_pos= 4, master_bind=''.

Estou percebendo que no primeiro nó, a variável master_host está vazia, enquanto no segundo, ela é preenchida com o ip do primário. Agora, como todos devem ser mestres, o primário não deveria ter algo assim?

Obrigado antecipadamente!