"Hold din database opgraderet til den nyeste version - det er for din sikkerhed" er noget, du ofte hører som gode råd og bedste praksis, når det kommer til databasestyring. På den anden side kan det være en tidskrævende opgave at opgradere din database. Selv en mindre versionsopgradering kræver, at du grundigt tester opgraderingen i et staging-miljø, før du opgraderer din produktionsopsætning. Så hvad er den store sag? Hvis du kun halter bagud en mindre version, burde det ikke være ligegyldigt, vel? Nå, det er måske ikke ... før det gør det. Og er du virkelig parat til at tage den slags risiko?
Tidligere i år blev en ny potentielt farlig sårbarhed identificeret i Galera Cluster (CVE-2021-27928). Ved første øjekast ser vi, at sværhedsgraden blev markeret som høj, og når vi begynder at grave yderligere i problemet, ser det faktisk alvorligt ud. Det ser ud til, at en SUPER-bruger kan udføre enhver vilkårlig kode ved at ændre variablerne wsrep_provider og wsrep_notify_cmd under kørsel. Det giver brugeren mulighed for at indlæse .so-biblioteket og pege på et script, som serveren vil udføre. Som du kan forestille dig, er dette ikke en god situation. Selvfølgelig skal du have adgang til SUPER-brugeren, og du skal have noget tilgængeligt til at udføre på databasenoden, men det faktum, at Galera kan konfigureres til at udføre vilkårlig kode som en 'mysql'-bruger, er dårligt nok på dens egen.
Som sædvanligt, i tilfælde som disse, er rettelserne blevet oprettet, og nye versioner af softwaren, upåvirket af sårbarheden, er blevet skubbet. Dette særlige problem er blevet rettet i MariaDB 10.5.9, 10.4.18, 10.3.28 og 10.2.37, samt Percona XtraDB Cluster 5.6.51-28.46, Percona XtraDB Cluster 5.7.33-31.49 og PerconaDB Xtra 8.0.22-13.1. Alt ser ud til at være tilbage til det normale. Ikke?
Forkert. Der er utallige systemer, der kører på produktion, som endnu ikke er blevet opgraderet til den nye, upåvirkede version. Severalnines supportteam er i kontakt med mange databasemiljøer i naturen, og vi arbejder konstant med kundeemner for at hjælpe dem med at migrere til et miljø, der administreres af ClusterControl. Vi ser alle slags MySQL (og ikke kun MySQL) køre i forældede versioner, nogle gange endda versioner, der har nået deres End Of Life og ikke længere får sikkerhedsopdateringer. Det burde ikke være tilfældet, især hvis du er ClusterControl-bruger.
ClusterControl kommer med et sæt funktioner, der hjælper dig med at holde dig opdateret med alle sikkerhedsrettelser. Lad os tage et kig:
Først og fremmest kommer ClusterControl med driftsrapporter, en af dem er pakkeopgraderingsrapporten:
Som alle ClusterControls driftsrapporter kan pakkeopgraderingsrapporten planlægges til at udføres regelmæssigt og derefter leveres via e-mail. Den vil indeholde information om pakkeversionerne installeret på noderne, og hvis der er nogen form for opgraderinger, der skal udføres:
Pakkeopgraderingsrapporten præsenterer en liste over pakker, der bør opdateres for alle databaser, loadbalancers, sikkerhedsrettelser og andre pakker installeret på noden. For alle systempakkerne er løsningen at opgradere dem ved hjælp af standardmetoder (apt, yum). Når det kommer til databaser og loadbalancers, kommer ClusterControl med funktionalitet, der giver dig mulighed for at udføre den mindre versionsopgradering direkte fra brugergrænsefladen.
Før vi går dertil, lad os antage, at databasen skal opdateres. Du ønsker ikke bare at fortsætte og køre opgraderingen i blinde - det kan potentielt forårsage problemer for din applikation. Det burde det ikke - mindre versioner bryder ikke bagudkompatibilitet (undtagen når du bruger MySQL 8.0 - så ja, du kan forvente alt, når du går fra 8.0.x til 8.0.x+1); dog er der altid en vis risiko involveret. Det du først skal gøre er at teste opgraderingen i et separat miljø.
Vi har en simpel MariaDB Galera-klynge med ProxySQL og Keepalived:
Vi vil gerne bygge en testklynge, så vi kan teste opgraderingen behandle. Med ClusterControl er det lige så nemt som at bruge Create Replica Cluster job:
Vi kan hente de friske data fra den eksisterende klynge, eller vi kan bruge dataene fra en sikkerhedskopi.
Vi skal også vælge en kildenode i produktionsklyngen:
Så skal vi igennem en almindelig installationsguide, vælge version og leverandør af databasen, definere root-adgangskode og så videre. Vi afslutter med at videregive de noder, som klyngen vil blive installeret på.
Som et resultat vil du se en ny klynge på listen med en tydeligt mærke, at det kopierer fra produktionsklyngen. En ting, der er værd at nævne, i standardopsætningen vil ClusterControl bruge de nyeste versioner af pakkerne til at oprette replika-klyngen. Hvis du bare vil dobbelttjekke forespørgslerne, er dette nok. Hvis du vil gennemgå hele opgraderingsprocessen, skal du fastgøre ældre versioner af MySQL-pakkerne for at installere en gammel version (og derefter løsne dem og teste opgraderingen).
På den ene eller den anden måde vil du efter vellykkede test til sidst ønsker at udføre opgraderingen. ClusterControl kan hjælpe dig med at opnå dette:
I Administrer -> Opgraderinger finder du en brugergrænseflade til at udføre opgraderingen .
Du kan bruge "Søg efter nye pakker" til at opdatere databasen over tilgængelige pakker. Vi kan også vælge, hvilke noder vi vil opgradere, og hvilke tjenester:
Bekræft blot, og det er det - ClusterControl udfører opgraderingen og giver dig seneste version af pakkerne.
Som du kan se, gør ClusterControl det nemt og ligetil at holde dine databaser opdateret. Det eneste trin, du skal håndtere manuelt, er den korrekte test. Ellers - alt andet kan udføres for dig af ClusterControl. Interesseret i at lære mere om, hvordan ClusterControl kan hjælpe dig med at administrere din database effektivt? Prøv det gratis i 30 dage.