Der er flere måder at implementere en database på. Du kan installere det i hånden, du kan stole på de bredt tilgængelige infrastruktur-orkestreringsværktøjer som Ansible, Chef, Puppet eller Salt. Disse værktøjer er meget populære, og det er ret nemt at finde scripts, opskrifter, spillebøger, you name it, som vil hjælpe dig med at automatisere installationen af en databaseklynge. Der er også mere specialiserede databaseautomatiseringsplatforme, såsom ClusterControl, som også kan bruges til automatiseret implementering. Hvad ville være den bedste måde at implementere din klynge på? Hvor meget tid skal du egentlig bruge til at implementere det?
Lad os først afklare, hvad vi vil gøre. Lad os antage, at vi vil implementere Percona XtraDB Cluster 5.7. Den vil bestå af tre noder, og til det vil vi bruge tre virtuelle Vagrant-maskiner, der kører Ubuntu 16.04 (bento/ubuntu-16.04-billede). Vi vil forsøge at implementere en klynge manuelt og derefter bruge Ansible og ClusterControl. Lad os se, hvordan resultaterne vil se ud.
Manuel implementering
Opsætning af lager - 1 minut, 45 sekunder.
Først og fremmest skal vi konfigurere Percona repositories på alle Ubuntu-noder. Hurtig google-søgning, ssh ind i de virtuelle maskiner og kørsel af nødvendige kommandoer tager 1m45s
Vi fandt følgende side med instruktioner:
https://www.percona.com/doc/percona-repo-config/percona-release.html
og vi udførte trin beskrevet i afsnittet "DEB-BASEREDE GNU/LINUX DISTRIBUTIONER". Vi kørte også en passende opdatering for at opdatere apts cache.
Installation af PXC Nodes - 2 minutter 45 sekunder
Dette trin består grundlæggende af at udføre:
[email protected]:~# apt install percona-xtradb-cluster-5.7Resten er for det meste afhængig af din internetforbindelses hastighed, da pakker bliver downloadet. Dit input vil også være nødvendigt (du sender en adgangskode til superbrugeren), så det er ikke uovervåget installation. Når alt er færdigt, vil du ende med tre kørende Percona XtraDB Cluster noder:
root 15488 0.0 0.2 4504 1788 ? S 10:12 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 15847 0.3 28.3 1339576 215084 ? Sl 10:12 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1Konfiguration af PXC-noder - 3 minutter, 25 sekunder
Her starter den vanskelige del. Det er virkelig svært at kvantificere erfaring, og hvor meget tid man skal bruge til rent faktisk at forstå, hvad der skal til. Hvad der er godt, google-søgning “how to install percona xtrabdb cluster” peger på Perconas dokumentation, som beskriver hvordan processen skal se ud. Det kan stadig tage mere eller mindre tid, afhængigt af hvor fortrolig du er med PXC og Galera generelt. I værste fald vil du ikke være opmærksom på yderligere nødvendige handlinger, og du vil oprette forbindelse til din PXC og begynde at arbejde med den uden at indse, at du faktisk har tre noder, der hver danner en klynge for sig.
Lad os antage, at vi følger anbefalingen fra Percona, og at vi bare tager de trin, der skal udføres. Kort sagt, vi ændrede konfigurationsfiler i henhold til instruktionerne på Perconas websted, vi forsøgte også at bootstrap den første node:
[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
* Bootstrapping Percona XtraDB Cluster database server mysqld ^CDette så ikke rigtigt ud. Desværre var instruktionerne ikke krystalklare. Igen, hvis du ikke ved, hvad der foregår, vil du bruge mere tid på at prøve at forstå, hvad der skete. Heldigvis er stackoverflow.com meget nyttigt (selvom ikke det første svar på listen, vi fik), og du burde indse, at du savner [mysqld] sektionsoverskrift i din /etc/mysql/my.cnf fil. Tilføjelse af dette på alle noder og gentagelse af bootstrap-processen løste problemet. I alt brugte vi 3 minutter og 25 sekunder (ikke inklusive google efter fejlen, da vi straks bemærkede, hvad der var problemet).
Konfiguration til SST, bringer andre noder ind i klyngen - startende fra 8 minutter til uendeligt
Instruktionerne på Perconas hjemmeside er ret klare. Når du har en node oppe at køre, skal du bare starte med de resterende noder, og du vil være i orden. Vi prøvede det, og vi kunne ikke se flere noder slutte sig til klyngen. Det er her, det er praktisk talt umuligt at sige, hvor lang tid det vil tage at diagnosticere problemet. Det tog os 6-7 minutter, men for at kunne gøre det hurtigt skal du:
- Vær bekendt med, hvordan PXC-konfiguration er struktureret:
[email protected]:~# tree /etc/mysql/ /etc/mysql/ ├── conf.d │ ├── mysql.cnf │ └── mysqldump.cnf ├── my.cnf -> /etc/alternatives/my.cnf ├── my.cnf.fallback ├── my.cnf.old ├── percona-xtradb-cluster.cnf └── percona-xtradb-cluster.conf.d ├── client.cnf ├── mysqld.cnf ├── mysqld_safe.cnf └── wsrep.cnf - Vid, hvordan !include- og !includedir-direktiverne fungerer i MySQL-konfigurationsfiler
- Vid, hvordan MySQL håndterer de samme variabler inkluderet i flere filer
- Vid, hvad du skal kigge efter, og vær opmærksom på konfigurationer, der ville resultere i, at noden bootstrapper sig selv for at danne en klynge alene
Problemet var relateret til det faktum, at instruktionerne ikke nævnte nogen fil undtagen /etc/mysql/my.cnf, hvor vi faktisk burde have ændret /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf. Denne fil indeholdt tom variabel:
wsrep_cluster_address=gcomm://og en sådan konfiguration tvinger node til at bootstrap, da den ikke har information om andre noder at slutte sig til. Vi indstillede den variabel i /etc/mysql/my.cnf, men senere blev filen wsrep.cnf inkluderet, hvilket overskriver vores opsætning.
Dette problem kan være en alvorlig blokering for folk, der ikke rigtig er bekendt med, hvordan MySQL og Galera fungerer, hvilket resulterer i timer, hvis ikke mere, med fejlretning.
Samlet installationstid - 16 minutter (hvis du er MySQL DBA som jeg er)
Det lykkedes os at installere Percona XtraDB Cluster på 16 minutter. Du skal huske på et par ting - vi har ikke justeret konfigurationen. Det er noget, der vil kræve mere tid og viden. PXC-node kommer med en simpel konfiguration, der hovedsageligt er relateret til binær logning og Galera-skrivesætreplikering. Der er ingen InnoDB-tuning. Hvis du ikke er bekendt med MySQL internals, er dette timer, hvis ikke dage med at læse og sætte dig ind i interne mekanismer. En anden vigtig ting er, at dette er en proces, du skal genansøge for hver klynge, du implementerer. Endelig lykkedes det os at identificere problemet og løse det meget hurtigt på grund af vores erfaring med Percona XtraDB Cluster og MySQL generelt. Casual bruger vil højst sandsynligt bruge betydeligt mere tid på at prøve at forstå, hvad der foregår og hvorfor.
Ansible Playbook
Nu til automatisering med Ansible. Lad os prøve at finde og bruge en passende spillebog, som vi kunne genbruge til alle yderligere implementeringer. Lad os se, hvor lang tid det tager at gøre det.
Konfiguration af SSH-forbindelse - 1 minut
Ansible kræver SSH-forbindelse på tværs af alle noder for at forbinde og konfigurere dem. Vi genererede en SSH-nøgle og distribuerede den manuelt på tværs af noderne.
Find Ansible Playbook - 2 minutter og 15 sekunder
Hovedproblemet her er, at der er så mange spillebøger tilgængelige derude, at det er umuligt at afgøre, hvad der er bedst. Som sådan besluttede vi at gå med top 3 Google-resultater og prøve at vælge en. Vi besluttede os for https://github.com/cdelgehier/ansible-role-XtraDB-Cluster, da det ser ud til at være mere konfigurerbart end de resterende.
Kloning af lager og installation af Ansible - 30 sekunder
Det er hurtigt, alt hvad vi havde brug for var at
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitForberedelse af inventarfil - 1 minut og 10 sekunder
Dette trin var også meget enkelt, vi oprettede en inventarfil ved hjælp af eksempel fra dokumentation. Vi har lige erstattet IP-adresserne på noderne med det, vi har konfigureret i vores miljø.
Forberedelse af en Playbook - 1 minut og 45 sekunder
Vi besluttede at bruge det mest omfattende eksempel fra dokumentationen, som også inkluderer lidt af konfigurationsjusteringen. Vi udarbejdede en korrekt struktur for Ansible (der var ingen sådan information i dokumentationen):
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterSå kørte vi det, men straks fik vi en fejl:
[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
[WARNING]: provided hosts list is empty, only localhost is available
ERROR! no action detected in task
The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: "Include {{ ansible_distribution }} tasks"
^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:
with_items:
- {{ foo }}
Should be written as:
with_items:
- "{{ foo }}"Dette tog 1 minut og 45 sekunder.
Løsning af Playbook-syntaksproblemet - 3 minutter 25 sekunder
Fejlen var vildledende, men den generelle tommelfingerregel er at prøve en nyere Ansible-version, hvilket vi gjorde. Vi googlede og fandt gode instruktioner på Ansibles hjemmeside. Næste forsøg på at køre afspilningsbogen mislykkedes også:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}Det tog 3 minutter og 25 sekunder at konfigurere ny Ansible-version og køre playbook op til denne fejl.
Rettelse af det manglende Python-modul - 3 minutter og 20 sekunder
Den rolle, vi brugte, tog tilsyneladende ikke hånd om dens forudsætninger, og der manglede et Python-modul til at forbinde til og sikre Galera-klyngen. Vi forsøgte først at installere MySQL-python via pip, men det blev tydeligt, at det vil tage længere tid, da det krævede mysql_config:
[email protected]:~# pip install MySQL-python
Collecting MySQL-python
Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
100% |████████████████████████████████| 112kB 278kB/s
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
metadata, options = get_config()
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
libs = mysql_config("libs_r")
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
raise EnvironmentError("%s not found" % (mysql_config.path,))
EnvironmentError: mysql_config not found
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/Det leveres af MySQL-udviklingsbiblioteker, så vi bliver nødt til at installere dem manuelt, hvilket var stort set meningsløst. Vi besluttede at gå med PyMySQL, som ikke krævede andre pakker at installere. Dette bragte os til et andet problem:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryIndtil dette tidspunkt brugte vi 3 minutter og 20 sekunder.
Rettelse af "Adgang nægtet"-fejl - 18 minutter 55 sekunder
I henhold til fejlen sikrede vi, at MySQL-konfigurationen er forberedt korrekt, og at den inkluderede korrekt bruger og adgangskode til at oprette forbindelse til databasen. Dette fungerede desværre ikke som forventet. Vi undersøgte nærmere og fandt ud af, at rollen ikke oprettede root-bruger korrekt, selvom den markerede trinnet som afsluttet. Vi lavede en kort undersøgelse, men besluttede at lave den manuelle rettelse i stedet for at forsøge at fejlsøge playbook, hvilket ville tage meget længere tid end de trin, vi gjorde. Vi har netop oprettet manuelt brugere [email protected] og [email protected] med korrekte adgangskoder. Dette gjorde det muligt for os at videregive dette trin til en anden fejl:
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryTil dette afsnit brugte vi 18 minutter og 55 sekunder.
Løsning af "Start Slave Nodes"-problemet (del 1) - 7 minutter 40 sekunder
Vi prøvede et par ting for at løse dette problem. Vi forsøgte at specificere noden ved hjælp af dens navn, vi forsøgte at skifte gruppenavne, intet løste problemet. Vi besluttede at rydde op i miljøet ved hjælp af scriptet i dokumentationen og starte fra bunden. Det rensede det ikke, men gjorde bare tingene endnu værre. Efter 7 minutter og 40 sekunder besluttede vi at slette de virtuelle maskiner, genskabe miljøet og starte fra bunden i håb om, at når vi tilføjer Python-afhængighederne, vil dette løse vores problem.
Løsning af "Start Slave Nodes"-problemet (del 2) - 13 minutter 15 sekunder
Desværre hjalp det slet ikke at opsætte Python-forudsætninger. Vi besluttede at afslutte processen manuelt, bootstrapping af den første node og derefter konfigurere SST-bruger og starte resterende slaver. Dette fuldførte den "automatiserede" opsætning, og det tog os 13 minutter og 15 sekunder at fejlfinde og så endelig acceptere, at det ikke vil fungere, som playbook-designeren forventede.
Yderligere fejlretning - 10 minutter 45 sekunder
Vi stoppede ikke der og besluttede, at vi ville prøve en ting mere. I stedet for at stole på Ansible-variabler sætter vi bare IP'en for en af noderne som masterknudepunktet. Dette løste den del af problemet, og vi endte med:
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}Dette var slutningen på vores forsøg - vi forsøgte at tilføje denne bruger, men det fungerede ikke korrekt gennem den mulige afspilningsbog, mens vi kunne bruge IPv6 localhost-adressen til at oprette forbindelse til, når vi brugte MySQL-klient.
Samlet installationstid - Ukendt (automatisk installation mislykkedes)
I alt brugte vi 64 minutter, og det er stadig ikke lykkedes os at få tingene til at køre automatisk. De resterende problemer er oprettelse af root-adgangskode, som ikke ser ud til at virke og derefter få Galera Cluster i gang (SST-brugerproblem). Det er svært at sige, hvor lang tid det vil tage at fejlfinde det yderligere. Det er helt sikkert muligt - det er bare svært at kvantificere, fordi det virkelig afhænger af erfaringen med Ansible og MySQL. Det er bestemt ikke noget nogen bare kan downloade, konfigurere og køre. Nå, måske ville en anden spillebog have fungeret anderledes? Det er muligt, men det kan lige så godt resultere i forskellige problemer. Ok, så der er en indlæringskurve at klatre og fejlfinding for at lave, men så, når du er klar, vil du bare køre et script. Nå, det er sådan set rigtigt. Så længe ændringer introduceret af vedligeholderen ikke vil ødelægge noget, du er afhængig af, eller ny Ansible-version vil ødelægge playbook, eller vedligeholderen vil bare glemme projektet og stoppe med at udvikle det (for den rolle, vi brugte, er der en ret nyttig pull-anmodning, der venter allerede i næsten et år, hvilket måske kunne løse Python-afhængighedsproblemet - det er ikke blevet slået sammen). Medmindre du accepterer, at du bliver nødt til at vedligeholde denne kode, kan du ikke rigtig stole på, at den er 100 % nøjagtig og fungerer i dit miljø, især i betragtning af at den oprindelige udvikler ikke har nogen incitamenter til at holde koden opdateret. Og hvad med andre versioner? Du kan ikke bruge denne særlige playbook til at installere PXC 5.6 eller nogen MariaDB-version. Selvfølgelig er der andre spillebøger, du kan finde. Vil de fungere bedre, eller måske vil du bruge flere timer på at prøve at få dem til at arbejde?
ClusterControlSingle Console for hele din databaseinfrastrukturFind ud af, hvad der ellers er nyt i ClusterControlInstaller ClusterControl GRATISClusterControl
Lad os endelig tage et kig på, hvordan ClusterControl kan bruges til at implementere Percona XtraDB Cluster.
Konfiguration af SSH-forbindelse - 1 minut
ClusterControl kræver SSH-forbindelse på tværs af alle noder for at forbinde og konfigurere dem. Vi genererede en SSH-nøgle og distribuerede den manuelt på tværs af noderne.
Opsætning af ClusterControl - 3 minutter og 15 sekunder
Hurtig søgning "ClusterControl installation" pegede os på den relevante ClusterControl-dokumentationsside. Vi ledte efter en "enklere måde at installere ClusterControl på", derfor fulgte vi linket og fandt følgende instruktioner.
At downloade scriptet og køre det tog 3 minutter og 15 sekunder, vi var nødt til at foretage nogle handlinger, mens installationen fortsatte, så det er ikke uovervåget installation.
Log på brugergrænsefladen og start af implementering - 1 minut og 10 sekunder
Vi pegede vores browser til ClusterControl-nodens IP.
Vi videregav de nødvendige kontaktoplysninger, og vi blev præsenteret for velkomstskærmen:
Næste trin - vi valgte implementeringsmuligheden.
Vi skulle videregive SSH-forbindelsesoplysninger.
Vi besluttede også, hvilken leverandør, version, adgangskode og værter, der skulle bruges. Hele denne proces tog 1 minut og 10 sekunder.
Percona XtraDB Cluster Deployment - 12 minutter 5 sekunder
Det eneste, der var tilbage, var at vente på, at ClusterControl afsluttede implementeringen. Efter 12 minutter og 5 sekunder var klyngen klar:
Samlet installationstid - 17 minutter og 30 sekunder
Relaterede ressourcer ClusterControl for MySQL ClusterControl for MariaDB ClusterControl for Galera ClusterDet lykkedes os at implementere ClusterControl og derefter PXC-klyngen ved hjælp af ClusterControl på 17 minutter og 30 sekunder. PXC-implementeringen tog 12 minutter og 5 sekunder . Til sidst har vi en arbejdsklynge, implementeret i henhold til bedste praksis. ClusterControl sikrer også, at konfigurationen af klyngen giver mening. Kort sagt, selvom du ikke rigtig ved noget om MySQL eller Galera Cluster, kan du få installeret en produktionsklar klynge på et par minutter. ClusterControl er ikke kun et implementeringsværktøj, det er også en administrationsplatform - gør tingene endnu nemmere for folk, der ikke har erfaring med MySQL og Galera, at identificere ydeevneproblemer (gennem rådgivere) og udføre administrationshandlinger (skalere klyngen op og ned, køre sikkerhedskopier, oprette asynkrone slaver til Galera). Hvad der er vigtigt, vil ClusterControl altid blive vedligeholdt og kan bruges til at implementere alle MySQL-varianter (og ikke kun MySQL/MariaDB, den understøtter også TimeScaleDB, PostgreSQL og MongoDB). Det fungerede også ud af boksen, noget som ikke kan siges om andre metoder, vi testede.
Hvis du gerne vil opleve det samme, kan du downloade ClusterControl gratis. Fortæl os, hvordan du kunne lide det.