Mysql
 sql >> Datenbank >  >> RDS >> Mysql

So automatisieren Sie die Migration von eigenständigem MySQL zu Galera-Cluster mit Ansible

Datenbankmigrationen lassen sich nicht gut skalieren. Normalerweise müssen Sie viele Tests durchführen, bevor Sie den Abzug betätigen und von alt auf neu umschalten können. Migrationen werden normalerweise manuell durchgeführt, da sich die meisten Prozesse nicht für eine Automatisierung eignen. Das bedeutet jedoch nicht, dass der Migrationsprozess nicht automatisiert werden kann. Stellen Sie sich vor, Sie richten eine Reihe von Knoten mit neuer Software ein, versorgen sie mit Daten und konfigurieren die Replikation zwischen alten und neuen Umgebungen von Hand. Das dauert Tage. Automatisierung kann sehr nützlich sein, wenn eine neue Umgebung eingerichtet und mit Daten versorgt wird. In diesem Blogbeitrag werfen wir einen Blick auf eine sehr einfache Migration – von einem eigenständigen Percona Server 5.7 zu einem 3-Knoten Percona XtraDB Cluster 5.7. Wir werden Ansible verwenden, um dies zu erreichen.

Umgebungsbeschreibung

Zuallererst ein wichtiger Haftungsausschluss:Was wir hier zeigen werden, ist nur ein Entwurf dessen, was Sie gerne in der Produktion ausführen würden. Es funktioniert in unserer Testumgebung, aber möglicherweise müssen Änderungen vorgenommen werden, damit es für Ihre Umgebung geeignet ist. In unseren Tests haben wir vier Ubuntu 16.04-VMs verwendet, die mit Vagrant bereitgestellt wurden. Einer enthält eigenständigen Percona Server 5.7, die restlichen drei werden für Percona XtraDB Cluster-Knoten verwendet. Wir verwenden auch einen separaten Knoten zum Ausführen von ansiblen Playbooks, obwohl dies keine Voraussetzung ist und das Playbook auch von einem der Knoten ausgeführt werden kann. Darüber hinaus ist SSH-Konnektivität zwischen allen Knoten verfügbar. Sie müssen eine Konnektivität von dem Host haben, auf dem Sie Ansible ausführen, aber die Möglichkeit, zwischen Knoten zu sshen, ist nützlich (insbesondere zwischen Master und neuem Slave - darauf verlassen wir uns im Playbook).

Playbook-Struktur

Ansible-Playbooks haben normalerweise eine gemeinsame Struktur – Sie erstellen Rollen, die verschiedenen Hosts zugewiesen werden können. Jede Rolle enthält Aufgaben, die darauf ausgeführt werden, Vorlagen, die verwendet werden, Dateien, die hochgeladen werden, Variablen, die für dieses bestimmte Playbook definiert werden. In unserem Fall ist das Playbook sehr einfach.

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

Wir haben ein paar Rollen definiert – wir haben eine Master-Rolle, die dazu dient, einige Plausibilitätsprüfungen auf dem eigenständigen Knoten durchzuführen. Es gibt einen Slave-Knoten, der auf einem der Galera-Knoten ausgeführt wird, um ihn für die Replikation zu konfigurieren und die asynchrone Replikation einzurichten. Dann haben wir eine Rolle für alle Galera-Knoten und eine Rolle für den ersten Galera-Knoten, der den Cluster daraus bootet. Für Galera-Rollen haben wir einige Vorlagen, die wir verwenden werden, um my.cnf-Dateien zu erstellen. Wir werden auch die lokale .my.cnf verwenden, um einen Benutzernamen und ein Passwort zu definieren. Wir haben eine Datei mit einigen Variablen, die wir vielleicht anpassen möchten, genau wie Passwörter. Schließlich haben wir eine Inventardatei, die Hosts definiert, auf denen wir das Playbook ausführen werden, wir haben auch die Playbook-Datei mit Informationen darüber, wie genau die Dinge ausgeführt werden sollen. Schauen wir uns die einzelnen Bits an.

