As migrações de banco de dados não são bem dimensionadas. Normalmente, você precisa realizar muitos testes antes de puxar o gatilho e mudar do antigo para o novo. As migrações geralmente são feitas manualmente, pois a maior parte do processo não se presta à automação. Mas isso não significa que não há espaço para automação no processo de migração. Imagine configurar vários nós com novo software, provisionando-os com dados e configurando manualmente a replicação entre ambientes antigos e novos. Isso leva dias. A automação pode ser muito útil ao configurar um novo ambiente e provisioná-lo com dados. Nesta postagem do blog, veremos uma migração muito simples - do Percona Server 5.7 autônomo para um Percona XtraDB Cluster 5.7 de 3 nós. Usaremos o Ansible para fazer isso.
Descrição do ambiente
Em primeiro lugar, um aviso importante - o que vamos mostrar aqui é apenas um rascunho do que você gostaria de executar na produção. Ele funciona em nosso ambiente de teste, mas pode exigir modificações para torná-lo adequado ao seu ambiente. Em nossos testes, usamos quatro VMs do Ubuntu 16.04 implantadas usando o Vagrant. Um contém o Percona Server 5.7 autônomo, os três restantes serão usados para nós do Percona XtraDB Cluster. Também usamos um nó separado para executar playbooks ansible, embora isso não seja um requisito e o playbook também possa ser executado a partir de um dos nós. Além disso, a conectividade SSH está disponível entre todos os nós. Você precisa ter conectividade do host em que executa o ansible, mas é útil ter a capacidade de ssh entre nós (especialmente entre mestre e novo escravo - contamos com isso no manual).
Estrutura do manual
Os playbooks do Ansible normalmente compartilham uma estrutura comum - você cria funções, que podem ser atribuídas a diferentes hosts. Cada papel conterá tarefas a serem executadas nele, modelos que serão usados, arquivos que serão carregados, variáveis que são definidas para este manual específico. No nosso caso, a cartilha é muito simples.
.
├── inventory
├── playbook.yml
├── roles
│ ├── first_node
│ │ ├── my.cnf.j2
│ │ ├── tasks
│ │ │ └── main.yml
│ │ └── templates
│ │ └── my.cnf.j2
│ ├── galera
│ │ ├── tasks
│ │ │ └── main.yml
│ │ └── templates
│ │ └── my.cnf.j2
│ ├── master
│ │ └── tasks
│ │ └── main.yml
│ └── slave
│ └── tasks
│ └── main.yml
└── vars
└── default.ymlDefinimos alguns papéis - temos um papel mestre, que se destina a fazer algumas verificações de integridade no nó autônomo. Existe um nó escravo, que será executado em um dos nós do Galera para configurá-lo para replicação e configurar a replicação assíncrona. Em seguida, temos um papel para todos os nós do Galera e um papel para o primeiro nó do Galera para inicializar o cluster a partir dele. Para funções Galera, temos alguns modelos que usaremos para criar arquivos my.cnf. Também usaremos .my.cnf local para definir um nome de usuário e senha. Temos um arquivo contendo algumas variáveis que podemos personalizar, assim como as senhas. Por fim, temos um arquivo de inventário, que define os hosts nos quais executaremos o playbook, também temos o arquivo do playbook com informações de como exatamente as coisas devem ser executadas. Vamos dar uma olhada nos bits individuais.
Arquivo de inventário
Este é um arquivo muito simples.
[galera]
10.0.0.142
10.0.0.143
10.0.0.144
[first_node]
10.0.0.142
[master]
10.0.0.141Temos três grupos, 'galera', que contém todos os nós Galera, 'first_node', que usaremos para o bootstrap e, finalmente, 'master', que contém nosso nó autônomo do Percona Server.
Manual.yml
O arquivo playbook.yml contém as diretrizes gerais sobre como o playbook deve ser executado.
- hosts: master
gather_facts: yes
become: true
pre_tasks:
- name: Install Python2
raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
vars_files:
- vars/default.yml
roles:
- { role: master }Como você pode ver, começamos com o nó autônomo e aplicamos tarefas relacionadas à função 'mestre' (discutiremos isso em detalhes mais adiante neste post).
- hosts: first_node
gather_facts: yes
become: true
pre_tasks:
- name: Install Python2
raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
vars_files:
- vars/default.yml
roles:
- { role: first_node }
- { role: slave }Segundo, vamos para o nó definido no grupo ‘first_node’ e aplicamos dois papéis:‘first_node’ e ‘slave’. O primeiro destina-se a implantar um cluster PXC de nó único, o segundo o configurará para funcionar como escravo e configurará a replicação.
- hosts: galera
gather_facts: yes
become: true
pre_tasks:
- name: Install Python2
raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
vars_files:
- vars/default.yml
roles:
- { role: galera }Por fim, passamos por todos os nós do Galera e aplicamos a função 'galera' em todos eles.
Guia de DevOps para gerenciamento de banco de dados de vários novesSaiba mais sobre o que você precisa saber para automatizar e gerenciar seus bancos de dados de código abertoBaixe gratuitamente
Variáveis
Antes de começarmos a examinar as funções, queremos mencionar as variáveis padrão que definimos para este manual.
sst_user: "sstuser"
sst_password: "pa55w0rd"
root_password: "pass"
repl_user: "repl_user"
repl_password: "repl1cati0n"Como dissemos, este é um manual muito simples, sem muitas opções de personalização. Você pode configurar usuários e senhas e é basicamente isso. Uma pegadinha - certifique-se de que a senha raiz do nó autônomo corresponda a 'root_password' aqui, caso contrário, o manual não poderá se conectar lá (pode ser estendido para lidar com isso, mas não abordamos isso).
Este arquivo não tem muito valor, mas, como regra geral, você deseja criptografar qualquer arquivo que contenha credenciais. Obviamente, isso é por razões de segurança. O Ansible vem com o ansible-vault, que pode ser usado para criptografar e descriptografar arquivos. Não abordaremos detalhes aqui, tudo o que você precisa saber está disponível na documentação. Resumindo, você pode criptografar facilmente os arquivos usando senhas e configurar seu ambiente para que os playbooks possam ser descriptografados automaticamente usando a senha do arquivo ou passados manualmente.
Funções
Nesta seção, examinaremos os papéis definidos no manual, resumindo o que eles devem desempenhar.
Papel de mestre
Como afirmamos, essa função destina-se a executar uma verificação de integridade na configuração do MySQL autônomo. Ele instalará os pacotes necessários como percona-xtrabackup-24. Ele também cria um usuário de replicação no nó mestre. Uma configuração é revisada para garantir que o server_id e outras configurações relacionadas à replicação e ao log binário sejam definidas. O GTID também está habilitado, pois contaremos com ele para replicação.
Função do primeiro nó
Aqui, o primeiro nó Galera é instalado. O repositório Percona será configurado, my.cnf será criado a partir do template. O PXC será instalado. Também executamos algumas limpezas para remover usuários desnecessários e criá-los, que serão necessários (usuário root com a senha de nossa escolha, usuário necessário para SST). Por fim, o cluster é inicializado usando esse nó. Contamos com o 'wsrep_cluster_address' vazio como uma forma de inicializar o cluster. É por isso que mais tarde ainda executamos o papel 'galera' no primeiro nó - para trocar o my.cnf inicial pelo final, contendo 'wsrep_cluster_address' com todos os membros do cluster. Uma coisa que vale a pena lembrar - quando você cria um usuário root com senha, você deve ter cuidado para não ficar bloqueado no MySQL para que o Ansible possa executar outras etapas do manual. Uma maneira de fazer isso é fornecer a .my.cnf o usuário e a senha corretos. Outra seria lembrar de sempre definir login_user e login_password corretos no módulo ‘mysql_user’.
Papel de escravo
Essa função trata da configuração da replicação entre o nó autônomo e o cluster PXC de nó único. Usamos o xtrabackup para obter os dados, também verificamos o gtid executado em xtrabackup_binlog_info para garantir que o backup seja restaurado corretamente e que a replicação possa ser configurada. Também realizamos um pouco da configuração, garantindo que o nó escravo possa usar a replicação GTID. Existem algumas armadilhas aqui - não é possível executar 'RESET MASTER' usando o módulo 'mysql_replication' a partir do Ansible 2.7.10, deve ser possível fazer isso no 2.8, sempre que for lançado. Tivemos que usar o módulo 'shell' para executar comandos da CLI do MySQL. Ao reconstruir o nó Galera a partir de uma fonte externa, você deve se lembrar de recriar todos os usuários necessários (pelo menos o usuário usado para SST). Caso contrário, os nós restantes não poderão ingressar no cluster.
Função da Galera
Finalmente, esta é a função na qual instalamos o PXC nos dois nós restantes. Nós o executamos em todos os nós, o inicial obterá “produção” my.cnf em vez de sua versão “bootstrap”. Os dois nós restantes terão o PXC instalado e obterão SST do primeiro nó do cluster.
Resumo
Como você pode ver, você pode criar facilmente um playbook Ansible simples e reutilizável que pode ser usado para implantar o Percona XtraDB Cluster e configurá-lo para ser um escravo do nó MySQL autônomo. Para ser honesto, para migrar um único servidor, isso provavelmente não fará sentido, pois fazer o mesmo manualmente será mais rápido. Ainda assim, se você espera que terá que reexecutar esse processo algumas vezes, definitivamente fará sentido automatizá-lo e torná-lo mais eficiente em termos de tempo. Como dissemos no início, este não é de forma alguma um manual pronto para produção. É mais uma prova de conceito, algo que você pode estender para torná-lo adequado ao seu ambiente. Você pode encontrar o arquivo com o manual aqui:http://severalnines.com/sites/default/files/ansible.tar.gz
Esperamos que você tenha achado este post interessante e valioso, não hesite em compartilhar seus pensamentos.
