Recuperação do nó Percona XtraDB Cluster

Question

Eu revisei o clustering do XtraDB e produzi um P.o.C. ambiente no Openstack usando 4 instâncias, que caiu durante o teste de resiliência.

De acordo com a documentação do pxc: link que abrange uma instalação de 3 nós optou por um quarto.

1. Testes de carregamento de dados completos da configuração inicial aprovados, com todos os nós sendo atualizados de forma síncrona usando um arquivo sql de teste de 1,6 GB para carregar um banco de dados.
2. Falha e restauração de nós iniciados, este teste implicou a interrupção do serviço mysql em um nó, a criação e subsequente descarte de um banco de dados para testar a replicação de nó sobrevivente e a inicialização do nó desativado para ressincronizar.
   1. Isso funcionou bem para nós 4,3,2.
   O
   2. Nó1, que, de acordo com os documentos pxc, é essencialmente um controlador, não voltaria a se agrupar no cluster.

Então, minhas perguntas são as seguintes:

1. Como retornar um nó do controlador para serviço se os nós sobreviventes tiverem dados gravados neles
2. Usando 4 nós como referência, existe uma maneira de remover esse ponto único de falha no nó1? (se um nó sobrevivente for reiniciado com o controlador (nó1) inativo / desatualizado, esse nó também falhará).

Answer 1

Com base nos seus sintomas no nó um, você está usando

wsrep_cluster_address=gcomm:// 

no seu arquivo de configuração, o que significa que o nó iniciará um novo cluster. Você pode confirmar isso com a variável wsrep_cluster_size sendo 1 no node1 e 3 nos outros. Se você deseja unir o node1 ao seu cluster já existente, você deve especificar

wsrep_cluster_address=gcomm://(ip of a running node here)

Nesse caso, node1 irá se juntar ao cluster.

Algumas ideias adicionais:

• Devido ao mecanismo de quorum no PXC (Percona Xtradb Cluster), não é recomendado executá-lo em 4 nós. É recomendável usar um número ímpar de nós, portanto, no caso de uma divisão de rede, uma parte do cluster dividido poderá ter a maioria.

• Em vez de wsrep_cluster_address, você pode usar wsrep_urls na seção [mysqld_safe].

Disclaimer: Eu trabalho para Percona.

    

Answer 2

Mais pesquisas sobre esta questão parece que este é um método viável (deixando esta resposta inaceitável no momento, caso alguém responda com uma melhor configuração):

1. Configuração circular
   A documentação
   1. per pxc tem todos os nós sincronizados a partir do nó 1
   2. pare o node2 reponha para node3, inicie o nó 2
   3. pare o node3 reponha para node4, inicie o nó 3
   4. pare o node1 reponha para node2, inicie o nó 1

Esta configuração parece conter a perda de qualquer nó por desconexão, pelo menos, e a restauração das sincronizações de nós sem problemas.

    

Answer 3

Se o Mysql não iniciar, o motivo é uma tabela de banco de dados corrompida.

replique o que o servidor está fazendo e obtenha uma boa cópia de um servidor parado para o dbs do cliente.

ele tars os arquivos de $ MYSQLHOME que são db via um nc.

usamos o scp para mover os arquivos bons para o lugar e, em seguida, iniciamos a sincronização novamente iniciando o mysql do servidor incorreto.