MySQL 8.x Opgradering

April 14, 2024

Waar begin 'n mens om 'n projek te beskryf wat maande geneem het vir iets wat veronderstel is om eenvoudig te wees? Dit is 'n reis wat gesorg het vir opwinding, uitdagings, gekners van tande en het verseker 'n mens se deursettingsvermoë getoets.

Don't understand Afrikaans? See the English version :)

'n Jaar se werk afgehandel

Wel, meestal. Hierdie was voorwaar 'n riller van 'n projek en ek het nie gedink dit gaan ooit só lank neem nie. Iewers in April 2023 het dinge verander in die span en skielik bevind ek myself in die posisie om 'n taak te verrig wat kennis benodig in 'n area wat nooit een van my sterker punte was nie. In my studies ná skool was die databasis module die enigste wat ek moes her. Hier vind ek myself in April 2023 aan die diep kant ingegooi om myself databasis administrateur te hou.

Dit was 'n uitmergelende proses, maar daar is nou geen terugkeer nie. Op 11 April 2024 het alles 'n hoogtepunt bereik en het die kliënt se data op die MySQL 8.0.36 primêre instansies begin werk. Die spreekwoordelike Rubikon is oorgesteek.

Daar is net te veel om in 'n plasing te sit, ek kan amper 'n boek skryf! Die idee was eenvoudig. Opgradeer 'n MySQL 5.7 databasis na MySQL 8.0.x. Die besonderhede wat ontbreek is al die afhanklike komponente wat in die platvorm se ekosisteem is, asook hoe lank die platvorm aan die gang is, en hoeveel onderhoud agterweë gebly het, en hoe goed, of op datum die dokumentasie gehou is.

MySQL 8.0

Die eerste ontwikkelings weergawe van MySQL 8.0.0 was vrygestel in 2016 (2016-09-12) en die eerste algemene beskikbare weergawe, 8.0.11, in 2018 (2018-04-19). Die nuutste stabiele weergawe wat deur AWS ondersteun word, is 8.0.36. Dus het daar heelwat ontwikkeling agter die skerms gebeur.

D.w.s. die poging om op te vang het eers vyf jaar later begin, en het op die ou-end 'n jaar geneem. Daar sal altyd vinger gewys word om te se dit of dat is die rede dat die proses moeiliker was of dat dit makliker sou wees indien platvorm dokumentasie op datum gehou was en al die hindernisse minder van 'n probleem sou wees. Maar hoe dit nou ook al sy, dit moes gebeur en ons het met groot deurnis die tog aangepak.

Kort voor lank sal so 'n projek weer aangepak moet word, in 2026, volgens die Oracle MySQL Blog.

Verkenning van die oerwoud

Aanvanklik was die grootste uitdaging om uit te vind wat presies in die hele databasis aangaan. Skemas, tabelle, entiteit-relasies, karakter en versameling stelle.

Met tyd was daar nuwe kolomme aangebring, nuwe tabelle en relasies, en die dissipline om seker te maak dat alles redelik dieselfde bly het ontbreek. Sekerlik het onkunde ook 'n rol te speel en 'n gebrek aan ervaring, veral as 'n mens aan die diep kant ingegooi word om iets op datum te bring wat deur persone aangeraak is wat lankal aanbeweeg het. Wie kan jy vra of dit wat jy wil doen reg of verkeerd is? Veral as Internet soektogte jou in situasies los waar dit lyk of jy die enigste een is wat 'n spesifieke probleem het!

In die geval van die tegnologie stapel is daar 'n lang storie wat verskeie tale insluit. Dit blyk dat aan die begin Microsoft .Net vir die platform gebruik was. Later het sommige van die dienste aanbeweeg na PHP, maar dele het agter gebly. Nóg later het daar weer dele van die PHP aanbeweeg na JavaScript op NodeJS. Wéér bly dele agter. Sommige koppelvlak-roepe gaan deur vier stapels vir een funksie! Sommige prosesse praat direk met die databasis, óf in NodeJS kode, óf in PHP. Ander prosesse praat deur NodeJS met PHP wat dan met die databasis kommunikeer. Die punt is dat al hierdie stapels op die ou-end met dieselfde databasis kommunikeer en almal moet versoenbaar wees.

