Managementul schemelor cu Skeema

Notă: această postare vine de la echipa de inginerie a SendGrid. Pentru mai multe postări de inginerie tehnică ca aceasta, consultați blogrollul nostru tehnic.

Gestionarea schemei bazei de date variază de la un vest sălbatic, oricine poate „fa-o ​​în direct” în procesul de producție până la un proces de revizuire în mai mulți pași, în mai multe echipe, în care doar un singur individ poate atinge baza de date de producție.

Pe măsură ce datele conținute în bazele de date relaționale devin mai valoroase pentru o companie și disponibilitatea bazei de date devine mai importantă pentru afacere, apar bariere în calea potențialelor modificări ale schemei.

La început, administratorii de baze de date (DBA) au devenit gardienii bazei de date pentru a proteja baza de date de lucruri rele. Dar existența unui DBA vechi între dezvoltatori și baza de date a aplicației lor poate provoca o încetinire semnificativă a ciclului de viață al dezvoltării unei aplicații, poate crea silozuri de dezvoltare și operațiuni și poate genera fricțiuni între echipe.

În lumea de astăzi orientată către dezvoltarea de microservicii, dezvoltatorii trebuie să fie capabili să gestioneze singuri modificările schemei bazei de date, deoarece sunt datele lor și sunt responsabili în ultimă instanță pentru performanța și timpul de funcționare a aplicației. DBA și echipele de operațiuni trebuie să ofere instrumente și sfaturi adecvate pentru a ajuta echipele de dezvoltare să devină proprietarii bazei de date.

Cum gestionăm schema

Procesul nostru actual de gestionare a schemei folosește un singur depozit Git pentru a stoca schema inițială pentru toate clusterele noastre de baze de date și conține toate modificările ulterioare ale acelei scheme pe măsură ce tabelele individuale sunt modificate/create și eliminate:

• Un dezvoltator efectuează o modificare de schemă la nivel local și generează o instrucțiune de modificare/creare/eliminare și o adaugă ca cerere de extragere la o ramură de integrare.
• Un set de tichete Jira pentru echipa de operațiuni de date sunt create pentru a revizui și aplica modificările schemei în mediile noastre de testare/proiectare și producție.
• Un membru al echipei Data Operations analizează modificarea solicitată și aplică modificarea mediului de testare/staging și unește PR cu ramura de integrare.
• Dezvoltatorul solicitant testează modificarea în mediile noastre de testare/proiectare și aprobă modificarea care urmează să fie împinsă în producție.
• În cele din urmă, Data Operations îmbină ramura de integrare pentru a stăpâni și aplică modificarea schemei mediului de producție.

Având în vedere valoarea datelor stocate în bazele noastre de date și dorința de a avea acele baze de date funcționale bine tot timpul, ne-am hotărât pe această secvență bizantină de evenimente pentru a ne proteja de noi înșine.

Protejarea bazei de date este un lucru, dar acest proces introduce mai multe obstacole pentru a face modificări de schemă într-un mod fiabil și eficient:

• Revizuirea și efectuarea modificărilor de schemă se întâmplă cu o cadență de două ori pe săptămână și poate fi ușor deraiată, deoarece mai multe echipe lucrează pe baze de date diferite, toate în același depozit Git și toată lumea se bazează pe cineva din echipa de operațiuni de date pentru a revizui și a face modificări în diferite medii.
• A avea un singur depozit pentru toate schemele de baze de date relaționale poate duce la procese de lansare dificile. O modificare a unei scheme care este pregătită pentru producție nu poate trece în producție dacă există alte modificări de schemă care nu sunt gata să fie împinse în producție, dar care stau în scenă în așteptarea unor teste suplimentare.
• Echipa Data Operations, care este o echipă mică, devine un blocaj în încercarea de a gestiona ce schimbare poate sau nu trece în producție și când. Conflictele de programare și disponibilitatea personalului pot încetini cu adevărat lansarea de noi funcții sau remedieri pentru aplicațiile curente.
• Aplicăm manual aceste modificări sistemelor de producție folosind comentarii în cererile de extragere și biletele Jira; uneori, copy paste poate merge îngrozitor de greșit.

Intră Skeema (și câțiva ajutoare)

Pentru a elimina aceste obstacole de proces, pentru a face modificările de schemă mai puțin predispuse la erori umane, pentru a permite dezvoltatorilor să gestioneze propria schemă a aplicației și, potențial, pentru a crește viteza de dezvoltare, echipa de operațiuni de date a depus mult efort în automatizarea și eficientizarea gestionării schema bazei de date.

Am automatizat aplicarea modificărilor de schemă de la dezvoltarea locală la producție folosind instrumentele noastre existente, Git, Buildkite CI și pt-online-schema-change, cu adăugarea a încă una, Skeema.

Ideea este să împărțim depozitul nostru monolitic de schemă DB în depozite de schemă individuale, câte unul pentru fiecare cluster de baze de date și să le permitem dezvoltatorilor să facă propriile modificări de schemă într-un mediu care le este familiar. De asemenea, dorim să avem balustrade sănătoase pentru a ajuta dezvoltatorii să caute asistență suplimentară pentru a efectua modificări de schemă mari, complexe sau potențial distructive.

Skeema este un instrument CLI care gestionează schema MySQL într-un mod declarativ folosind SQL.

Poate genera limbajul de definire a datelor (DDL) pentru fiecare tabel dintr-o bază de date și poate exporta DDL într-un sistem de fișiere local pentru integrare cu un depozit de urmărire prin Git. Skeema poate compara fișierele SQL dintr-un depozit Git cu o bază de date MySQL live și poate scoate aceste diferențe ca instrucțiuni DDL.

