Migrace databází se špatně škálují. Než budete moci stisknout spoušť a přejít ze starého na nový, musíte obvykle provést velké množství testů. Migrace se obvykle provádějí ručně, protože většina procesu není vhodná pro automatizaci. To však neznamená, že v procesu migrace není prostor pro automatizaci. Představte si, že nastavujete řadu uzlů s novým softwarem, poskytujete jim data a ručně konfigurujete replikaci mezi starým a novým prostředím. To trvá dny. Automatizace může být velmi užitečná při nastavování nového prostředí a poskytování dat. V tomto příspěvku na blogu se podíváme na velmi jednoduchou migraci – ze samostatného serveru Percona Server 5.7 na 3uzlový Percona XtraDB Cluster 5.7. K tomu použijeme Ansible.
Popis prostředí
Nejprve jedno důležité upozornění – to, co zde ukážeme, je pouze návrh toho, co byste mohli chtít spustit ve výrobě. Funguje v našem testovacím prostředí, ale může vyžadovat úpravy, aby bylo vhodné pro vaše prostředí. V našich testech jsme použili čtyři virtuální počítače Ubuntu 16.04 nasazené pomocí Vagrant. Jeden obsahuje samostatný Percona Server 5.7, zbývající tři budou použity pro uzly Percona XtraDB Cluster. Používáme také samostatný uzel pro spouštění ansible playbooků, i když to není podmínkou a playbook lze také spustit z jednoho z uzlů. Kromě toho je mezi všemi uzly k dispozici připojení SSH. Musíte mít konektivitu z hostitele, na kterém běžíte ansible, ale schopnost ssh mezi uzly je užitečná (zejména mezi master a new slave – na to spoléháme v playbooku).
Struktura příručky
Ansible playbooky obvykle sdílejí společnou strukturu – vytváříte role, které lze přiřadit různým hostitelům. Každá role bude obsahovat úkoly, které se na ní mají provést, šablony, které budou použity, soubory, které budou nahrány, proměnné, které jsou definovány pro tento konkrétní playbook. V našem případě je příručka velmi jednoduchá.
.
├── 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
Definovali jsme několik rolí – máme hlavní roli, která je určena k provádění některých kontrol zdravého rozumu na samostatném uzlu. Existuje podřízený uzel, který bude spuštěn na jednom z uzlů Galera, aby jej nakonfiguroval pro replikaci a nastavil asynchronní replikaci. Pak máme roli pro všechny uzly Galery a roli pro první uzel Galery, který z něj zavede cluster. Pro role Galera máme několik šablon, které použijeme k vytvoření souborů my.cnf. K definování uživatelského jména a hesla také použijeme local .my.cnf. Máme soubor obsahující několik proměnných, které můžeme chtít upravit, stejně jako hesla. Nakonec máme soubor inventáře, který definuje hostitele, na kterých budeme playbook spouštět, máme také soubor playbook s informacemi o tom, jak přesně by se věci měly spouštět. Pojďme se podívat na jednotlivé bity.
Soubor inventáře
Toto je velmi jednoduchý soubor.
[galera]
10.0.0.142
10.0.0.143
10.0.0.144
[first_node]
10.0.0.142
[master]
10.0.0.141
Máme tři skupiny, ‚galera‘, která obsahuje všechny uzly Galera, ‚first_node‘, kterou použijeme pro bootstrap, a nakonec ‚master‘, která obsahuje náš samostatný uzel Percona Server.
Playbook.yml
Soubor playbook.yml obsahuje obecné pokyny, jak by měl být playbook spuštěn.
- 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 můžete vidět, začínáme se samostatným uzlem a aplikujeme úkoly související s rolí „master“ (podrobně o tom pojednáme dále v tomto příspěvku).
- 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 }
Za druhé, přejdeme do uzlu definovaného ve skupině „first_node“ a použijeme dvě role:„first_node“ a „slave“. První jmenovaný je určen k nasazení jednoho uzlu PXC clusteru, druhý jej nakonfiguruje tak, aby fungoval jako slave, a nastaví replikaci.
- 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 }
Nakonec projdeme všechny uzly Galera a na všechny aplikujeme roli „galera“.
Několik nines DevOps Průvodce správou databázíZjistěte, co potřebujete vědět k automatizaci a správě vašich databází s otevřeným zdrojovým kódemStáhněte si zdarmaProměnné
Než se začneme zabývat rolemi, chceme zmínit výchozí proměnné, které jsme definovali pro tuto příručku.
sst_user: "sstuser"
sst_password: "pa55w0rd"
root_password: "pass"
repl_user: "repl_user"
repl_password: "repl1cati0n"
Jak jsme uvedli, jedná se o velmi jednoduchý playbook bez větších možností přizpůsobení. Můžete nakonfigurovat uživatele a hesla a to je v podstatě vše. Jedna chyba – ujistěte se, že kořenové heslo samostatného uzlu odpovídá heslu root_password, protože jinak by se tam playbook nemohl připojit (lze jej rozšířit, aby to zvládl, ale tím jsme se nezabývali).
Tento soubor nemá příliš velkou hodnotu, ale zpravidla chcete zašifrovat jakýkoli soubor, který obsahuje přihlašovací údaje. Je zřejmé, že je to z bezpečnostních důvodů. Ansible přichází s ansible-vault, který lze použít k šifrování a dešifrování souborů. Nebudeme se zde zabývat podrobnostmi, vše, co potřebujete vědět, je k dispozici v dokumentaci. Stručně řečeno, můžete snadno šifrovat soubory pomocí hesel a nakonfigurovat své prostředí tak, aby bylo možné playbooky automaticky dešifrovat pomocí hesla ze souboru nebo předat ručně.
Role
V této části projdeme role, které jsou definovány v příručce, a shrneme, co mají plnit.
Hlavní role
Jak jsme uvedli, tato role je určena ke spuštění kontroly zdravého rozumu konfigurace samostatného MySQL. Nainstaluje požadované balíčky jako percona-xtrabackup-24. Také vytvoří uživatele replikace na hlavním uzlu. Konfigurace je zkontrolována, aby bylo zajištěno, že je nastaveno server_id a další nastavení související s replikací a binárním protokolem. GTID je také povoleno, protože na něj budeme při replikaci spoléhat.
Role prvního_uzlu
Zde je nainstalován první uzel Galera. Nakonfiguruje se úložiště Percona, ze šablony se vytvoří my.cnf. PXC bude nainstalováno. Provádíme také čištění, abychom odstranili nepotřebné uživatele a vytvořili ty, kteří budou vyžadováni (uživatel root s heslem dle našeho výběru, uživatel vyžadovaný pro SST). Nakonec se cluster zavede pomocí tohoto uzlu. Spoléháme se na prázdný „wsrep_cluster_address“ jako způsob inicializace clusteru. To je důvod, proč později stále provádíme roli ‚galera‘ na prvním uzlu – pro výměnu počátečního souboru my.cnf za konečný, který obsahuje ‚wsrep_cluster_address‘ se všemi členy clusteru. Jedna věc, kterou stojí za to zapamatovat - když vytváříte root uživatele s heslem, musíte být opatrní, abyste nebyli uzamčeni MySQL, aby Ansible mohl provádět další kroky playbooku. Jedním ze způsobů, jak toho dosáhnout, je poskytnout souboru .my.cnf správného uživatele a heslo. Dalším by bylo pamatovat na to, abyste vždy nastavili správné login_user a login_password v modulu ‚mysql_user‘.
Role otroka
Tato role je o konfiguraci replikace mezi samostatným uzlem a clusterem PXC s jedním uzlem. K získání dat používáme xtrabackup, také kontrolujeme, zda je v xtrabackup_binlog_info proveden gtid, abychom zajistili, že záloha bude správně obnovena a že replikaci lze nakonfigurovat. Provádíme také část konfigurace, abychom se ujistili, že podřízený uzel může používat replikaci GTID. Je zde několik problémů - od Ansible 2.7.10 není možné spustit ‚RESET MASTER‘ pomocí modulu ‚mysql_replication‘, mělo by to být možné provést ve verzi 2.8, kdykoli to vyjde. Ke spuštění příkazů MySQL CLI jsme museli použít modul „shell“. Při přestavbě uzlu Galera z externího zdroje si musíte pamatovat na opětovné vytvoření všech požadovaných uživatelů (alespoň uživatele používaného pro SST). Jinak se zbývající uzly nebudou moci připojit ke clusteru.
Role Galera
Konečně, toto je role, ve které nainstalujeme PXC na zbývající dva uzly. Spustíme to na všech uzlech, ten počáteční dostane „produkční“ my.cnf místo své „bootstrap“ verze. Zbývající dva uzly budou mít nainstalované PXC a získají SST z prvního uzlu v clusteru.
Shrnutí
Jak vidíte, můžete snadno vytvořit jednoduchou, opakovaně použitelnou příručku Ansible, kterou lze použít pro nasazení Percona XtraDB Cluster a jeho konfiguraci jako otroka samostatného MySQL uzlu. Abych byl upřímný, pro migraci jednoho serveru to pravděpodobně nebude mít smysl, protože dělat totéž ručně bude rychlejší. Přesto, pokud očekáváte, že budete muset tento proces několikrát opakovat, rozhodně bude mít smysl jej zautomatizovat a zefektivnit jej z hlediska času. Jak jsme uvedli na začátku, nejedná se v žádném případě o produkční příručku. Je to spíše důkaz konceptu, něco, co můžete rozšířit, aby to bylo vhodné pro vaše prostředí. Archiv s playbookem najdete zde:http://severalnines.com/sites/default/files/ansible.tar.gz
Doufáme, že pro vás byl tento blogový příspěvek zajímavý a hodnotný. Neváhejte se podělit o své myšlenky.