Sådan opgraderes fra MariaDB 10.4 til MariaDB 10.5

MariaDB 10.5 blev udgivet som GA i juni 2020. I udgivelsen er der tilføjet understøttelse af Amazon S3 eller enhver offentlig eller privat tredjepartssky, der understøtter S3 API. Den har også sofistikeret håndtering af privilegier, der udvider dens granularitet, hvilket gør det muligt for en DBA for eksempel at give begrænsede privilegier på en bestemt databasebruger for stram sikkerhed af din database.

MariaDB 10.5 pralede også af sine forbedringer med InnoDB-lagringsmotoren for dens ydeevne, og nogle nye variabler præsenteres også, men større forældede variabler er blevet markeret som forældede eller helt fjernet. Bemærk for eksempel, at i MariaDB 10.5 er innodb_buffer_pool_instances allerede blevet markeret som forældet, mens det er indstillet til at blive fjernet i version 10.6. Hvis du er nysgerrig efter hvilken grund de siger, så tjek venligst MDEV-15058.

Med alle disse ændringer er det bedst at levere denne blog for at give en guide til, hvordan man opgraderer MariaDB 10.4 til MariaDB 10.5. Vi tager det trin-for-trin om, hvilke ting du skal overveje for at opgradere.

Ting, du skal bruge, før du opgraderer

Det er ikke altid den bedste metode til at opgradere din database live i produktion uden at lave en test. Denne simple jargon definerer det begreb, vi kalder SNAFU. Du kan måske trykke på Google for at finde udtrykket, men dybest set er det altid bedst ikke at røre ved normal sundhed, især de normalt fungerende systemer. Det er dog ikke altid, at dit system skal forblive konstant, det skal opgraderes for at benytte sikkerhedsrettelser, fejlrettelser og avancerede funktioner, der er til stede på de nyere versionsudgivelser. Så i dette tilfælde har du altid planlagt og konfigureret en failback-mekanisme forud for opgraderingen. Hvis en opgradering af systemet indhenter problemer, der ikke blev observeret, kan det få indflydelse på din virksomhed.

Opret altid en sikkerhedskopi af din database

I dette tilfælde skal du altid sørge for backup af dine data. Du kan bruge værktøjer som f.eks. mariabackup eller mydumper eller, hvis du er ClusterControl-bruger, så brug værktøjet Database Backup Management. Hvis du endnu ikke er forberedt på, hvilken type sikkerhedskopiering du har brug for, skal du muligvis tjekke de bedste fremgangsmåder, når du tager en sikkerhedskopi.

Test...Test... og test igen

Mens backup giver data til feed, hvis du skal gendanne til dens primære tilstand, hvis der opstår uforudsete problemer, skal opgradering til en større udgivelse først testes i en udviklings- eller iscenesættelsesmaskine. For store virksomhedsvirksomheder er det almindelig praksis altid at lave en regressionstest på et målrettet QA-miljø eller iscenesættelsesmiljø, hvor opgraderingen af ​​databaseserverne til dens hovedversion først skal anvendes. Alle systemer fra applikation og database skal fortsætte en regressionstest eller serie af QA-test, indtil alt er bestået. Det er ikke en god idé at forenkle en testcase af din applikation, der går til databasesystemerne og bare udelukke, at alt er i orden, så længe databasen ikke går ned, eller det bare er blevet bevist i kort tid, hvor testen er kort, en meget simpel test, som blot dækker en lille procentdel af dit samlede system. At teste din opgradering først på et iscenesættelses- eller QA-miljø skal prioriteres således, at den skal opnå den helt gode form af din applikation uden at påvirke forretningssiden og også de brugere, der skal bruge din applikation, end sent at indse, at databaseopgraderingen får dit system til at opføre sig unormalt på grund af ændringer, du endnu ikke har opdaget.

Forbered en gendannelsesprocedure

Alt skal planlægges under opgraderingen af ​​din database. Når backup er tilgængelig, og test afslører stærke og lovende resultater, føles det altid sikkert og forudsigeligt, hvis der opstår uventede udfordringer, mens du opgraderer dine MariaDB-produktionsdatabaseservere. I dette tilfælde skal du altid skrive og forberede en procedure, der får tingene til at gå tilbage til det normale problemfrit og problemfrit.

Hvis dit vedligeholdelsesvindue ikke er for langt, kan forberedelse af en gendannelsesprocedure ved hjælp af automatiserede værktøjer såsom Ansible, Chef, Puppet, SaltStack eller Terraform være et godt valg til gendannelsesprocedure. Det minimerer menneskelige fejl og giver hurtighed og smidighed til at udføre vitale opgaver. Selvom det kan skade, hvis der kan opstå en enkelt fejl, hvis automatiseringsscriptet fejler, så betyder det også, at du ikke kan ignorere muligheden for, at dette kan ske. Derfor peger dette også på, at gendannelse skal være problemfri og er blevet testet korrekt, for at den skal kunne gendanne til en gyldig procedure.

MariaDB-opgraderingsprocedurer

Opgradering af din MariaDB version 10.4 til 10.5 er ikke besværligt endnu en ligetil. Nedenfor er de trin, du kan følge for at opgradere til den seneste MariaDB 10.5-version.

Forbered dit lager

Det er forståeligt, at du har MariaDB 10.4, så det er en antagelse, at der er et aktuelt lager i dine nuværende MariaDB-servernoder. Ellers kan du tilføje et lager alligevel, og det er bare enkelt.

Ubuntu/Debian

For Ubuntu/Debian-baserede systemer, for et eksisterende mariadb-lager, kan du redigere depotet. Du kan muligvis verificere, om de eksisterende depoter er i din vært, eller finde ud af, om der er et eksisterende MariaDB-lager et eller andet sted. For at gøre det, bare,

$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/* 

Du har typisk et mariadb.list-lager. I min opsætning i Ubuntu 18.0 (Bionic) vises dette som følgende:

[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 main 

Kør blot følgende kommandolinje for at tilføje MariaDB 10.5-lageret,

$ apt-key list |grep -C2 -i 'mariadb' 

$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db 

$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8 

$ sudo apt update 

[[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 = 1 

[[email protected] ~]# dnf --disablerepo=* --enablerepo=mariadb_10.5 repolist 

repo id                                repo name                                              status

mariadb_10.5                           MariaDB Repository For 10.5                            83 

set global innodb_max_dirty_pages_pct = 0; 

$ mysqladmin ext -i10 | grep dirty

| Innodb_buffer_pool_pages_dirty                         | 0                                                |

| Innodb_buffer_pool_bytes_dirty                         | 0                                                | 

systemctl stop mariadb 

[mysqld]

….

skip-slave-start 

START SLAVE; 

sudo apt install --only-upgrade  mariadb-server mariadb-client mariadb-backup mariadb-common 

$ dnf --disablerepo=* --enablerepo=mariadb_10.5 upgrade Mariadb-server MariaDB-client MariaDB-backup MariaDB-common Mariadb-shared 

$ systemctl daemon-reload 

$ systemctl start mariadb 

$ mysql_upgrade  

tail -5f /var/log/mariadb/mariadb.log