Jak zautomatyzować migrację z samodzielnego MySQL do klastra Galera za pomocą Ansible

Migracje baz danych nie skalują się dobrze. Zazwyczaj musisz wykonać wiele testów, zanim będziesz mógł pociągnąć za spust i przełączyć się ze starego na nowy. Migracje są zwykle wykonywane ręcznie, ponieważ większość procesu nie nadaje się do automatyzacji. Nie oznacza to jednak, że w procesie migracji nie ma miejsca na automatyzację. Wyobraź sobie konfigurowanie wielu węzłów z nowym oprogramowaniem, dostarczanie im danych i ręczne konfigurowanie replikacji między starym i nowym środowiskiem. Zajmuje to kilka dni. Automatyzacja może być bardzo przydatna podczas konfigurowania nowego środowiska i udostępniania mu danych. W tym poście na blogu przyjrzymy się bardzo prostej migracji — z samodzielnego serwera Percona Server 5.7 do 3-węzłowego klastra Percona XtraDB Cluster 5.7. W tym celu użyjemy Ansible.

Opis środowiska

Przede wszystkim jedno ważne zastrzeżenie - to, co tutaj pokażemy, to tylko szkic tego, co możesz chcieć uruchomić w produkcji. Działa w naszym środowisku testowym, ale może wymagać modyfikacji, aby było odpowiednie dla Twojego środowiska. W naszych testach użyliśmy czterech maszyn wirtualnych Ubuntu 16.04 wdrożonych przy użyciu Vagranta. Jeden zawiera samodzielny serwer Percona Server 5.7, pozostałe trzy będą używane dla węzłów klastra Percona XtraDB. Używamy również oddzielnego węzła do uruchamiania playbooków ansible, chociaż nie jest to wymagane, a playbook można również uruchomić z jednego z węzłów. Ponadto łączność SSH jest dostępna między wszystkimi węzłami. Musisz mieć łączność z hosta, na którym uruchamiasz ansible, ale możliwość ssh między węzłami jest przydatna (zwłaszcza między urządzeniem głównym a nowym urządzeniem podrzędnym - polegamy na tym w podręczniku).

Struktura poradnika

Playbooki Ansible zazwyczaj mają wspólną strukturę – tworzysz role, które można przypisać do różnych hostów. Każda rola będzie zawierała zadania do wykonania, szablony, które zostaną użyte, pliki, które zostaną przesłane, zmienne, które są zdefiniowane dla tego konkretnego poradnika. W naszym przypadku poradnik jest bardzo prosty.

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

Zdefiniowaliśmy kilka ról - mamy rolę główną, która ma na celu sprawdzenie poprawności w samodzielnym węźle. Istnieje węzeł podrzędny, który zostanie wykonany na jednym z węzłów Galera, aby skonfigurować go do replikacji i skonfigurować replikację asynchroniczną. Następnie mamy rolę dla wszystkich węzłów Galera i rolę dla pierwszego węzła Galera, który załaduje z niego klaster. W przypadku ról Galera mamy kilka szablonów, których użyjemy do tworzenia plików my.cnf. Użyjemy również lokalnego .my.cnf do zdefiniowania nazwy użytkownika i hasła. Mamy plik zawierający kilka zmiennych, które możemy chcieć dostosować, podobnie jak hasła. Wreszcie mamy plik inwentarzowy, który definiuje hosty, na których będziemy uruchamiać playbook, mamy też plik playbook z informacją, jak dokładnie mają być wykonywane. Przyjrzyjmy się poszczególnym bitom.

Plik zasobów

To bardzo prosty plik.

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

Mamy trzy grupy, „galera”, która zawiera wszystkie węzły Galera, „first_node”, której użyjemy do ładowania początkowego i wreszcie „master”, która zawiera nasz samodzielny węzeł serwera Percona.

Poradnik.yml

Plik playbook.yml zawiera ogólne wytyczne dotyczące wykonywania podręcznika.

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

Jak widać, zaczynamy od samodzielnego węzła i stosujemy zadania związane z rolą „master” (omówimy to szczegółowo w dalszej części tego postu).

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

Po drugie, przechodzimy do węzła zdefiniowanego w grupie „first_node” i stosujemy dwie role:„first_node” i „slave”. Pierwszy z nich ma na celu wdrożenie jednowęzłowego klastra PXC, drugi skonfiguruje go do pracy jako slave i skonfiguruje replikację.

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

Na koniec przechodzimy przez wszystkie węzły Galera i stosujemy na nich rolę „galera”.

Manynines DevOps Przewodnik po zarządzaniu bazami danychDowiedz się, co musisz wiedzieć, aby zautomatyzować i zarządzać bazami danych typu open sourcePobierz za darmo

Zmienne

Zanim zaczniemy przyglądać się rolom, chcemy wspomnieć o domyślnych zmiennych, które zdefiniowaliśmy dla tego poradnika.

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

Jak już wspomnieliśmy, jest to bardzo prosty podręcznik bez wielu opcji dostosowywania. Możesz skonfigurować użytkowników i hasła i to w zasadzie to. Jedna uwaga - upewnij się, że hasło roota węzła autonomicznego pasuje tutaj do „root_password”, w przeciwnym razie playbook nie będzie mógł się tam połączyć (można go rozszerzyć, aby sobie z tym poradzić, ale tego nie omówiliśmy).

