Existem várias maneiras de implantar um banco de dados. Você pode instalá-lo manualmente, pode confiar nas ferramentas de orquestração de infraestrutura amplamente disponíveis, como Ansible, Chef, Puppet ou Salt. Essas ferramentas são muito populares e é muito fácil encontrar scripts, receitas, playbooks, o que quiser, o que o ajudará a automatizar a instalação de um cluster de banco de dados. Existem também plataformas de automação de banco de dados mais especializadas, como ClusterControl, que também podem ser usadas para implantação automatizada. Qual seria a melhor maneira de implantar seu cluster? Quanto tempo você realmente precisará para implantá-lo?
Primeiro, vamos esclarecer o que queremos fazer. Vamos supor que estaremos implantando o Percona XtraDB Cluster 5.7. Ele será composto por três nós e para isso usaremos três máquinas virtuais Vagrant rodando Ubuntu 16.04 (imagem bento/ubuntu-16.04). Tentaremos implantar um cluster manualmente, usando Ansible e ClusterControl. Vamos ver como serão os resultados.
Implantação manual
Configuração do repositório - 1 minuto e 45 segundos.
Antes de tudo, temos que configurar os repositórios Percona em todos os nós do Ubuntu. Pesquisa rápida no google, ssh nas máquinas virtuais e execução dos comandos necessários leva 1m45s
Encontramos a seguinte página com instruções:
https://www.percona.com/doc/percona-repo-config/percona-release.html
e executamos as etapas descritas na seção “DISTRIBUIÇÕES GNU/LINUX BASEADAS EM DEB”. Também rodamos o apt update, para atualizar o cache do apt.
Instalação de nós PXC - 2 minutos e 45 segundos
Esta etapa consiste basicamente em executar:
[email protected]:~# apt install percona-xtradb-cluster-5.7O resto depende principalmente da velocidade da sua conexão com a Internet, pois os pacotes estão sendo baixados. Sua entrada também será necessária (você passará uma senha para o superusuário) para que não seja uma instalação autônoma. Quando tudo estiver pronto, você terá três nós do Percona XtraDB Cluster em execução:
root 15488 0.0 0.2 4504 1788 ? S 10:12 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 15847 0.3 28.3 1339576 215084 ? Sl 10:12 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1Configurando nós PXC - 3 minutos, 25 segundos
Aqui começa a parte complicada. É realmente difícil quantificar a experiência e quanto tempo seria necessário para realmente entender o que é necessário fazer. O que é bom, a pesquisa no google “como instalar o cluster percona xtrabdb” aponta para a documentação do Percona, que descreve como deve ser o processo. Ainda pode demorar mais ou menos tempo, dependendo de quão familiarizado você está com o PXC e Galera em geral. Na pior das hipóteses, você não estará ciente de nenhuma ação adicional necessária e se conectará ao seu PXC e começará a trabalhar com ele, sem perceber que, na verdade, você tem três nós, cada um formando um cluster próprio.
Vamos supor que seguimos a recomendação de Percona e cronometramos apenas essas etapas para serem executadas. Em resumo, modificamos os arquivos de configuração conforme instruções no site da Percona, também tentamos inicializar o primeiro nó:
[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
* Bootstrapping Percona XtraDB Cluster database server mysqld ^CIsso não parecia correto. Infelizmente, as instruções não eram claras. Novamente, se você não souber o que está acontecendo, passará mais tempo tentando entender o que aconteceu. Felizmente, stackoverflow.com é muito útil (embora não seja a primeira resposta na lista que recebemos) e você deve perceber que perdeu o cabeçalho da seção [mysqld] em seu arquivo /etc/mysql/my.cnf. Adicionar isso em todos os nós e repetir o processo de bootstrap resolveu o problema. No total, gastamos 3 minutos e 25 segundos (sem incluir pesquisando o erro, pois percebemos imediatamente qual era o problema).
Configurando para SST, trazendo outros nós para o cluster - a partir de 8 minutos até o infinito
As instruções no site da Percona são bastante claras. Depois de ter um nó em execução, basta iniciar os nós restantes e você ficará bem. Tentamos isso e não conseguimos ver mais nós entrando no cluster. É aqui que é praticamente impossível dizer quanto tempo levará para diagnosticar o problema. Demorou de 6 a 7 minutos, mas para poder fazer isso rapidamente, você precisa:
- Conheça como a configuração do PXC é estruturada:
[email protected]:~# tree /etc/mysql/ /etc/mysql/ ├── conf.d │ ├── mysql.cnf │ └── mysqldump.cnf ├── my.cnf -> /etc/alternatives/my.cnf ├── my.cnf.fallback ├── my.cnf.old ├── percona-xtradb-cluster.cnf └── percona-xtradb-cluster.conf.d ├── client.cnf ├── mysqld.cnf ├── mysqld_safe.cnf └── wsrep.cnf - Saiba como as diretivas !include e !includedir funcionam nos arquivos de configuração do MySQL
- Saiba como o MySQL lida com as mesmas variáveis incluídas em vários arquivos
- Saiba o que procurar e esteja ciente das configurações que resultariam na autoinicialização do nó para formar um cluster por conta própria
O problema estava relacionado ao fato de que as instruções não mencionavam nenhum arquivo exceto /etc/mysql/my.cnf onde, de fato, deveríamos estar modificando /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf. Esse arquivo continha uma variável vazia:
wsrep_cluster_address=gcomm://e tal configuração força o nó a ser inicializado, pois não possui informações sobre outros nós aos quais se juntar. Definimos essa variável em /etc/mysql/my.cnf, mas depois o arquivo wsrep.cnf foi incluído, substituindo nossa configuração.
Esse problema pode ser um sério bloqueador para pessoas que não estão realmente familiarizadas com o funcionamento do MySQL e do Galera, resultando em horas, se não mais, de depuração.
Tempo total de instalação - 16 minutos (se você for MySQL DBA como eu)
Conseguimos instalar o Percona XtraDB Cluster em 16 minutos. Você deve ter em mente algumas coisas - nós não ajustamos a configuração. Isso é algo que exigirá mais tempo e conhecimento. O nó PXC vem com algumas configurações simples, relacionadas principalmente ao log binário e à replicação do conjunto de gravações Galera. Não há ajuste InnoDB. Se você não estiver familiarizado com os componentes internos do MySQL, são horas, senão dias, de leitura e familiarização com os mecanismos internos. Outra coisa importante é que esse é um processo que você precisaria reaplicar para cada cluster implantado. Por fim, conseguimos identificar o problema e resolvê-lo muito rapidamente devido à nossa experiência com Percona XtraDB Cluster e MySQL em geral. O usuário casual provavelmente gastará muito mais tempo tentando entender o que está acontecendo e por quê.
Manual do Ansible
Agora, vamos à automação com o Ansible. Vamos tentar encontrar e usar um playbook ansible, que possamos reutilizar para todas as outras implantações. Vamos ver quanto tempo levará para fazer isso.
Configurando a conectividade SSH - 1 minuto
O Ansible requer conectividade SSH em todos os nós para conectá-los e configurá-los. Geramos uma chave SSH e a distribuímos manualmente entre os nós.
Encontrando o Ansible Playbook - 2 minutos e 15 segundos
O principal problema aqui é que existem tantos playbooks disponíveis por aí que é impossível decidir o que é melhor. Como tal, decidimos ir com os 3 principais resultados do Google e tentar escolher um. Decidimos por https://github.com/cdelgehier/ansible-role-XtraDB-Cluster, pois parece ser mais configurável do que os restantes.
Clonagem do repositório e instalação do Ansible - 30 segundos
Isso é rápido, tudo o que precisávamos era
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitPreparando o arquivo de inventário - 1 minuto e 10 segundos
Esta etapa também foi muito simples, criamos um arquivo de inventário usando exemplo da documentação. Acabamos de substituir os endereços IP dos nós pelo que configuramos em nosso ambiente.
Preparando um manual - 1 minuto e 45 segundos
Decidimos usar o exemplo mais extenso da documentação, que inclui também um pouco do ajuste de configuração. Preparamos uma estrutura correta para o Ansible (não havia essa informação na documentação):
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterEm seguida, executamos, mas imediatamente recebemos um erro:
[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
[WARNING]: provided hosts list is empty, only localhost is available
ERROR! no action detected in task
The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: "Include {{ ansible_distribution }} tasks"
^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:
with_items:
- {{ foo }}
Should be written as:
with_items:
- "{{ foo }}"Isso levou 1 minuto e 45 segundos.
Corrigindo o problema de sintaxe do Playbook - 3 minutos e 25 segundos
O erro foi enganoso, mas a regra geral é tentar a versão mais recente do Ansible, o que fizemos. Pesquisamos no Google e encontramos boas instruções no site do Ansible. A próxima tentativa de executar o playbook também falhou:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}A configuração da nova versão do Ansible e a execução do playbook até esse erro levaram 3 minutos e 25 segundos.
Corrigindo o módulo Python ausente - 3 minutos e 20 segundos
Aparentemente, a função que usamos não atendeu seus pré-requisitos e um módulo Python estava faltando para conectar e proteger o cluster Galera. Primeiro tentamos instalar o MySQL-python via pip, mas ficou claro que levará mais tempo, pois exigia mysql_config:
[email protected]:~# pip install MySQL-python
Collecting MySQL-python
Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
100% |████████████████████████████████| 112kB 278kB/s
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
metadata, options = get_config()
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
libs = mysql_config("libs_r")
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
raise EnvironmentError("%s not found" % (mysql_config.path,))
EnvironmentError: mysql_config not found
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/Isso é fornecido pelas bibliotecas de desenvolvimento do MySQL, então teríamos que instalá-las manualmente, o que era praticamente inútil. Decidimos usar o PyMySQL, que não exigia a instalação de outros pacotes. Isso nos levou a outra questão:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryAté este ponto, passamos 3 minutos e 20 segundos.
Corrigindo o erro "Acesso negado" - 18 minutos e 55 segundos
Conforme o erro, garantimos que a configuração do MySQL foi preparada corretamente e que incluiu o usuário e a senha corretos para se conectar ao banco de dados. Isso, infelizmente, não funcionou como esperado. Investigamos mais e descobrimos que a função não criou o usuário root corretamente, embora tenha marcado a etapa como concluída. Fizemos uma breve investigação, mas decidimos fazer a correção manual em vez de tentar depurar o manual, o que levaria muito mais tempo do que as etapas que fizemos. Acabamos de criar manualmente os usuários [email protected] e [email protected] com as senhas corretas. Isso nos permitiu passar esta etapa e para outro erro:
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryPara esta seção, gastamos 18 minutos e 55 segundos.
Corrigindo o problema "Iniciar os nós escravos" (parte 1) - 7 minutos e 40 segundos
Tentamos algumas coisas para resolver esse problema. Tentamos especificar o nó usando seu nome, tentamos trocar os nomes dos grupos, nada resolveu o problema. Decidimos limpar o ambiente usando o script fornecido na documentação e começar do zero. Não o limpou, mas apenas tornou as coisas ainda piores. Após 7 minutos e 40 segundos, decidimos eliminar as máquinas virtuais, recriar o ambiente e começar do zero, esperando que, quando adicionarmos as dependências do Python, isso resolva nosso problema.
Corrigindo o problema "Iniciar os nós escravos" (parte 2) - 13 minutos e 15 segundos
Infelizmente, configurar os pré-requisitos do Python não ajudou em nada. Decidimos terminar o processo manualmente, inicializando o primeiro nó e depois configurando o usuário SST e iniciando os escravos restantes. Isso completou a configuração “automatizada” e levamos 13 minutos e 15 segundos para depurar e, finalmente, aceitar que não funcionará como o designer do playbook esperava.
Depuração adicional - 10 minutos e 45 segundos
Não paramos por aí e decidimos que vamos tentar mais uma coisa. Em vez de depender de variáveis do Ansible, apenas colocamos o IP de um dos nós como o nó mestre. Isso resolveu essa parte do problema e acabamos com:
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}Este foi o fim de nossas tentativas - tentamos adicionar este usuário, mas ele não funcionou corretamente através do playbook ansible, enquanto poderíamos usar o endereço de host local IPv6 para conectar ao usar o cliente MySQL.
Tempo total de instalação - Desconhecido (Falha na instalação automatizada)
No total, passamos 64 minutos e ainda não conseguimos fazer as coisas acontecerem automaticamente. Os problemas restantes são a criação de senha de root que parece não funcionar e, em seguida, iniciar o Galera Cluster (problema do usuário SST). É difícil dizer quanto tempo levará para depurá-lo ainda mais. Com certeza é possível - é difícil quantificar porque realmente depende da experiência com o Ansible e o MySQL. Definitivamente, não é algo que qualquer um pode simplesmente baixar, configurar e executar. Bem, talvez outro manual teria funcionado de forma diferente? É possível, mas também pode resultar em problemas diferentes. Ok, então há uma curva de aprendizado a ser escalada e depuração a ser feita, mas, quando estiver tudo pronto, você apenas executará um script. Bem, isso é meio verdade. Contanto que as alterações introduzidas pelo mantenedor não interrompam algo de que você dependa ou uma nova versão do Ansible interrompa o manual ou o mantenedor simplesmente esqueça o projeto e pare de desenvolvê-lo (para a função que usamos há um pull request bastante útil aguardando já há quase um ano, o que pode resolver o problema de dependência do Python - ele não foi mesclado). A menos que você aceite que terá que manter esse código, você não pode realmente confiar que ele seja 100% preciso e funcione em seu ambiente, especialmente porque o desenvolvedor original não tem incentivos para manter o código atualizado. Além disso, e as outras versões? Você não pode usar este manual específico para instalar o PXC 5.6 ou qualquer versão do MariaDB. Claro, existem outros manuais que você pode encontrar. Eles funcionarão melhor ou talvez você passe mais horas tentando fazê-los funcionar?
ClusterControlSingle Console para toda a sua infraestrutura de banco de dados Descubra o que mais há de novo no ClusterControlInstale o ClusterControl GRATUITAMENTE
Controle de cluster
Por fim, vamos dar uma olhada em como o ClusterControl pode ser usado para implantar o Percona XtraDB Cluster.
Configurando a conectividade SSH - 1 minuto
O ClusterControl requer conectividade SSH em todos os nós para conectá-los e configurá-los. Geramos uma chave SSH e a distribuímos manualmente entre os nós.
Configurando o ClusterControl - 3 minutos e 15 segundos
A pesquisa rápida “Instalação do ClusterControl” nos apontou para a página de documentação relevante do ClusterControl. Estávamos procurando uma “maneira mais simples de instalar o ClusterControl”, portanto, seguimos o link e encontramos as seguintes instruções.
Baixar o script e executá-lo levou 3 minutos e 15 segundos, tivemos que realizar algumas ações enquanto a instalação prosseguia para que não fosse uma instalação autônoma.
Login na interface do usuário e início da implantação - 1 minuto e 10 segundos
Apontamos nosso navegador para o IP do nó ClusterControl.
Passamos as informações de contato necessárias e nos foi apresentada a tela de boas-vindas:
Próxima etapa - escolhemos a opção de implantação.
Tivemos que passar os detalhes da conectividade SSH.
Também decidimos o fornecedor, a versão, a senha e os hosts a serem usados. Todo esse processo levou 1 minuto e 10 segundos.
Implantação do cluster Percona XtraDB - 12 minutos e 5 segundos
A única coisa que restava era esperar que o ClusterControl terminasse a implantação. Após 12 minutos e 5 segundos, o cluster estava pronto:
Tempo total de instalação - 17 minutos e 30 segundos
Recursos relacionados ClusterControl for MySQL ClusterControl for MariaDB ClusterControl for Galera ClusterConseguimos implantar o ClusterControl e depois o cluster PXC usando o ClusterControl em 17 minutos e 30 segundos. A implantação do PXC levou 12 minutos e 5 segundos . No final temos um cluster de trabalho, implantado de acordo com as melhores práticas. O ClusterControl também garante que a configuração do cluster faça sentido. Resumindo, mesmo que você não saiba nada sobre MySQL ou Galera Cluster, você pode ter um cluster pronto para produção implantado em alguns minutos. ClusterControl não é apenas uma ferramenta de implantação, é também uma plataforma de gerenciamento - torna as coisas ainda mais fáceis para pessoas sem experiência com MySQL e Galera identificar problemas de desempenho (através de conselheiros) e fazer ações de gerenciamento (dimensionar o cluster para cima e para baixo, executar backups, criar escravos assíncronos para Galera). O que é importante, ClusterControl será sempre mantido e pode ser usado para implantar todos os tipos de MySQL (e não apenas MySQL/MariaDB, ele também suporta TimeScaleDB, PostgreSQL e MongoDB). Também funcionou fora da caixa, algo que não pode ser dito sobre outros métodos que testamos.
Se você gostaria de experimentar o mesmo, você pode baixar ClusterControl gratuitamente. Deixe-nos saber como você gostou.
