Mysql
 sql >> Base de données >  >> RDS >> Mysql

Comment automatiser la migration de MySQL autonome vers le cluster Galera à l'aide d'Ansible

Les migrations de bases de données ne s'adaptent pas bien. En règle générale, vous devez effectuer de nombreux tests avant de pouvoir appuyer sur la gâchette et passer de l'ancien au nouveau. Les migrations sont généralement effectuées manuellement, car la majeure partie du processus ne se prête pas à l'automatisation. Mais cela ne signifie pas qu'il n'y a pas de place pour l'automatisation dans le processus de migration. Imaginez configurer un certain nombre de nœuds avec de nouveaux logiciels, les provisionner avec des données et configurer manuellement la réplication entre les anciens et les nouveaux environnements. Cela prend des jours. L'automatisation peut être très utile lors de la configuration d'un nouvel environnement et de son approvisionnement en données. Dans cet article de blog, nous examinerons une migration très simple - de Percona Server 5.7 autonome vers un Percona XtraDB Cluster 5.7 à 3 nœuds. Nous utiliserons Ansible pour y parvenir.

Description de l'environnement

Tout d'abord, une clause de non-responsabilité importante - ce que nous allons montrer ici n'est qu'un brouillon de ce que vous aimeriez exécuter en production. Il fonctionne sur notre environnement de test, mais il peut nécessiter des modifications pour l'adapter à votre environnement. Dans nos tests, nous avons utilisé quatre machines virtuelles Ubuntu 16.04 déployées à l'aide de Vagrant. L'un contient Percona Server 5.7 autonome, les trois autres seront utilisés pour les nœuds Percona XtraDB Cluster. Nous utilisons également un nœud séparé pour exécuter des playbooks ansibles, bien que ce ne soit pas une exigence et que le playbook puisse également être exécuté à partir de l'un des nœuds. De plus, la connectivité SSH est disponible entre tous les nœuds. Vous devez avoir une connectivité depuis l'hôte sur lequel vous exécutez ansible, mais avoir la possibilité de ssh entre les nœuds est utile (en particulier entre le maître et le nouvel esclave - nous nous appuyons sur cela dans le playbook).

Structure du livre de jeu

Les playbooks Ansible partagent généralement une structure commune - vous créez des rôles, qui peuvent être attribués à différents hôtes. Chaque rôle contiendra des tâches à exécuter dessus, des modèles qui seront utilisés, des fichiers qui seront téléchargés, des variables qui sont définies pour ce playbook particulier. Dans notre cas, le playbook est très simple.

.
├── 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.yml

Nous avons défini quelques rôles - nous avons un rôle principal, qui est destiné à effectuer des vérifications d'intégrité sur le nœud autonome. Il y a un nœud esclave, qui sera exécuté sur l'un des nœuds Galera pour le configurer pour la réplication et configurer la réplication asynchrone. Ensuite, nous avons un rôle pour tous les nœuds Galera et un rôle pour le premier nœud Galera pour amorcer le cluster à partir de celui-ci. Pour les rôles Galera, nous avons quelques modèles que nous utiliserons pour créer des fichiers my.cnf. Nous utiliserons également le .my.cnf local pour définir un nom d'utilisateur et un mot de passe. Nous avons un fichier contenant quelques variables que nous pouvons personnaliser, tout comme les mots de passe. Enfin, nous avons un fichier d'inventaire, qui définit les hôtes sur lesquels nous allons exécuter le playbook, nous avons également le fichier playbook avec des informations sur la manière exacte dont les choses doivent être exécutées. Jetons un coup d'œil aux éléments individuels.

Fichier d'inventaire

C'est un fichier très simple.

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

Nous avons trois groupes, 'galera', qui contient tous les nœuds Galera, 'first_node', que nous utiliserons pour le bootstrap et enfin 'master', qui contient notre nœud Percona Server autonome.

Playbook.yml

Le fichier playbook.yml contient les directives générales sur la façon dont le playbook doit être exécuté.

-   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 }

Comme vous pouvez le voir, nous commençons par le nœud autonome et nous appliquons des tâches liées au rôle "maître" (nous en discuterons en détail plus loin dans cet article).

-   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 }

Deuxièmement, nous allons au nœud défini dans le groupe "first_node" et nous appliquons deux rôles :"first_node" et "slave". Le premier est destiné à déployer un cluster PXC à nœud unique, le second le configurera pour fonctionner en tant qu'esclave et configurera la réplication.

-   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 }

Enfin, nous parcourons tous les nœuds Galera et appliquons le rôle "galera" sur chacun d'eux.

Guide DevOps de la gestion des bases de données de ManyninesDécouvrez ce que vous devez savoir pour automatiser et gérer vos bases de données open sourceTélécharger gratuitement

Variables

Avant de commencer à examiner les rôles, nous souhaitons mentionner les variables par défaut que nous avons définies pour ce playbook.

sst_user: "sstuser"
sst_password: "pa55w0rd"
root_password: "pass"
repl_user: "repl_user"
repl_password: "repl1cati0n"

