Olá pessoal!
Depois que uma tarefa apareceu no trabalho - parece haver um cluster de teste innoDB configurado em várias máquinas virtuais com o centos 7.5, você precisa estudá-lo e adicionar mais alguns nós. Você pode quebrar e zombar como quiser. Parece tentador.
Antes disso, eu não tinha experiência com esse cluster, mas o Google para ajudar.
Com algumas exceções, todos os links nele e no Yandex estavam no dev.mysql.com ou neste
artigo no Habr . Parece que um cluster de dois nós foi configurado nele.
Bem, eu li o artigo, fiquei um pouco surpreso com a complexidade de adicionar nós e a falta de muitos detalhes, mas tudo bem. Com um pecado, adicionei metade de um novo nó (alguns dos comandos não foram úteis, outros quebraram tudo), depois do qual comecei a experimentar o reinício dos nós, etc.
Após várias abordagens e inúmeras mortes de células nervosas, o cluster não aguentou mais. Um nó não queria ser adicionado sob nenhuma condição, o outro desligou quando tentei acessar o banco de dados, o terceiro fingiu que tudo estava em ordem. Eu tive que atirar e começar do zero.
Ao criar um novo cluster, infelizmente, muitos problemas e inconsistências surgiram. Talvez o ponto esteja nas versões de software, tentei o mysql 5.7. Talvez na distribuição. Como resultado, parei as tentativas impensadas de fazer tudo em um pedaço de papel e comecei a configurá-lo digitando. E google.
Algumas noites agradáveis e noites e o aglomerado se reuniu e até se recusou a desmoronar.
Ao mesmo tempo, o método de sua criação era notavelmente diferente das tentativas anteriores e eu queria compartilhá-lo, porque Na Internet, não encontrei outras instruções compreensíveis e relevantes relevantes para a configuração do cluster no inndoDB.
Portanto, temos três máquinas virtuais idênticas com o Centos 7.5 mínimo 1804 recém-instalado e o selinux e o firewalld desativados:
1.1.1.1
1.1.1.2
1.1.1.3
Para o trabalho, usei o mysql 5.7, por isso usamos. Vamos começar com 1.1.1.1:
1. Instale o repositório mysql-community:
rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
Desligue o repositório para 8, ligue-o para 5.7 e verifique - se está tudo bem, então instale o mysql:
yum install yum-utils yum-config-manager --disable mysql80-community yum-config-manager --enable mysql57-community yum repolist yum install mysql-community-server mysql-shell
2. Trazemos o /etc/my.cnf para este formulário:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock symbolic-links=0 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid bind-address=0.0.0.0 port=3301 # Replication part server_id=1 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 plugin-load = group_replication.so # Group replication part transaction_write_set_extraction=XXHASH64 loose-group_replication_start_on_boot = OFF loose-group_replication_local_address = 1.1.1.1:33011 loose-group_replication_bootstrap_group = OFF report_port = 3301 report_host = 1.1.1.1
Aqui 3301 é a porta na qual o mysql escutará e 33011 é a porta na qual os nós se comunicam.
3. Inicie o mysql e execute a configuração preliminar:
systemctl start mysqld grep 'password' /var/log/mysqld.log mysql_secure_installation
4. Crie um cluster e um usuário separado para gerenciá-lo. Se você souber com antecedência os endereços IP dos nós, poderá listá-los imediatamente na lista ipwhitel. Vamos fingir que ainda não sabemos sobre 1.1.1.2. e 1.1.1.3:
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.1:3301 > dba.checkInstanceConfiguration() > cl=dba.createCluster('TestCluster', {ipWhitelist: '1.1.1.1'}) > dba.configureLocalInstance() > cl.status()
Feito! O cl.status deve gerar algo como isto:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Ao alterar o cluster, será necessário executar o comando dba.configureLocalInstance () localmente em todos os nós para salvar as alterações:
WARNING: On instance '1.1.1.1:3301' membership change cannot be persisted since MySQL version 5.7.23 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the <Dba>.configureLocalInstance command locally to persist the changes.
Porque adicionaremos mais alguns nós, não fecharemos a conexão com o servidor 1.1.1.1, será útil para nós.
Agora vamos tentar adicionar o nó 1.1.1.2 ao cluster. Para fazer isso, executamos todos os mesmos comandos nele até 3 etapas, inclusive, sem esquecer de alterar server_id, loose-group_replication_local_address e report_host.
4. Executamos em 1.1.1.2:
mysql -p > set GLOBAL group_replication_allow_local_disjoint_gtids_join=ON;
Tentei definir essa variável através do mysqlsh, alternando para o modo sql, mas as ações não o afetaram no mysql. Seguinte:
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.2:3301 > dba.checkInstanceConfiguration()
5. Retorne ao primeiro nó 1.1.1.1. Se você fechou a conexão, poderá conectar-se rapidamente ao cluster assim:
mysqlsh --uri cladmin@1.1.1.1:3301 --cluster > \sql > STOP GROUP_REPLICATION; > SET GLOBAL group_replication_ip_whitelist="1.1.1.1,1.1.1.2"; > START GROUP_REPLICATION; > \js > cluster.addInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2'}) > cluster.status()
Por alguma razão, ao adicionar um nó sem a opção ipWhitelist, ele não é automaticamente transmitido a ele, portanto, nós o especificamos manualmente.
Se sua lista de permissões estiver configurada inicialmente para todos os nós ou uma sub-rede, os comandos no modo sql poderão ser ignorados.
Não esqueça de executar dba.configureLocalInstance () em todos os nós para salvar a configuração.
O cluster de seus dois nós acabou:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Bem, há um cluster de dois nós, mas no "Cluster NÃO é tolerante a nenhuma falha".
Adicione um terceiro, o algoritmo é basicamente o mesmo que adicionar um segundo.
Se você precisar alterar novamente a lista de desbloqueio, execute os comandos no nó r / w, porque em nós de r / o, parece não levar a nada. Nesse caso, os nós de E / S cairão e precisarão ser reconectados, relatando simultaneamente uma nova lista de permissões.
No nosso caso:
> cluster.rejoinInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2,1.1.1.3'})
Bem, novamente, não se esqueça de executar o dba.configureLocalInstance () em todos os nós para salvar a configuração.
Um cluster de três nós se parece com isso:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.3:3301": { "address": "1.1.1.3:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Se o cluster tiver recolhido o estado de um nó, ele precisará ser iniciado com o parâmetro loose-group_replication_bootstrap_group = ON no /etc/my.cnf
Após a inicialização, o parâmetro precisará ser desativado novamente, caso contrário, esse nó sempre será separado do cluster e manterá seu próprio.
A instalação do mysql-router está bem descrita
aqui , então não vejo sentido em duplicar.
É isso, espero que alguém ache minha experiência útil.
Obrigado pela atenção.