Det finns flera sätt att distribuera en databas. Du kan installera det för hand, du kan lita på de allmänt tillgängliga verktygen för orkestrering av infrastruktur som Ansible, Chef, Puppet eller Salt. Dessa verktyg är mycket populära och det är ganska lätt att hitta skript, recept, spelböcker, you name it, som hjälper dig att automatisera installationen av ett databaskluster. Det finns också mer specialiserade databasautomatiseringsplattformar, som ClusterControl, som också kan användas för automatiserad distribution. Vad skulle vara det bästa sättet att distribuera ditt kluster? Hur mycket tid behöver du egentligen för att distribuera det?
Låt oss först klargöra vad vi vill göra. Låt oss anta att vi kommer att distribuera Percona XtraDB Cluster 5.7. Den kommer att bestå av tre noder och för det kommer vi att använda tre virtuella Vagrant-maskiner som kör Ubuntu 16.04 (bento/ubuntu-16.04-bild). Vi kommer att försöka distribuera ett kluster manuellt och sedan använda Ansible och ClusterControl. Låt oss se hur resultaten kommer att se ut.
Manuell distribution
Inställning av förvar - 1 minut, 45 sekunder.
Först och främst måste vi konfigurera Percona repositories på alla Ubuntu-noder. Snabb googlesökning, ssh till de virtuella maskinerna och att köra nödvändiga kommandon tar 1m45s
Vi hittade följande sida med instruktioner:
https://www.percona.com/doc/percona-repo-config/percona-release.html
och vi utförde steg som beskrivs i avsnittet "DEB-BASERAD GNU/LINUX DISTRIBUTION". Vi körde också apt update, för att uppdatera apts cache.
Installera PXC-noder - 2 minuter 45 sekunder
Detta steg består i princip av att köra:
[email protected]:~# apt install percona-xtradb-cluster-5.7Resten beror mest på din internetuppkopplingshastighet när paket laddas ner. Din input kommer också att behövas (du kommer att skicka ett lösenord för superanvändaren) så det är inte obevakad installation. När allt är klart kommer du att ha tre körande 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:-1Konfigurera PXC-noder - 3 minuter, 25 sekunder
Här börjar den knepiga delen. Det är verkligen svårt att kvantifiera erfarenhet och hur mycket tid man skulle behöva för att faktiskt förstå vad som behövs göras. Vad som är bra, google-sökning "how to install percona xtrabdb cluster" pekar på Perconas dokumentation, som beskriver hur processen ska se ut. Det kan fortfarande ta mer eller mindre tid, beroende på hur bekant du är med PXC och Galera i allmänhet. I värsta fall kommer du inte att vara medveten om några ytterligare nödvändiga åtgärder och du kommer att ansluta till din PXC och börja arbeta med den, utan att inse att du faktiskt har tre noder, som var och en bildar ett eget kluster.
Låt oss anta att vi följer rekommendationen från Percona och tar tid på att just de stegen ska utföras. Kort sagt, vi modifierade konfigurationsfiler enligt instruktionerna på Perconas webbplats, vi försökte också bootstrap den första noden:
[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 ^CDetta såg inte korrekt ut. Tyvärr var instruktionerna inte kristallklara. Återigen, om du inte vet vad som händer, kommer du att spendera mer tid på att försöka förstå vad som hände. Lyckligtvis kommer stackoverflow.com till stor hjälp (även om det inte är det första svaret på listan som vi fick) och du bör inse att du missar [mysqld]-sektionshuvudet i din /etc/mysql/my.cnf-fil. Att lägga till detta på alla noder och upprepa bootstrap-processen löste problemet. Totalt tillbringade vi 3 minuter och 25 sekunder (inte inklusive att googla efter felet eftersom vi direkt märkte vad som var problemet).
Konfigurera för SST, föra in andra noder i klustret - med start från 8 minuter till oändligt
Instruktionerna på Perconas webbplats är ganska tydliga. När du har en nod igång, starta bara återstående noder och du kommer att bli bra. Vi försökte det och vi kunde inte se fler noder som gick med i klustret. Det är här det är praktiskt taget omöjligt att säga hur lång tid det tar att diagnostisera problemet. Det tog oss 6-7 minuter men för att kunna göra det snabbt måste du:
- Var bekant med hur PXC-konfigurationen är uppbyggd:
[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 - Vet hur !include- och !includedir-direktiven fungerar i MySQL-konfigurationsfiler
- Vet hur MySQL hanterar samma variabler som ingår i flera filer
- Vet vad du ska leta efter och var medveten om konfigurationer som skulle resultera i att noden startar sig själv för att bilda ett kluster på egen hand
Problemet var relaterat till det faktum att instruktionerna inte nämnde någon fil förutom /etc/mysql/my.cnf där vi faktiskt borde ha modifierat /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf. Den filen innehöll tom variabel:
wsrep_cluster_address=gcomm://och en sådan konfiguration tvingar noden att bootstrap eftersom den inte har information om andra noder att ansluta sig till. Vi ställde in den variabeln i /etc/mysql/my.cnf men senare inkluderades filen wsrep.cnf, vilket skrev över vår inställning.
Det här problemet kan vara en allvarlig blockerare för personer som inte riktigt är bekanta med hur MySQL och Galera fungerar, vilket resulterar i till och med timmar om inte mer av felsökning.
Total installationstid - 16 minuter (om du är MySQL DBA som jag är)
Vi lyckades installera Percona XtraDB Cluster på 16 minuter. Du måste komma ihåg ett par saker - vi har inte justerat konfigurationen. Detta är något som kommer att kräva mer tid och kunskap. PXC-noden kommer med en enkel konfiguration, mest relaterad till binär loggning och Galera-skrivuppsättningsreplikering. Det finns ingen InnoDB-inställning. Om du inte är bekant med MySQL-interna funktioner, är detta timmar om inte dagar av att läsa och bekanta dig med interna mekanismer. En annan viktig sak är att detta är en process som du måste återansöka för varje kluster du distribuerar. Slutligen lyckades vi identifiera problemet och lösa det mycket snabbt på grund av vår erfarenhet av Percona XtraDB Cluster och MySQL i allmänhet. Casual användare kommer med största sannolikhet att spendera betydligt mer tid på att försöka förstå vad som händer och varför.
Ansible Playbook
Nu till automatisering med Ansible. Låt oss försöka hitta och använda en lämplig spelbok, som vi kan återanvända för alla ytterligare distributioner. Låt oss se hur lång tid det tar att göra det.
Konfigurera SSH-anslutning - 1 minut
Ansible kräver SSH-anslutning över alla noder för att ansluta och konfigurera dem. Vi genererade en SSH-nyckel och distribuerade den manuellt över noderna.
Finding Ansible Playbook - 2 minuter 15 sekunder
Huvudfrågan här är att det finns så många spelböcker tillgängliga där ute att det är omöjligt att avgöra vad som är bäst. Som sådan bestämde vi oss för att välja topp 3 Google-resultat och försöka välja ett. Vi bestämde oss för https://github.com/cdelgehier/ansible-role-XtraDB-Cluster eftersom det verkar vara mer konfigurerbart än de återstående.
Klona arkivet och installera Ansible - 30 sekunder
Det här går snabbt, allt vi behövde var att
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitFörbereder inventeringsfil - 1 minut och 10 sekunder
Detta steg var också väldigt enkelt, vi skapade en inventeringsfil med hjälp av exempel från dokumentation. Vi har precis ersatt IP-adresserna för noderna med det vi har konfigurerat i vår miljö.
Förbereda en Playbook - 1 minut 45 sekunder
Vi bestämde oss för att använda det mest omfattande exemplet från dokumentationen, som också inkluderar lite av konfigurationsjusteringen. Vi förberedde en korrekt struktur för Ansible (det fanns ingen sådan information i dokumentationen):
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterSedan körde vi det men omedelbart fick vi ett felmeddelande:
[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 }}"Detta tog 1 minut och 45 sekunder.
Lösa syntaxproblemet i Playbook - 3 minuter 25 sekunder
Felet var missvisande men den allmänna tumregeln är att prova den senaste versionen av Ansible, vilket vi gjorde. Vi googlade och hittade bra instruktioner på Ansibles hemsida. Nästa försök att köra spelboken misslyckades också:
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 minuter och 25 sekunder att installera en ny Ansible-version och köra spelboken till det här felet.
Åtgärda den saknade Python-modulen - 3 minuter 20 sekunder
Uppenbarligen tog rollen vi använde inte till sina förutsättningar och en Python-modul saknades för att ansluta till och säkra Galera-klustret. Vi försökte först installera MySQL-python via pip men det blev uppenbart att det kommer att ta längre tid eftersom det krävde 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 tillhandahålls av MySQL-utvecklingsbibliotek så vi skulle behöva installera dem manuellt, vilket var ganska meningslöst. Vi bestämde oss för att gå med PyMySQL, som inte krävde andra paket att installera. Detta förde oss till en annan fråga:
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.retryFram till denna punkt spenderade vi 3 minuter och 20 sekunder.
Att åtgärda felet "Åtkomst nekad" - 18 minuter 55 sekunder
Enligt felet säkerställde vi att MySQL-konfigurationen är korrekt förberedd och att den inkluderade korrekt användare och lösenord för att ansluta till databasen. Detta fungerade tyvärr inte som förväntat. Vi undersökte ytterligare och fann att rollen inte skapade root-användare korrekt, även om den markerade steget som slutfört. Vi gjorde en kort undersökning men bestämde oss för att göra den manuella korrigeringen istället för att försöka felsöka spelboken, vilket skulle ta mycket mer tid än de steg vi gjorde. Vi skapade just manuellt användare [email protected] och [email protected] med korrekta lösenord. Detta gjorde det möjligt för oss att skicka detta steg till ett annat fel:
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.retryFör det här avsnittet spenderade vi 18 minuter och 55 sekunder.
Åtgärda "Starta slavnoderna"-problemet (del 1) - 7 minuter 40 sekunder
Vi försökte ett par saker för att lösa detta problem. Vi försökte specificera noden med dess namn, vi försökte byta gruppnamn, ingenting löste problemet. Vi bestämde oss för att rensa upp miljön med hjälp av skriptet i dokumentationen och börja om från början. Det gjorde inte rent det utan gjorde bara saken ännu värre. Efter 7 minuter och 40 sekunder bestämde vi oss för att utplåna de virtuella maskinerna, återskapa miljön och börja om från början i hopp om att när vi lägger till Python-beroenden kommer detta att lösa vårt problem.
Åtgärda "Starta slavnoderna"-problemet (del 2) - 13 minuter 15 sekunder
Tyvärr hjälpte det inte alls att ställa in Python-förutsättningar. Vi bestämde oss för att avsluta processen manuellt, starta upp den första noden och sedan konfigurera SST-användare och starta återstående slavar. Detta slutförde den "automatiska" inställningen och det tog oss 13 minuter och 15 sekunder att felsöka och sedan slutligen acceptera att det inte kommer att fungera som playbook-designern förväntade sig.
Ytterligare felsökning - 10 minuter 45 sekunder
Vi stannade inte där och bestämde oss för att vi ska prova en sak till. Istället för att förlita sig på Ansible-variabler sätter vi bara IP:n för en av noderna som masternod. Detta löste den delen av problemet och vi slutade 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)\")"}Detta var slutet på våra försök - vi försökte lägga till den här användaren men det fungerade inte korrekt genom den möjliga spelboken medan vi kunde använda IPv6 localhost-adress för att ansluta till när vi använde MySQL-klienten.
Total installationstid - okänd (automatisk installation misslyckades)
Totalt spenderade vi 64 minuter och vi har fortfarande inte lyckats få igång saker automatiskt. De återstående problemen är att skapa root-lösenord som inte verkar fungera och sedan få igång Galera Cluster (SST-användarproblem). Det är svårt att säga hur lång tid det tar att felsöka det ytterligare. Det är säkert möjligt - det är bara svårt att kvantifiera eftersom det verkligen beror på erfarenheten med Ansible och MySQL. Det är definitivt inte något vem som helst bara kan ladda ner, konfigurera och köra. Nåväl, kanske en annan lekbok hade fungerat annorlunda? Det är möjligt, men det kan lika gärna leda till olika problem. Ok, så det finns en inlärningskurva att klättra och felsökning för att göra, men sedan, när du är klar, kommer du bara att köra ett skript. Tja, det är typ sant. Så länge ändringar som införts av underhållaren inte kommer att bryta något du är beroende av eller så kommer den nya Ansible-versionen att förstöra spelboken eller så kommer underhållaren bara att glömma projektet och sluta utveckla det (för rollen som vi använde finns det en ganska användbar pull-begäran som väntar redan i nästan ett år, vilket kanske skulle kunna lösa Python-beroendeproblemet - det har inte slagits samman). Om du inte accepterar att du måste underhålla den här koden kan du inte riktigt lita på att den är 100 % korrekt och fungerar i din miljö, särskilt med tanke på att den ursprungliga utvecklaren inte har några incitament att hålla koden uppdaterad. Och hur är det med andra versioner? Du kan inte använda den här spelboken för att installera PXC 5.6 eller någon MariaDB-version. Visst, det finns andra spelböcker du kan hitta. Kommer de att fungera bättre eller kanske du tillbringar en massa timmar till för att få dem att fungera?
ClusterControlSingle Console för hela din databasinfrastrukturTa reda på vad mer som är nytt i ClusterControlInstallera ClusterControl GRATISClusterControl
Slutligen, låt oss ta en titt på hur ClusterControl kan användas för att distribuera Percona XtraDB Cluster.
Konfigurera SSH-anslutning - 1 minut
ClusterControl kräver SSH-anslutning över alla noder för att ansluta och konfigurera dem. Vi genererade en SSH-nyckel och distribuerade den manuellt över noderna.
Konfigurera ClusterControl - 3 minuter 15 sekunder
Snabbsökning "ClusterControl installation" visade oss på relevant ClusterControl-dokumentationssida. Vi letade efter ett "enklare sätt att installera ClusterControl" därför följde vi länken och hittade följande instruktioner.
Att ladda ner skriptet och köra det tog 3 minuter och 15 sekunder, vi var tvungna att vidta några åtgärder medan installationen fortsatte så det är inte oövervakad installation.
Logga in på gränssnittet och start av driftsättning - 1 minut 10 sekunder
Vi pekade med vår webbläsare på IP:n för ClusterControl-noden.
Vi skickade de nödvändiga kontaktuppgifterna och vi presenterades med välkomstskärmen:
Nästa steg - vi valde distributionsalternativet.
Vi var tvungna att skicka SSH-anslutningsinformation.
Vi bestämde oss också för leverantör, version, lösenord och värdar att använda. Hela denna process tog 1 minut och 10 sekunder.
Percona XtraDB Cluster Deployment - 12 minuter 5 sekunder
Det enda som återstod var att vänta på att ClusterControl skulle slutföra driftsättningen. Efter 12 minuter och 5 sekunder var klustret klart:
Total installationstid - 17 minuter 30 sekunder
Relaterade resurser ClusterControl för MySQL ClusterControl för MariaDB ClusterControl för Galera ClusterVi lyckades distribuera ClusterControl och sedan PXC-kluster med ClusterControl på 17 minuter och 30 sekunder. Själva PXC-distributionen tog 12 minuter och 5 sekunder . I slutet har vi ett fungerande kluster, distribuerat enligt bästa praxis. ClusterControl ser också till att konfigurationen av klustret är vettig. Kort sagt, även om du egentligen inte kan något om MySQL eller Galera Cluster, kan du få ett produktionsfärdigt kluster utplacerat på ett par minuter. ClusterControl är inte bara ett distributionsverktyg, det är också en hanteringsplattform - gör saker ännu enklare för personer som inte har erfarenhet av MySQL och Galera att identifiera prestandaproblem (genom rådgivare) och utföra hanteringsåtgärder (skala klustret upp och ner, köra säkerhetskopior, skapa asynkrona slavar till Galera). Vad som är viktigt, ClusterControl kommer alltid att underhållas och kan användas för att distribuera alla MySQL-smaker (och inte bara MySQL/MariaDB, den stöder även TimeScaleDB, PostgreSQL och MongoDB). Det fungerade också direkt, något som inte kan sägas om andra metoder vi testade.
Om du vill uppleva samma sak kan du ladda ner ClusterControl gratis. Berätta för oss hur du tyckte om det.