MariaDB 10.5 släpptes som GA i juni 2020. I utgåvan har det lagts till stöd för Amazon S3 eller andra offentliga eller privata moln från tredje part som stöder S3 API. Den har också sofistikerad hantering av privilegier som utökar dess granularitet, vilket gör att en DBA till exempel kan ge begränsade privilegier för en viss databasanvändare för att din databas ska vara säker.
MariaDB 10.5 skröt också med sina förbättringar med InnoDB-lagringsmotorn för dess prestanda och några nya variabler presenteras också men större föråldrade variabler har markerats som föråldrade eller helt borttagna. Notera till exempel att i MariaDB 10.5 har innodb_buffer_pool_instances redan markerats som utfasad medan den är inställd på att tas bort i version 10.6. Om du är nyfiken på vilken anledning de än säger, kolla in MDEV-15058.
Med alla dessa ändringar är det bäst att leverera den här bloggen för att ge en guide om hur man uppgraderar MariaDB 10.4 till MariaDB 10.5. Vi tar steg-för-steg vad du behöver tänka på för att uppgradera.
Saker du behöver innan du uppgraderar
Det är inte alltid den bästa metoden att uppgradera din databas live i produktion utan att göra ett test. Denna enkla jargong definierar termen vi kallar SNAFU. Du kanske träffar Google för att hitta termen, men i grund och botten är det alltid bäst att inte röra normal hälsa, särskilt de normalt fungerande systemen. Det är dock inte alltid som ditt system måste förbli konstant, det måste uppgraderas för att kunna använda säkerhetskorrigeringar, buggfixar och avancerade funktioner som finns i de nyare versionerna. Så i det här fallet har du alltid en failback-mekanism planerad och inställd före uppgraderingen. Om uppgraderingen av systemet kommer ikapp med problem som inte har observerats, kan det påverka ditt företag.
Skapa alltid en säkerhetskopia av din databas
I det här fallet ska du alltid säkerhetskopiera dina data. Du kan använda verktyg som mariabackup eller mydumper eller, om du är en ClusterControl-användare, använd sedan verktyget Database Backup Management. Om du ännu inte är förberedd på vilken typ av säkerhetskopia du behöver, kanske du måste kontrollera de bästa metoderna när du tar en säkerhetskopia.
Testa...Testa... och testa igen
Medan säkerhetskopieringen tillhandahåller data att mata ut ifall du behöver återställa till dess primära tillstånd om oförutsedda problem uppstår, måste uppgradering till en större version först testas till en utvecklings- eller iscensättningsmaskin. För stora företagsföretag är det vanligt att alltid göra ett regressionstest på en riktad QA-miljö eller iscensättningsmiljö där uppgraderingen av databasservrarna till dess huvudversion först måste tillämpas. Alla system från applikation och databas måste fortsätta ett regressionstest eller serie av QA-tester tills allt har gått igenom. Det är inte en bra idé att förenkla ett testfall av din applikation som går till databassystemen och bara utesluta att allt är bra så länge databasen inte kraschar eller det bara har bevisats under en kort tid där testet är kort, ett mycket enkelt test som bara täcker en liten andel av ditt totala system. Att testa din uppgradering först i en iscensättnings- eller QA-miljö måste prioriteras så att den måste uppnå den perfekta formen på din applikation utan att påverka affärssidan och även användarna som kommer att använda din applikation, än att inse sent att databasuppgraderingen gör att ditt system beter sig onormalt på grund av ändringar som du ännu inte har upptäckt.
Förbered en återställningsprocedur
Allt måste planeras under uppgraderingen av din databas. Närhelst säkerhetskopiering är tillgänglig och testning avslöjar starka och lovande resultat, känns det alltid säkert och förutsägbart ifall oväntade utmaningar inträffar när du uppgraderar dina MariaDB-produktionsdatabasservrar. I det här fallet ska du alltid skriva och förbereda en procedur som gör att saker och ting går tillbaka till det normala smidigt och sömlöst.
Om ditt underhållsfönster inte är för långt kan det vara ett bra val att förbereda en återställningsprocedur med hjälp av automatiserade verktyg som Ansible, Chef, Puppet, SaltStack eller Terraform. Det minimerar mänskliga fel och ger snabbhet och smidighet att utföra viktiga uppgifter. Även om det kan skadas om ett enskilt fel kan uppstå om automatiseringsskriptet misslyckas, betyder det också att du inte kan ignorera möjligheten att detta kan hända. Därför pekar detta också på att återställning måste vara sömlös och har testats ordentligt för att den ska kunna återställa till en giltig procedur.
Uppgraderingsprocedurer för MariaDB
Att uppgradera din MariaDB version 10.4 till 10.5 är inte ett krångel ännu en enkel sak. Nedan följer stegen du kan följa för att uppgradera till den senaste versionen av MariaDB 10.5.
Förbered ditt arkiv
Det är förståeligt att du har MariaDB 10.4, så det är ett antagande att det finns ett befintligt arkiv i dina nuvarande MariaDB-servernoder. Annars kan du lägga till ett arkiv ändå och det är bara enkelt.
Ubuntu/Debian
För Ubuntu/Debian-baserade system, för ett befintligt mariadb-förråd, kan du redigera förvaret. Du kanske kan verifiera om de befintliga förråden finns i din värd eller hitta om det finns ett befintligt MariaDB-förråd någonstans. För att göra det, bara,
$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*Vanligtvis har du ett mariadb.list-förråd. I min installation i Ubuntu 18.0 (Bionic) visas detta som följande:
[email protected]:/vagrant# cat /etc/apt/sources.list.d/mariadb.list
deb [arch=amd64] http://ftp.osuosl.org/pub/mariadb/repo/10.4/ubuntu bionic mainKör bara följande kommandorad för att lägga till MariaDB 10.5-förvaret,
. /etc/os-release
sudo echo "deb [arch=amd64] http://ftp.osuosl.org/pub/mariadb/repo/10.5/${ID} ${VERSION_CODENAME} main" >> /etc/apt/sources.list.d/mariadb.listInnan MariaDB-paket kan installeras, kräver det att paketen som ska installeras måste importeras med den offentliga GPG-nyckeln som används för att verifiera de digitala signaturerna för paketen i deras arkiv. Du kan kontrollera dina apt-nycklar med följande,
$ apt-key list |grep -C2 -i 'mariadb'Om nycklar inte importeras
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943dbeller för nyare Ubuntu/Debian-baserade versioner, dvs. börjar med Debian 9 (Stretch), och Debian Unstable (Sid), och Ubuntu 16.04 LTS (Xenial),
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8När du är klar är det bara att köra
$ sudo apt updateCentOS/RHEL
För CentOS/RHEL, om du har ett befintligt arkiv, kan du bara lägga till eller redigera filen. I annat fall räcker det med att lägga till raderna nedan för MariaDB 10.5-förvaret (se mariadb.repo). Till exempel har jag följande mariadb.repo i min CentOS 8.0-värd.
[[email protected] ~]# cat /etc/yum.repos.d/mariadb.repo
[mariadb]
name = MariaDB Repository
baseurl = http://yum.mariadb.org/10.4/centos8-amd64
enabled = 1
gpgkey = https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1
[mariadb_10.5]
name = MariaDB Repository For 10.5
baseurl = http://yum.mariadb.org/10.5/centos8-amd64
enabled = 1
gpgkey = https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1Du kan verifiera att om MariaDB-förvaret är aktiverat och fungerar bra:
[[email protected] ~]# dnf --disablerepo=* --enablerepo=mariadb_10.5 repolist
repo id repo name status
mariadb_10.5 MariaDB Repository For 10.5 83Uppgradera dina MariaDB-paket
Att uppgradera med MariaDB är väldigt enkelt. Se till att du har stängt av MariaDB-servern ordentligt först.
För en upptagen och levande produktionsserver, se till att du inte har några inkommande anslutningar och att de smutsiga sidorna spolas ordentligt till disken. Innan du stänger av servern kan du ställa in spolningen av smutsiga sidor med din Innodb-lagringsmotor aggressivt så att alla smutsiga sidor töms och gör avstängningsprocessen snabbare,
set global innodb_max_dirty_pages_pct = 0;Övervaka sedan de smutsiga sidorna med följande,
$ mysqladmin ext -i10 | grep dirty
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |När det är bra, stäng av MariaDB-instansen,
systemctl stop mariadbFör ett master-/replikdatabaskluster är det en god praxis att alltid starta uppgraderingen på replikerna. Så innan uppgraderingen och efter avstängningen, se till att du har lagt till följande i din my.cnf-konfigurationsfil,
[mysqld]
….
skip-slave-startDetta låter dig undvika att automatiskt starta replikeringstrådarna när MariaDB-servern startas. Detta ger dig mer säkerhet och undviker ytterligare misstag i replikeringen. Starta replikeringstrådarna manuellt när de är klara med följande sats,
START SLAVE;Ubuntu/Debian
Att uppgradera med Ubuntu/Debian-baserade system är ganska okomplicerat,
sudo apt install --only-upgrade mariadb-server mariadb-client mariadb-backup mariadb-commonGe självklart inte alternativet -y så att du kan granska följande paket som ska uppdateras.
Centos/RHEL
Precis som med Ubuntu/Debian-baserade system visar CentOS/RHEL inte heller något krångel för att uppgradera din nuvarande MariaDB 10.4-version. Du kan köra följande kommando nedan för att räcka processen,
$ dnf --disablerepo=* --enablerepo=mariadb_10.5 upgrade Mariadb-server MariaDB-client MariaDB-backup MariaDB-common Mariadb-sharedEfter installation/paketuppgradering
När paketen har uppgraderats. Eftersom detta är en stor uppgradering, glöm inte att ladda om demonen för systemd. Bara kör,
$ systemctl daemon-reloadNu när du är klar, starta mariadb-tjänsten
$ systemctl start mariadboch kör mysqld_upgrade,
$ mysql_upgrade Medan du kör mysql_upgrade, övervaka alltid felloggen så att du kan fånga eventuella fel innan du kör och startar allt för din normala verksamhet:
tail -5f /var/log/mariadb/mariadb.logUppgraderingstips för ClusterControl-användare
Eftersom ClusterControl inte tillhandahåller större versionsuppgraderingar, när du utför en paketuppgradering, glöm inte alltid att stänga av automatiska återställningslägen för ditt MariaDB-kluster. Ställ in noderna på underhållsläge så att varningarna är tysta och inga falska varningar ska meddelas.