Inventardatei

Dies ist eine sehr einfache Datei.

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

Wir haben drei Gruppen, „galera“, die alle Galera-Knoten enthält, „first_node“, die wir für den Bootstrap verwenden werden, und schließlich „master“, die unseren eigenständigen Percona-Server-Knoten enthält.

Playbook.yml

Die Datei playbook.yml enthält die allgemeinen Richtlinien, wie das Playbook ausgeführt werden soll.

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

Wie Sie sehen können, beginnen wir mit dem eigenständigen Knoten und wenden Aufgaben an, die sich auf die Rolle „Master“ beziehen (wir werden dies weiter unten in diesem Beitrag ausführlich besprechen).

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

Zweitens gehen wir zu dem Knoten, der in der Gruppe „first_node“ definiert ist, und wenden zwei Rollen an:„first_node“ und „slave“. Ersteres soll einen PXC-Cluster mit einem einzelnen Knoten bereitstellen, letzteres wird es so konfigurieren, dass es als Slave funktioniert, und die Replikation einrichten.

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

Schließlich gehen wir alle Galera-Knoten durch und wenden die Rolle „galera“ auf alle an.

Multiplenines DevOps-Leitfaden zur DatenbankverwaltungErfahren Sie, was Sie wissen müssen, um Ihre Open-Source-Datenbanken zu automatisieren und zu verwalten.Kostenlos herunterladen

Variablen

Bevor wir uns mit den Rollen befassen, möchten wir die Standardvariablen erwähnen, die wir für dieses Playbook definiert haben.

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

Wie bereits erwähnt, ist dies ein sehr einfaches Spielbuch ohne viele Anpassungsmöglichkeiten. Sie können Benutzer und Passwörter konfigurieren und das war es im Grunde. Ein Fallstrick – bitte stellen Sie sicher, dass das Root-Passwort des Standalone-Knotens hier mit „root_password“ übereinstimmt, da sich das Playbook sonst dort nicht verbinden könnte (es kann erweitert werden, um damit umzugehen, aber wir haben das nicht behandelt).

Diese Datei hat keinen großen Wert, aber als Faustregel sollten Sie jede Datei verschlüsseln, die Anmeldeinformationen enthält. Offensichtlich ist dies aus Sicherheitsgründen. Ansible wird mit Ansible-Vault geliefert, das zum Verschlüsseln und Entschlüsseln von Dateien verwendet werden kann. Wir werden hier nicht auf Details eingehen, alles, was Sie wissen müssen, ist in der Dokumentation verfügbar. Kurz gesagt, Sie können Dateien einfach mit Passwörtern verschlüsseln und Ihre Umgebung so konfigurieren, dass die Playbooks automatisch mit Passwörtern aus der Datei entschlüsselt oder von Hand übergeben werden können.

Rollen

In diesem Abschnitt gehen wir auf Rollen ein, die im Playbook definiert sind, und fassen zusammen, was sie ausführen sollen.

Meisterrolle

Wie bereits erwähnt, soll diese Rolle eine Plausibilitätsprüfung der Konfiguration des eigenständigen MySQL durchführen. Es installiert erforderliche Pakete wie percona-xtrabackup-24. Es erstellt auch einen Replikationsbenutzer auf dem Master-Knoten. Eine Konfiguration wird überprüft, um sicherzustellen, dass server_id und andere replikations- und binärprotokollbezogene Einstellungen festgelegt sind. GTID ist ebenfalls aktiviert, da wir uns für die Replikation darauf verlassen werden.

First_node-Rolle