Comme nous l'avons dit, il s'agit d'un playbook très simple sans beaucoup d'options de personnalisation. Vous pouvez configurer les utilisateurs et les mots de passe et c'est tout. Un piège - assurez-vous que le mot de passe root du nœud autonome correspond à "root_password" ici, sinon le playbook ne pourrait pas s'y connecter (il peut être étendu pour le gérer, mais nous n'avons pas couvert cela).

Ce fichier n'a pas beaucoup de valeur mais, en règle générale, vous souhaitez chiffrer tout fichier contenant des informations d'identification. Évidemment, c'est pour des raisons de sécurité. Ansible est livré avec ansible-vault, qui peut être utilisé pour chiffrer et déchiffrer des fichiers. Nous ne couvrirons pas les détails ici, tout ce que vous devez savoir est disponible dans la documentation. En bref, vous pouvez facilement chiffrer des fichiers à l'aide de mots de passe et configurer votre environnement afin que les playbooks puissent être déchiffrés automatiquement à l'aide du mot de passe du fichier ou passés à la main.

Rôles

Dans cette section, nous passerons en revue les rôles définis dans le playbook, en résumant ce qu'ils sont censés accomplir.

Rôle principal

Comme nous l'avons indiqué, ce rôle est destiné à exécuter une vérification de l'intégrité de la configuration du MySQL autonome. Il installera les packages requis tels que percona-xtrabackup-24. Il crée également un utilisateur de réplication sur le nœud maître. Une configuration est examinée pour s'assurer que le server_id et d'autres paramètres liés à la réplication et au journal binaire sont définis. GTID est également activé car nous nous en appuierons pour la réplication.

Rôle du premier_nœud

Ici, le premier nœud Galera est installé. Le référentiel Percona sera configuré, my.cnf sera créé à partir du modèle. PXC sera installé. Nous effectuons également un nettoyage pour supprimer les utilisateurs inutiles et créer ceux qui seront nécessaires (utilisateur root avec le mot de passe de notre choix, utilisateur requis pour SST). Enfin, le cluster est amorcé à l'aide de ce nœud. Nous nous appuyons sur le "wsrep_cluster_address" vide pour initialiser le cluster. C'est pourquoi plus tard, nous exécutons toujours le rôle 'galera' sur le premier nœud - pour échanger mon.cnf initial avec le dernier, contenant 'wsrep_cluster_address' avec tous les membres du cluster. Une chose à retenir - lorsque vous créez un utilisateur root avec un mot de passe, vous devez faire attention à ne pas verrouiller MySQL afin qu'Ansible puisse exécuter d'autres étapes du playbook. Une façon de le faire est de fournir à .my.cnf un nom d'utilisateur et un mot de passe corrects. Une autre serait de se rappeler de toujours définir les bons login_user et login_password dans le module 'mysql_user'.

Rôle d'esclave

Ce rôle consiste à configurer la réplication entre le nœud autonome et le cluster PXC à nœud unique. Nous utilisons xtrabackup pour obtenir les données, nous vérifions également le gtid exécuté dans xtrabackup_binlog_info pour nous assurer que la sauvegarde sera restaurée correctement et que la réplication peut être configurée. Nous effectuons également une partie de la configuration, en nous assurant que le nœud esclave peut utiliser la réplication GTID. Il y a quelques pièges ici - il n'est pas possible d'exécuter 'RESET MASTER' en utilisant le module 'mysql_replication' à partir d'Ansible 2.7.10, il devrait être possible de le faire en 2.8, chaque fois qu'il sortira. Nous avons dû utiliser le module "shell" pour exécuter les commandes MySQL CLI. Lors de la reconstruction du nœud Galera à partir d'une source externe, vous devez vous rappeler de recréer tous les utilisateurs requis (au moins l'utilisateur utilisé pour SST). Sinon, les nœuds restants ne pourront pas rejoindre le cluster.

Rôle de galère

Enfin, c'est le rôle dans lequel nous installons PXC sur les deux nœuds restants. Nous l'exécutons sur tous les nœuds, le premier obtiendra "production" my.cnf au lieu de sa version "bootstrap". Les deux nœuds restants auront PXC installé et ils obtiendront SST du premier nœud du cluster.

Résumé

Comme vous pouvez le voir, vous pouvez facilement créer un playbook Ansible simple et réutilisable qui peut être utilisé pour déployer le cluster Percona XtraDB et le configurer pour qu'il devienne un esclave du nœud MySQL autonome. Pour être honnête, pour migrer un seul serveur, cela n'aura probablement aucun intérêt car faire la même chose manuellement sera plus rapide. Néanmoins, si vous vous attendez à devoir réexécuter ce processus plusieurs fois, il sera certainement judicieux de l'automatiser et de le rendre plus efficace. Comme nous l'avons indiqué au début, il ne s'agit en aucun cas d'un playbook prêt pour la production. Il s'agit plutôt d'une preuve de concept, quelque chose que vous pouvez étendre pour l'adapter à votre environnement. Vous pouvez trouver des archives avec le playbook ici :http://severalnines.com/sites/default/files/ansible.tar.gz

Nous espérons que vous avez trouvé cet article de blog intéressant et précieux, n'hésitez pas à partager vos réflexions.