Ten plik nie ma dużej wartości, ale z reguły chcesz zaszyfrować każdy plik, który zawiera poświadczenia. Oczywiście dzieje się tak ze względów bezpieczeństwa. Ansible jest dostarczany z ansible-vault, którego można używać do szyfrowania i odszyfrowywania plików. Nie będziemy tutaj omawiać szczegółów, wszystko, co musisz wiedzieć, jest dostępne w dokumentacji. Krótko mówiąc, możesz łatwo zaszyfrować pliki za pomocą haseł i skonfigurować środowisko tak, aby podręczniki mogły być odszyfrowywane automatycznie za pomocą hasła z pliku lub przekazywane ręcznie.

Role

W tej sekcji omówimy role zdefiniowane w podręczniku, podsumowując ich przeznaczenie.

Rola mistrza

Jak już wspomnieliśmy, ta rola ma na celu sprawdzenie poprawności konfiguracji samodzielnego MySQL. Zainstaluje wymagane pakiety, takie jak percona-xtrabackup-24. Tworzy również użytkownika replikacji w węźle głównym. Konfiguracja jest sprawdzana w celu upewnienia się, że skonfigurowano server_id oraz inne ustawienia replikacji i dziennika binarnego. GTID jest również włączony, ponieważ będziemy na nim polegać podczas replikacji.

Rola pierwszego_węzła

Tutaj zainstalowany jest pierwszy węzeł Galera. Repozytorium Percona zostanie skonfigurowane, my.cnf zostanie utworzony z szablonu. PXC zostanie zainstalowany. Przeprowadzamy również czyszczenie, aby usunąć niepotrzebnych użytkowników i utworzyć tych, którzy będą potrzebni (użytkownik root z wybranym przez nas hasłem, użytkownik wymagany do SST). Na koniec klaster jest ładowany przy użyciu tego węzła. Polegamy na pustym „wsrep_cluster_address” jako sposobie zainicjowania klastra. Dlatego później nadal wykonujemy rolę „galera” na pierwszym węźle – aby zamienić początkowy my.cnf na końcowy, zawierający „wsrep_cluster_address” ze wszystkimi członkami klastra. Jedna rzecz warta zapamiętania - kiedy tworzysz użytkownika root z hasłem, musisz uważać, aby nie zablokować MySQL, aby Ansible mógł wykonać inne kroki podręcznika. Jednym ze sposobów, aby to zrobić, jest podanie .my.cnf poprawnego użytkownika i hasła. Innym byłoby pamiętanie, aby zawsze ustawiać poprawne login_user i login_password w module „mysql_user”.

Rola niewolnika

Ta rola polega na skonfigurowaniu replikacji między węzłem autonomicznym a jednowęzłowym klastrem PXC. Używamy xtrabackup do pobierania danych, sprawdzamy również wykonane gtid w xtrabackup_binlog_info, aby upewnić się, że kopia zapasowa zostanie przywrócona poprawnie i że można skonfigurować replikację. Wykonujemy również trochę konfiguracji, upewniając się, że węzeł podrzędny może korzystać z replikacji GTID. Jest tu kilka problemów - nie można uruchomić „RESET MASTER” za pomocą modułu „mysql_replication” od Ansible 2.7.10, powinno być to możliwe w 2.8, kiedy tylko się pojawi. Musieliśmy użyć modułu „shell”, aby uruchomić polecenia MySQL CLI. Przebudowując węzeł Galera ze źródła zewnętrznego, należy pamiętać o ponownym utworzeniu wszystkich wymaganych użytkowników (przynajmniej użytkownika używanego do SST). W przeciwnym razie pozostałe węzły nie będą mogły dołączyć do klastra.

Rola Galery

Wreszcie jest to rola, w której instalujemy PXC na pozostałych dwóch węzłach. Uruchamiamy go na wszystkich nodach, początkowy dostanie „production” my.cnf zamiast wersji „bootstrap”. Pozostałe dwa węzły będą miały zainstalowane PXC i uzyskają SST z pierwszego węzła w klastrze.

Podsumowanie

Jak widać, można łatwo stworzyć prosty podręcznik Ansible wielokrotnego użytku, którego można użyć do wdrożenia klastra Percona XtraDB i skonfigurowania go jako podrzędnego samodzielnego węzła MySQL. Szczerze mówiąc, w przypadku migracji pojedynczego serwera prawdopodobnie nie będzie to miało sensu, ponieważ ręczne wykonanie tego samego będzie szybsze. Mimo to, jeśli spodziewasz się, że będziesz musiał powtórzyć ten proces kilka razy, z pewnością będzie sensowne zautomatyzowanie go i zwiększenie wydajności czasowej. Jak wspomnieliśmy na początku, nie jest to w żadnym wypadku podręcznik gotowy do produkcji. Jest to bardziej weryfikacja koncepcji, coś, co możesz rozszerzyć, aby dostosować ją do swojego środowiska. Archiwum z poradnikiem znajdziesz tutaj:http://severalnines.com/sites/default/files/ansible.tar.gz

Mamy nadzieję, że ten post na blogu okazał się interesujący i wartościowy. Nie wahaj się podzielić swoimi przemyśleniami.