Daar is swaar geleun op die interne vermoëns van MySQL, soos snellers, funksies en gestoorde prosedures. Die kennis en wysheid van die aanvanklike argitekte het met tyd heengegaan en dit was nie opgeneem in enige vorm wat opgespoor kon word nie. Dit beteken dat die hele proses met baie moeite en onsekerheid aangepak is. In my loopbaan het ek geleer dat databasisse die beste is wanneer dit gebruik word om die data te stoor. Verwerking en rapportering geskied dan deur middel van verwerking buite die databasis. Dit beteken nie dat sulke funksionaliteit gladnie gebruik moet word nie, maar dit moet nie misbruik word nie. Wat hier ter sprake is, is dat baie kennis van die data-domein buite kode leef, in 'n unieke wêreld, ver weg van die bronkode en weergawe-bestuur. Ek reken enige sagteware ontwikkelaar of argitek sal kan uitwys dat dit 'n probleem is. Iets waarmee ons moes saamleef.

Statistieke oorsig

Om 'n idee te kry van die grootte van die projek sal ek 'n paar syfers aandui.

Vir die hoof databasis:

Databasis stoor grootte: ongeveer 335G
Hoof bediener: 1
Naboots of repliserende bedieners: 2
Basis Tabelle: 181
Tabelle as Aansigte (views): 77
Kolomme: 2475
Roetines:
- Funksies: 13
- Prosedures: 427
Snellers: 165
SQL bronkode wat gebruik is vir opgradering: 26305 lyne, waarvan
- 3913 blanko was en
- 946 kommentaar

Oor die tydperk van die projek, het een van die JIRA plekhouers sowat negentig kommentaar inskrywings gehad, om opdaterings en observasies vas te vang.

Hulpbronne

Aan die begin is handmatige verkenning gedoen van die databasis, soos wat ek geleer het waarna om te kyk voordat die opgradering kan begin. Daar is 'n gids saamgestel en genoem in vele plasings aanlyn, wat help om die voorbereiding te doen. Daar is ook opgradering-gereedheids-sagteware wat die teiken databasis onder kruisverhoor neem en inspekteer en dan gee dit 'n verslag van alles wat fout is of 'n probleem kan wees.

Nadat dit later 'n groot projek begin word het, het ek besef dat gereedskap nodig gaan wees. Weens die kritiese belangrikheid van die proses het ek begin om 'n nutsprogram te skryf in 'n taal of tegnologie wat ek met my lewe vertrou - Clojure. Ek het wel met die Babashka dialek daarvan gewerk omdat dit reeds die meeste van die sagteware biblioteke wat ek nodig het, bevat. Ja ek weet dit is 'n unieke keuse gewees, maar soos ek sê, ek vertrou dit met my lewe. En ek het uitdagings gehad wat ek gevoel het veel moeiliker sou wees om in ander tale en tegnologie te doen.

Die konsep is dat ek gespesialiseerde vergelykings begin doen het tussen produksie en toets databasisse en dit raak redelik gekompliseerd. Ek wil aan beide databasisse tegelyk koppel en dieselfde tipe data wat van albei kom vergelyk, sonder om heeltyd te wissel tussen die een en die ander.

Daar is seker alleenstaande programme wat dit kan doen, maar ek was nie op hoogte daarvan nie, en dit beteken ek sou my aandag eers elders moet fokus om weer dáárdie sagteware te leer, en dan weet ek steeds nie of ek dit vertrou nie.

Probeer en probeer weer

Vroeg al het dit duidelik geword dat daar baie uitdagings gaan wees met soveel wat verkeerd kan loop of data wat skade kan ly en dan is daar groot moeilikheid. Die druk was hewig op my skouers, bloot omdat dit so belangrik is om reg te doen.

Vanweë die volume van die data het dit 'n baie tydsame proses geraak. Ek praat nie van 'n uur of twee nie. Dit het dae geneem. Nader aan die einde sou die proses van begin tot einde so twee na drie dae neem as absoluut alles perfek in plek val. Dit het gehelp om groter verwerker instansies te gebruik, maar kostes moes ook onder beheer bly.

Tydlyne en verrassings

Teen Desember 2023 het ons die gebruikers-aanvaarding toets omgewing (UAT) oorgeskakel van MySQL 5.7.x na MySQL 8.0.28 en was opgewonde om naby te wees aan die punt om produksie ook oor te skakel! Aanvanklike toetse in die toets omgewing het belowend gelyk en daar was begin om die nuwe produksie replikasie instansies voor te berei. En natuurlik moes dit gebeur dat die ondersteuningstydperk baie vinning nader kom... In Januarie 2024 moes ons begin bepaal waar ons gaan opeindig, en of dit 'n probleem gaan word: AWS gaan begin om ekstra tariewe te vra vir verlengde ondersteuning, en ons weet nie of die oorskakeling vlot sal verloop nie!

