Ao contrário do servidor MySQL padrão e do MySQL Cluster, a maneira de iniciar um MySQL/MariaDB Galera Cluster é um pouco diferente. O Galera requer que você inicie um nó em um cluster como um ponto de referência, antes que os nós restantes possam se unir e formar o cluster. Esse processo é conhecido como bootstrap de cluster. Bootstrapping é uma etapa inicial para introduzir um nó de banco de dados como componente principal, antes que outros o vejam como um ponto de referência para sincronizar dados.
Como funciona?
Quando o Galera inicia com o comando bootstrap em um nó, esse nó específico atingirá o estado Primário (verifique o valor de wsrep_cluster_status). Os nós restantes exigirão apenas um comando de inicialização normal e procurarão automaticamente o Componente Primário (PC) existente no cluster e se unirão para formar um cluster. A sincronização de dados ocorre por meio de transferência de estado incremental (IST) ou transferência de estado de instantâneo (SST) entre o associador e o doador.
Então, basicamente, você só deve inicializar o cluster se quiser iniciar um novo cluster ou quando nenhum outro nó no cluster estiver no estado PRIMARY. Deve-se tomar cuidado ao escolher a ação a ser executada, caso contrário você pode acabar com clusters divididos ou perda de dados.
Os cenários de exemplo a seguir ilustram quando inicializar um cluster de três nós com base no estado do nó (wsrep_local_state_comment) e no estado do cluster (wsrep_cluster_status):
| Estado de Galera | Fluxo de inicialização |
|---|---|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
Como iniciar o Galera Cluster?
Os 3 fornecedores do Galera usam diferentes comandos de bootstrapping (com base na versão mais recente do software). No primeiro nó, execute:
-
Cluster MySQL Galera (Codificação):
$ service mysql bootstrap # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line -
Cluster Percona XtraDB (Percona):
$ service mysql bootstrap-pxc # sysvinit $ systemctl start [email protected] # systemd -
Cluster MariaDB Galera (MariaDB):
$ service mysql bootstrap # sysvinit $ service mysql start --wsrep-new-cluster # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
O comando acima é apenas um wrapper e o que ele realmente faz é iniciar a instância do MySQL nesse nó com gcomm:// como a variável wsrep_cluster_address. Você também pode definir manualmente as variáveis dentro de my.cnf e executar o comando padrão start/restart. No entanto, não se esqueça de alterar wsrep_cluster_address novamente para conter os endereços de todos os nós após o início.
Quando o primeiro nó estiver ativo, execute o seguinte comando nos nós subsequentes:
$ service mysql start
$ systemctl start mysqlO novo nó se conecta aos membros do cluster conforme definido pelo parâmetro wsrep_cluster_address. Ele agora recuperará automaticamente o mapa de cluster e se conectará ao restante dos nós e formará um cluster.
Aviso:nunca inicialize quando quiser reconectar um nó a um cluster existente e NUNCA execute a inicialização em mais de um nó.
Sinalizador de segurança para inicialização
Galera a partir da versão 3.19 vem com um novo sinalizador chamado “safe_to_bootstrap” dentro do grastate.dat. Esse sinalizador facilita a decisão e evita escolhas inseguras ao acompanhar a ordem em que os nós estão sendo desligados. O nó que foi desligado por último será marcado como “Seguro para Bootstrap”. Todos os outros nós serão marcados como inseguros para bootstrap.
Olhando para o conteúdo grastate.dat (o padrão está em MySQL datadir) e você deve notar o sinalizador na última linha:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: 2575
safe_to_bootstrap: 0Ao inicializar o novo cluster, o Galera se recusará a iniciar o primeiro nó marcado como inseguro para inicializar. Você verá a seguinte mensagem nos logs:
“Pode não ser seguro inicializar o cluster a partir deste nó. Não foi o último a sair do cluster e pode não conter todas as atualizações.
Para forçar a inicialização do cluster com este nó, edite o arquivo grastate.dat manualmente e defina safe_to_bootstrap como 1 .”
Em caso de desligamento não limpo ou falha grave, todos os nós terão “safe_to_bootstrap:0”, então temos que consultar o mecanismo de armazenamento InnoDB para determinar qual nó realizou a última transação no cluster. Isso pode ser alcançado iniciando o mysqld com a variável “--wsrep-recover” em cada um dos nós, que produz uma saída como esta:
$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...O número após a string UUID na linha "Recovered position" é o que deve ser procurado. Escolha o nó que possui o maior número e edite seu grastate.dat para definir “safe_to_bootstrap:1”, conforme mostrado no exemplo abaixo:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: -1
safe_to_bootstrap: 1Você pode então executar o comando bootstrap padrão no nó escolhido.
E se os nós tiverem divergido?
Em certas circunstâncias, os nós podem ter divergido uns dos outros. O estado de todos os nós pode se tornar Não-Primário devido à divisão da rede entre nós, falha do cluster ou se o Galera atingir uma exceção ao determinar o Componente Primário. Você precisará então selecionar um nó e promovê-lo a um Componente Primário.
Para determinar qual nó precisa ser inicializado, compare o valor wsrep_last_committed em todos os nós de banco de dados:
node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10032 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10348 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 997 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+Das saídas acima, o node2 tem os dados mais atualizados. Nesse caso, todos os nós do Galera já foram iniciados, portanto, você não precisa necessariamente inicializar o cluster novamente. Só precisamos promover o node2 para ser um Componente Primário:
node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";Os nós restantes se reconectarão ao Componente Primário (node2) e ressincronizarão seus dados com base nesse nó.
Se você estiver usando o ClusterControl (experimente gratuitamente), poderá determinar o wsrep_last_committed e o wsrep_cluster_status diretamente de ClusterControl> Visão geral página:
Ou em ClusterControl> Desempenho> Status do banco de dados página:
