"Houd uw database geüpgraded naar de nieuwste versie - het is voor uw veiligheid" is iets dat u vaak hoort als goed advies en best practice als het gaat om databasebeheer. Aan de andere kant kan het upgraden van uw database een tijdrovende taak zijn. Zelfs een kleine versie-upgrade vereist dat u de upgrade grondig test in een testomgeving voordat u uw productie-installatie opwaardeert. Dus wat is het probleem? Als je maar één kleine versie achterloopt, zou het niet uit moeten maken, toch? Nou, misschien niet... totdat het dat doet. En ben je echt bereid om dat soort risico te nemen?
Eerder dit jaar werd een nieuwe potentieel gevaarlijke kwetsbaarheid geïdentificeerd in Galera Cluster (CVE-2021-27928). Op het eerste gezicht zien we dat de ernst als hoog was gemarkeerd, en als we ons verder gaan verdiepen in het probleem, ziet het er inderdaad ernstig uit. Het lijkt erop dat een SUPER-gebruiker willekeurige code kan uitvoeren door de variabelen wsrep_provider en wsrep_notify_cmd tijdens runtime te wijzigen. Het stelt de gebruiker in staat om de .so-bibliotheek te laden en naar een script te verwijzen dat de server zal uitvoeren. Zoals je je kunt voorstellen, is dit geen goede situatie. Natuurlijk, je moet toegang hebben tot de SUPER-gebruiker, en je zou iets beschikbaar moeten hebben om uit te voeren op het databaseknooppunt, maar het feit dat Galera kan worden geconfigureerd om willekeurige code uit te voeren als een 'mysql'-gebruiker is al erg genoeg op zijn eigen.
Zoals gebruikelijk zijn in dergelijke gevallen de fixes gemaakt en zijn nieuwe versies van de software, die niet door de kwetsbaarheid zijn aangetast, gepusht. Dit specifieke probleem is opgelost in MariaDB 10.5.9, 10.4.18, 10.3.28 en 10.2.37, evenals Percona XtraDB Cluster 5.6.51-28.46, Percona XtraDB Cluster 5.7.33-31.49 en Percona XtraDB Cluster 8.0.22-13.1. Alles lijkt weer normaal te worden. Toch?
Fout. Er zijn talloze systemen die in productie zijn en die nog niet zijn geüpgraded naar de nieuwe, onaangetaste versie. Het ondersteuningsteam van verschillendenines heeft contact met veel database-omgevingen in het wild, en we werken voortdurend samen met potentiële klanten om hen te helpen migreren naar een omgeving die wordt beheerd door ClusterControl. We zien allerlei soorten MySQL (en niet alleen MySQL) draaien in verouderde versies, soms zelfs versies die hun End Of Life hebben bereikt en geen beveiligingsupdates meer krijgen. Dat zou niet het geval moeten zijn, vooral niet als u een ClusterControl-gebruiker bent.
ClusterControl wordt geleverd met een reeks functies waarmee u op de hoogte kunt blijven van alle beveiligingsoplossingen. Laten we eens kijken:
Allereerst wordt ClusterControl geleverd met operationele rapporten, waaronder het pakketupgraderapport:
Zoals alle operationele rapporten van ClusterControl, kan het pakketupgraderapport worden gepland om regelmatig worden uitgevoerd en vervolgens per e-mail worden bezorgd. Het bevat informatie over de pakketversies die op de knooppunten zijn geïnstalleerd en of er upgrades moeten worden uitgevoerd:
Het pakket-upgraderapport bevat een lijst met pakketten die voor alle databases, loadbalancers, beveiligingsoplossingen en alle andere pakketten die op het knooppunt zijn geïnstalleerd. Voor alle systeempakketten is de oplossing om ze te upgraden met behulp van standaardmethoden (apt, yum). Als het gaat om de databases en loadbalancers, wordt ClusterControl geleverd met functionaliteit waarmee u de kleine versie-upgrade rechtstreeks vanuit de gebruikersinterface kunt uitvoeren.
Laten we aannemen dat de database moet worden bijgewerkt voordat we daarheen gaan. U wilt niet zomaar doorgaan en de upgrade blindelings uitvoeren - dit kan mogelijk problemen veroorzaken voor uw toepassing. Dat zou niet moeten - kleine versies verbreken de achterwaartse compatibiliteit niet (behalve wanneer u MySQL 8.0 gebruikt - ja, dan mag u alles verwachten als u van 8.0.x naar 8.0.x+1 gaat); er is echter altijd enig risico aan verbonden. Wat u eerst moet doen, is de upgrade testen in een aparte omgeving.
We hebben een eenvoudig MariaDB Galera-cluster met ProxySQL en Keepalive:
We willen graag een testcluster bouwen zodat we de upgrade kunnen testen Verwerken. Met ClusterControl is het net zo eenvoudig als het gebruik van Create Replica Cluster-taak:
We kunnen de nieuwe gegevens uit het bestaande cluster halen, of we kunnen de gegevens uit een back-up gebruiken.
We moeten ook een bronknooppunt kiezen in het productiecluster:
Vervolgens moeten we een normale implementatiewizard doorlopen, de versie kiezen en leverancier van de database, het definiëren van het root-wachtwoord, enzovoort. We sluiten af met het doorgeven van de nodes waarop het cluster zal worden geïnstalleerd.
Als resultaat ziet u een nieuw cluster in de lijst met een duidelijk teken dat het van het productiecluster repliceert. Een ding dat het vermelden waard is, in de standaardconfiguratie zal ClusterControl de nieuwste versies van de pakketten gebruiken om het replicacluster te maken. Als u alleen de query's wilt controleren, is dit voldoende. Als u het hele upgradeproces wilt doorlopen, moet u oudere versies van de MySQL-pakketten vastpinnen om een oude versie te installeren (en ze vervolgens losmaken en de upgrade testen).
Op de een of andere manier, na succesvolle tests, wil je uiteindelijk de upgrade uitvoeren. ClusterControl kan u hierbij helpen:
In Beheren -> Upgrades vindt u een gebruikersinterface om de upgrade uit te voeren .
U kunt "Controleren op nieuwe pakketten" gebruiken om de database met beschikbare pakketjes. We kunnen ook kiezen welke nodes we willen upgraden en welke services:
Gewoon bevestigen en dat is alles - ClusterControl voert de upgrade uit en geeft u de laatste versie van de pakketten.
Zoals u kunt zien, maakt ClusterControl het up-to-date houden van uw databases eenvoudig en duidelijk. De enige stap die u handmatig moet uitvoeren, is het juiste testen. Anders - al het andere kan door ClusterControl voor u worden uitgevoerd. Wilt u meer weten over hoe ClusterControl u kan helpen uw database effectief te beheren? Probeer het 30 dagen gratis.