De asemenea, poate fi configurat să utilizeze instrumentul pt-online-schema-change de la Percona și să formateze comanda necesară pt-online-schema-change pentru a potrivi schema bazei de date MySQL care rulează cu schema definită în depozitul Git.

Skeema este, de asemenea, capabil să gestioneze schema în mai multe medii, cum ar fi local, testare și producție, cu configurații diferite în fiecare. Și, în sfârșit, poate fi adaptat cu ușurință la un flux de lucru bazat pe pull request.

Crearea de depozite individuale de scheme de baze de date MySQL va descompune depozitul nostru monolitic Git cu schemă db și va permite dezvoltatorilor din echipe separate să gestioneze schema MySQL a aplicației lor în propriul depozit în loc de un depozit partajat (db-schema).

Având un depozit separat pentru fiecare schemă de bază de date va permite o mai mare autonomie echipei de dezvoltare a aplicațiilor. Acest lucru elimină necesitatea de a coordona toate modificările schemei într-un program rigid și permite ca modificările să fie mutate în producție după cum dorește echipa aplicației.

O componentă vitală a automatizării acestui proces este conducta CI a Buildkite. Am creat o conductă care:

• Verifică erorile de sintaxă SQL
• Creează un server MySQL de testare folosind ramura principală curentă a schemei bazei de date și testează aplicarea modificărilor în cererea de extragere (PR)
• Verificați diferențele și aplicați modificările PR în mediul nostru de testare MySQL
• Verificați diferențele și aplicați modificările PR în mediul nostru de pregătire și scoateți câteva statistici de tabel din mediul de producție

Statisticile de producție sunt dimensiunea tabelului pe disc și numărul estimat de rânduri. Aceste statistici pot ajuta la determinarea dacă modificarea schemei poate cauza un anumit nivel de întrerupere a serviciului și ar putea necesita o gestionare specială. Odată ce PR este fuzionat cu master, conducta buildkite verifică diferențele dintre ramura principală și ceea ce rulează în producție.

Dacă diferențele sunt schimbările așteptate din PR, dezvoltatorul poate debloca acest pas final și Skeema aplică modificări clusterului de baze de date MySQL de producție. Fiecare dintre acești pași este un pas de blocare care necesită aprobarea echipei de inginerie responsabilă pentru modificarea solicitată înainte de a trece la pasul următor.

În ceea ce privește balustradele, am configurat Skeema să nu permită modificări distructive ale schemei în producție ca implicită.

Modificările distructive sunt permise în mediile noastre de testare și pregătire.

De asemenea, am configurat Skeema să folosească pt-online-schema-change pentru a face modificări de schemă. Acesta este același instrument de schimbare a schemei cu care este familiarizată echipa DataOps și a fost folosit la SendGrid de mulți ani. Am dezvoltat un set de opțiuni rezonabile pentru ca pt-online-schema-change să-și anuleze modificările dacă replicarea rămâne în urmă sau firele active din baza de date devin excesive.

Configurarea Skeema în acest fel elimină potențialele erori de a avea pași manuali pentru aplicarea și codarea manuală a comenzilor pt-online-schema-change de către membrii echipei DataOps.

Odată cu adăugarea de balustrade programatice, echipele individuale pot fi responsabile pentru gestionarea schemelor lor de baze de date MySQL și aplicarea acelor modificări în mediile de pre-producție și producție cu o siguranță relativă. Dacă balustradele sunt lovite, schimbarea schemei va eșua și este anulată. Motivele pentru eșecul modificării schemei sunt trimise în jurnalele de compilare pentru o revizuire suplimentară.

Permiterea dezvoltatorilor să-și conducă modificările de la testarea locală pe un laptop la producție sporește considerabil autonomia dezvoltatorului și proprietatea asupra bazei de date care le susține aplicația. Automatizarea și integrarea Skeema în procesul nostru de gestionare a bazei de date MySQL acoperă cu ușurință aproximativ nouăzeci la sută din sarcinile noastre generale de gestionare a modificării schemei.

Cele mai multe modificări ale schemei sunt pentru adăugarea de coloane, modificarea câmpurilor de enumerare, modificarea valorii implicite și adăugarea de indici. Restul de zece procente din modificările de schemă se ocupă de cazuri speciale de tabele mari, baze de date foarte active sau tabele partiționate. Începând cu această postare, Skeema nu se ocupă încă de efectuarea modificărilor de schemă la tabelele partiționate, dar am auzit că este o adăugare adesea solicitată și dezvoltatorul Skeema solicită în mod activ ajutor pentru implementarea acestei caracteristici.

Combinarea Git, pt-online-schema-change, Skeema și o conductă Buildkite CI aduce un proces fiabil, repetabil, programatic modificărilor schemei bazei de date MySQL. Le permite dezvoltatorilor să gestioneze în siguranță schema bazelor de date și să controleze cât de rapid sunt implementate funcțiile și corecțiile în producție.

Includerea balustradelor adecvate în fișierele de configurare pentru Skeema și modificarea schemei pt-online, oferă o măsură de încredere pentru dezvoltatorii care implementează modificări ale schemei și oferă feedback valoros cu privire la modalitățile posibile de a proceda cu schimbarea schemei dacă acele balustrade sunt lovite.

Echipa de operațiuni de date rămâne disponibilă pentru a-i ajuta pe cele zece procente rămase din cazuri la care acest proces nu poate fi aplicat și va lucra la instrumente suplimentare pentru a îmbunătăți acest proces în viitor.