Om alles operasioneel te hou moes ons na MySQL 5.7.44 opgradeer sodat daar nie 'n outomatiese opgradering na 8.0.x gepoog word nie. Dit het belanghebbendes ongemaklik laat begin rondskuif omdat ons 'n paar uur se onderbreking nodig sou hê om daardie spesifieke opgradering te doen. Maar ons het dit gedoen en met die weergawe op 5.7.44 was dit 'n veiligheidsnet wat vir ons tyd kon gee om seker te maak dat die voorbereiding vir 8.0.28 so goed as moontlik gedoen word.

Nóg nader aan die punt om oor te skakel begin ons huiswerk doen oor wanneer die volgende opgradering vanaf AWS se kant aangehits sal word, en o wee, 8.0.28 se einde is vroeg in 2024! Tesame met hierdie nuus het ons ook agter gekom dat daar 'n nuwe uitdaging gaan wees.

Microsoft .Net

Van die ouer deel in die platform is in C# geskryf en werk op Windows met .Net. Vir Java is daar MySQL Connector/J, en vir .Net is daar Connector/NET. Windows en .Net is heeltemal buite my gemaksone en ek het probeer verstaan sover as wat ek kan. Maar met al die ander goed reeds in my kop kon ek net nie 'n paradigma skuif maak om OOK .Net te bemeester nie. Gelukkig kon ons 'n oud-kollega aanspoor om te help en hy het ingestem om die .Net deel te inspekteer.

Daar was 'n plan om die .Net platvorms op te gradeer nadat die databasis opgradering voltooi is. Dit het 'n punt bereik waar dit duidelik geword het dat meer probleme opgelos sal word deur die Windows bedieners met die .Net platvorm op te gradeer voordat ons poog om verder te gaan met die databasis opgradering.

Die groot rede vir hierdie spesifieke Connector/NET opgradering was omdat die ouer .Net nie met MySQL 8.0.36 kon praat nie, en dit is 'n groot probleem. Verder is daar ook 'n bepaalde deel waar die .Net deel na beide 5.7.44 en 8.0.36 databasisse moes kan kommunikeer. Dit was ononderhandelbaar.

Op hierdie punt is daar al soveel afdraai paadjies geneem dat dit moeilik is om kop te hou met alles wat al gebeur het, en wat nog moet gebeur. Maar ons gaan voort. Een van die eerste bedieners wat George in 2016 op die been gebring het deur KliekOps, is vervang met CloudFormation. Ek is trots dat ek iets kon vervang wat deur 'n mentor opgestel was. Ons het 'n ver pad gestap om te leer hoe om dinge op die regte manier te doen. Ek het baie geleer, en steeds is daar baie om te leer.

Die Rubikon

Die laaste paar dae voor D-dag was alles vol voorbereiding, beplanning, na-gaan, instellings, verstellings, seker-maak en geselsies om seker te maak alles is gereed en in orde. Daar was take wat ons voor die tyd kon doen, sodat daar minder op een slag of op die dag moes gebeur, en ek is bly ons het dit eerder só gedoen!

Die dag van die oorskakeling was uitmergelend. Soveel punte om weereens na te gaan en om kop te hou met die juisste prosesse van die dag. Die oorskakeling het ons ongeveer vier ure geneem, en alles het meestal goed verloop. Daar was haakplekke wat ons verder in die res van die dag in geneem het, maar dit was minder krities en gelukkig was daar nie 'n nood terug-rol nodig nie. Soveel omgee, fokus en harde werk was toegepas, dat só 'n terugslag my waansinnig sou maak!

Daar is nog rowwe dele wat uitsorteer moet word, maar dit was suksesvol, en die kliënt hoef nie meer verlengde ondersteuning tariewe te betaal aan AWS nie.

Ten Slotte

Hierdie was beslis 'n formidabele uitdaging, maar daardeur het ek baie geleer in verskeie areas. Ou spinnerakke is weggevee en die ou rakke in my geheue is afgestof! AWS RDS maak dit regtig veel maklikker om gemoedsrus te hê oor die data wat gestoor word.

Met die volume van data wat bestuur moes word, sou dit 'n baie moeilike taak gewees het op lokale bedieners.