"Håll din databas uppgraderad till den senaste versionen - det är för din säkerhet" är något du ofta hör som goda råd och bästa praxis när det kommer till databashantering. Å andra sidan kan det vara en tidskrävande uppgift att uppgradera din databas. Även en mindre versionsuppgradering kräver att du noggrant testar uppgraderingen i en uppgraderingsmiljö innan du uppgraderar din produktionsinställning. Så vad är grejen? Om du bara släpar efter en mindre version, borde det inte spela någon roll, eller hur? Tja, det kanske inte...förrän det gör det. Och är du verkligen beredd att ta den typen av risk?
Tidigare i år identifierades en ny potentiellt farlig sårbarhet i Galera Cluster (CVE-2021-27928). Vid första anblicken ser vi att svårighetsgraden markerades som hög, och när vi börjar gräva vidare i frågan ser det verkligen allvarligt ut. Det verkar som att en SUPER-användare kan exekvera vilken godtycklig kod som helst genom att ändra variablerna wsrep_provider och wsrep_notify_cmd under körningen. Det låter användaren ladda .so-biblioteket och peka mot ett skript som servern kommer att köra. Som du kan föreställa dig är detta inte en bra situation. Visst, du måste ha tillgång till SUPER-användaren, och du skulle behöva ha något tillgängligt för att köra på databasnoden, men det faktum att Galera kan konfigureras för att exekvera godtycklig kod som en 'mysql'-användare är dåligt nog på dess egen.
Som vanligt, i fall som dessa, har korrigeringarna skapats och nya versioner av programvaran, opåverkade av sårbarheten, har pushats. Det här specifika problemet har åtgärdats i MariaDB 10.5.9, 10.4.18, 10.3.28 och 10.2.37, samt Percona XtraDB Cluster 5.6.51-28.46, Percona XtraDB Cluster 5.7.33-31.49 och PerconaDB Cluster 8.0.22-13.1. Allt verkar vara tillbaka till det normala. Visst?
Fel. Det finns otaliga system som körs i produktion som ännu inte har uppgraderats till den nya, opåverkade versionen. Severalnines supportteam är i kontakt med många databasmiljöer i naturen, och vi arbetar ständigt med potentiella kunder för att hjälpa dem migrera till en miljö som hanteras av ClusterControl. Vi ser alla typer av MySQL (och inte bara MySQL) som körs i föråldrade versioner, ibland även versioner som har nått End Of Life och inte längre får säkerhetsuppdateringar. Så borde inte vara fallet, särskilt om du är en ClusterControl-användare.
ClusterControl kommer med en uppsättning funktioner som hjälper dig att hålla dig uppdaterad med alla säkerhetskorrigeringar. Låt oss ta en titt:
För det första kommer ClusterControl med driftsrapporter, en av dem är paketuppgraderingsrapporten:
Precis som alla ClusterControls driftsrapporter kan paketuppgraderingsrapporten schemaläggas till att utföras regelbundet och sedan levereras via e-post. Den kommer att innehålla information om paketversionerna installerade på noderna och om det finns någon form av uppgraderingar som bör utföras:
Paketuppgraderingsrapporten presenterar en lista över paket som bör uppdateras för alla databaser, lastbalanserare, säkerhetsfixar och andra paket installerade på noden. För alla systempaket är lösningen att uppgradera dem med standardmetoder (apt, yum). När det kommer till databaser och lastbalanserare kommer ClusterControl med funktionalitet som låter dig utföra den mindre versionsuppgraderingen direkt från användargränssnittet.
Innan vi går dit, låt oss anta att databasen måste uppdateras. Du vill inte bara fortsätta och köra uppgraderingen i blindo - det kan potentiellt orsaka problem för din applikation. Det borde det inte - mindre versioner bryter inte bakåtkompatibiliteten (förutom när du använder MySQL 8.0 - då ja, du kan förvänta dig vad som helst när du går från 8.0.x till 8.0.x+1); dock finns det alltid en viss risk. Det du bör göra först är att testa uppgraderingen i en separat miljö.
Vi har ett enkelt MariaDB Galera-kluster med ProxySQL och Keepalived:
Vi skulle vilja bygga ett testkluster så att vi kan testa uppgraderingen bearbeta. Med ClusterControl är det lika enkelt som att använda Skapa Replica Cluster-jobb:
Vi kan hämta färska data från det befintliga klustret, eller så kan vi använda data från en säkerhetskopia.
Vi måste också välja en källnod i produktionsklustret:
Då måste vi gå igenom en vanlig installationsguide, välja version och leverantör av databasen, definiera root-lösenord och så vidare. Vi avslutar med att skicka de noder som klustret kommer att installeras på.
Som ett resultat kommer du att se ett nytt kluster på listan med en tydlig markering att den replikerar från produktionsklustret. En sak som är värd att nämna, i standardinställningen kommer ClusterControl att använda de senaste versionerna av paketen för att skapa replikklustret. Om du vill dubbelkolla bara frågorna räcker det. Om du vill gå igenom hela uppgraderingsprocessen måste du fästa äldre versioner av MySQL-paketen för att installera en gammal version (och sedan lossa dem och testa uppgraderingen).
På ett eller annat sätt, efter framgångsrika tester, kommer du så småningom att vilja utföra uppgraderingen. ClusterControl kan hjälpa dig att åstadkomma detta:
I Hantera -> Uppgraderingar hittar du ett användargränssnitt för att utföra uppgraderingen .
Du kan använda "Sök efter nya paket" för att uppdatera databasen med tillgängliga paket. Vi kan också välja vilka noder vi vill uppgradera och vilka tjänster:
Bekräfta helt enkelt och det är allt - ClusterControl utför uppgraderingen och ger dig senaste versionen av paketen.
Som du kan se gör ClusterControl det enkelt och enkelt att hålla dina databaser uppdaterade. Det enda steget som du måste hantera manuellt är korrekt testning. Annars - allt annat kan utföras åt dig av ClusterControl. Intresserad av att lära dig mer om hur ClusterControl kan hjälpa dig att effektivt hantera din databas? Prova det gratis i 30 dagar.