Início / dba / Perguntas / 73044
Accepted
Luke Nguyen
Asked: 2014-08-04 01:49:01 +0800 CST

Cluster MySQL: Failover entre o nó de dados

  • 772

Hoje, faço algumas expirações para entender melhor o cluster MySQL.

O cluster MySQL funciona bem:

ndb_mgm> show

Connected to Management Server at: localhost:1186

Cluster Configuration

[ndbd(NDB)]2 node(s)

[email protected]  (mysql-5.6.19 ndb-7.3.6, Nodegroup: 0, *)

[email protected]  (mysql-5.6.19 ndb-7.3.6, Nodegroup: 0)

[ndb_mgmd(MGM)]1 node(s)

[email protected]  (mysql-5.6.19 ndb-7.3.6)

[mysqld(API)]1 node(s)

[email protected]  (mysql-5.6.19 ndb-7.3.6)

Caso 1: desligo o nó de gerenciamento por killall ndb_mgmd e mato um nó de dados por killall ndbd. Vejo que o nó de dados restantes está desativado, embora eu não faça nada com ele. Não há nó de dados ao vivo, portanto, é impossível obter ou alterar dados do nó sql.

Caso 2: Mantenho o nó de gerenciamento ativo. Eu mato um nó de dados por killall ndbd. Vejo que o nó de dados restante ainda está vivo, então o nó sql ainda funciona bem.

Eu tenho uma pergunta. Devo manter o nó de gerenciamento para controlar nós de dados? Eu não li o manual de referência do mysql mencionar o caso semelhante.

Agradeço antecipadamente.

mysql mysql-cluster

1 respostas

  1. Best Answer

    O nó de gerenciamento não é essencial para as operações normais do mysql, exceto em:

    • Instalação e outras operações de manutenção em todo o cluster
    • Por padrão, é o nó do árbitro, o que significa que ele detém a responsabilidade de decidir se uma partição específica continua em execução no caso de um cérebro dividido.

    Cérebro dividido é um conceito importante em agrupamento, que acontece quando, aparentemente, um grupo de nós identifica algum outro grupo de nós como inativo (um grupo pode ser um único nó). No entanto, você não pode ter certeza se eles estão realmente inativos ou se a comunicação entre eles está inativa. Para manter a consistência, um algoritmo deve decidir o que fazer. Caso contrário, suas partições separadas do cluster podem acabar com diferentes estados/conjuntos de dados. Normalmente, e é isso que acontece, se a sua partição tiver mais de 50% dos nós, você continua, se não, você para.

    No seu caso particular, sem um árbitro, como 1 nó é apenas 50% dos nós de dados, ele decide "se matar" - não é uma falha, é uma decisão de design. Com o árbitro, sabemos que o outro nó não continuará sozinho, pois o árbitro não pode vê-lo, então ele decide continuar com 50% dos nós (1, que tem todos os dados, pois o padrão é noofreplicas = 2 ) + árbitro. Em geral, você deseja executar com um número ímpar de nós para minimizar a possibilidade de desligamento total do cluster.

    Normalmente, em uma configuração NDB, seus nós SQL também são um nó arbitrador primário e secundário (você pode modificar seus pesos). Você normalmente tem mais de um nó de API, para evitar um único ponto de falha. Portanto, a configuração mais comum é de 2 nós API/SQL/árbitro e 2 nós NDB. Dessa forma, na maioria dos casos, 2 nós precisam ficar inativos para que todo o cluster falhe .

    • 2

relate perguntas