Hier wird der erste Galera-Knoten installiert. Das Percona-Repository wird konfiguriert, my.cnf wird aus der Vorlage erstellt. PXC wird installiert. Wir führen auch einige Aufräumarbeiten durch, um unnötige Benutzer zu entfernen und diejenigen zu erstellen, die benötigt werden (Root-Benutzer mit dem Passwort unserer Wahl, Benutzer, der für SST erforderlich ist). Schließlich wird der Cluster unter Verwendung dieses Knotens gebootstrapped. Wir verlassen uns auf die leere „wsrep_cluster_address“, um den Cluster zu initialisieren. Aus diesem Grund führen wir später immer noch die Rolle „galera“ auf dem ersten Knoten aus, um die anfängliche my.cnf mit der letzten zu tauschen, die „wsrep_cluster_address“ mit allen Mitgliedern des Clusters enthält. Eine Sache, an die Sie sich erinnern sollten:Wenn Sie einen Root-Benutzer mit Passwort erstellen, müssen Sie darauf achten, dass MySQL nicht gesperrt wird, damit Ansible andere Schritte des Playbooks ausführen kann. Eine Möglichkeit, dies zu tun, besteht darin, .my.cnf mit dem richtigen Benutzer und Passwort zu versehen. Eine andere wäre, daran zu denken, immer den richtigen login_user und login_password im ‚mysql_user‘-Modul festzulegen.

Sklavenrolle

Bei dieser Rolle dreht sich alles um die Konfiguration der Replikation zwischen dem eigenständigen Knoten und dem Einzelknoten-PXC-Cluster. Wir verwenden xtrabackup, um die Daten abzurufen, wir prüfen auch auf ausgeführte gtid in xtrabackup_binlog_info, um sicherzustellen, dass die Sicherung ordnungsgemäß wiederhergestellt wird und dass die Replikation konfiguriert werden kann. Wir führen auch einen Teil der Konfiguration durch und stellen sicher, dass der Slave-Knoten die GTID-Replikation verwenden kann. Hier gibt es ein paar Fallstricke - es ist nicht möglich, 'RESET MASTER' mit dem 'mysql_replication'-Modul ab Ansible 2.7.10 auszuführen, es sollte möglich sein, dies in 2.8 zu tun, wann immer es herauskommt. Wir mussten das Modul „shell“ verwenden, um MySQL-CLI-Befehle auszuführen. Wenn Sie den Galera-Knoten aus einer externen Quelle neu erstellen, müssen Sie daran denken, alle erforderlichen Benutzer neu zu erstellen (zumindest Benutzer, die für SST verwendet werden). Andernfalls können die verbleibenden Knoten dem Cluster nicht beitreten.

Galera-Rolle

Schließlich ist dies die Rolle, in der wir PXC auf den verbleibenden zwei Knoten installieren. Wir führen es auf allen Knoten aus, der erste erhält „Produktion“ my.cnf anstelle seiner „Bootstrap“-Version. Auf den verbleibenden zwei Knoten wird PXC installiert und sie erhalten SST vom ersten Knoten im Cluster.

Zusammenfassung

Wie Sie sehen, können Sie ganz einfach ein einfaches, wiederverwendbares Ansible-Playbook erstellen, das zum Bereitstellen des Percona XtraDB-Clusters und zum Konfigurieren als Slave eines eigenständigen MySQL-Knotens verwendet werden kann. Um ehrlich zu sein, wird dies für die Migration eines einzelnen Servers wahrscheinlich keinen Sinn haben, da es schneller geht, dasselbe manuell zu tun. Wenn Sie jedoch davon ausgehen, dass Sie diesen Vorgang einige Male erneut ausführen müssen, ist es auf jeden Fall sinnvoll, ihn zu automatisieren und zeiteffizienter zu gestalten. Wie eingangs erwähnt, ist dies keineswegs ein produktionsreifes Playbook. Es ist eher ein Proof of Concept, etwas, das Sie erweitern können, um es für Ihre Umgebung geeignet zu machen. Das Archiv mit dem Playbook finden Sie hier:http://severalnines.com/sites/default/files/ansible.tar.gz

Wir hoffen, Sie fanden diesen Blogbeitrag interessant und wertvoll. Zögern Sie nicht, uns Ihre Gedanken mitzuteilen.