Remediați erorile de migrare a bazei de date Kopano după o actualizare a versiunii MySQL

O eroare de migrare a bazei de date Kopano imediat după o actualizare a versiunii MySQL sau MariaDB înseamnă de obicei că aplicația și baza de date nu mai sunt de acord în privința a ceva ce era implicit: starea schemei, valorile implicite ale serverului, comportamentul SQL, autentificarea sau calea de actualizare în sine. Scopul util nu este pur și simplu de a face kopano-serverun start once. Scopul este de a ajunge la o stare în care schema este consistentă, Kopano pornește fără erori de actualizare a bazei de date, utilizatorii pot deschide magazine, iar fluxul de e-mailuri supraviețuiește unei reporniri.

Acest ghid se concentrează pe dovezi. Fiecare etapă include un semnal de succes și un punct în care ar trebui să încetați să mai încercați aceeași soluție și să schimbați direcția. Documentația administratorului public Kopano este mai veche decât versiunile actuale de MySQL și MariaDB, așa că nu presupuneți că fiecare versiune modernă a bazei de date este acceptată de fiecare versiune istorică a Kopano. Folosiți versiunea exactă a pachetului Kopano, furnizorul bazei de date și eroarea serverului ca dovezi decisive.

Începeți cu rezultatul de care aveți nevoie

Înainte de a modifica configurația, definiți ce înseamnă „reparat”. O recuperare sănătoasă are în mod normal toate aceste semne:

• kopano-serverpornește și rămâne în funcțiune după repornirea serviciului.
• Jurnalul Kopano nu mai raportează o actualizare a schemei bazei de date sau o eroare de execuție SQL.
• Baza de date poate fi citită și scrisă de contul Kopano configurat.
• Magazinele și utilizatorii existenți sunt vizibili, nu o schemă goală nou creată.
• Trimiterea și livrarea corespondenței se reiau normal.
• O a doua repornire produce același rezultat sănătos.

Dacă ați atins doar primul element, continuați testarea. O pornire temporară după modificarea sql_mode, de exemplu, nu dovedește că schema de bază este corectă.

1. Opriți scriitorii Kopano și faceți o copie de rezervă a bazei de date restaurabilă

Documentația de actualizare Kopano recomandă crearea unei copii de rezervă a bazei de date și a fișierelor de configurare și oprirea serviciilor care utilizează baza de date înainte de lucrările de actualizare. Documentația menționează în mod specific oprirea kopano-spoolerși kopano-server, plus componentele opționale care rulează. Consultați documentația de actualizare Kopano Core .

sudo systemctl stop kopano-spooler
sudo systemctl stop kopano-server

mysqldump -u root -p --single-transaction kopano > /root/kopano-before-fix.sql
ls -lh /root/kopano-before-fix.sql

Pentru o instalare mare, păstrați și /etc/kopano/, notați locația de stocare a atașamentelor și urmați politica existentă de copiere de rezervă a bazei de date. Dacă atașamentele sunt stocate în afara MySQL, un dump SQL în sine nu este o copie de rezervă Kopano completă.

Opriți serviciile Kopano care scriu în baza de date și verificați dacă există o imagine de memorie nouă înainte de a modifica schema sau setările serverului.

Semnal de succes: aveți o copie de rezervă care poate fi restaurată într-o instanță separată a bazei de date și știți unde sunt stocate atașamentele externe. Schimbați abordarea dacă: dump-ul în sine eșuează. Remediați coruperea bazei de date, permisiunile, spațiul pe disc sau conectivitatea înainte de a încerca o migrare a schemei Kopano.

2. Înregistrați versiunea exactă a bazei de date și setările implicite modificate

O actualizare majoră MySQL poate modifica setările implicite ale serverului fără a modifica tabelele existente. MySQL 8.0, de exemplu, a modificat setul de caractere implicit al serverului la utf8mb4și colaționarea implicită la utf8mb4_0900_ai_ci. De asemenea, a modificat alte setări implicite și a eliminat sau a depreciat comportamentul mai vechi. Oracle documentează aceste diferențe în Changes in MySQL 8.0 .

Capturați starea reală a serverului în loc să presupuneți ce a făcut actualizarea pachetului:

mysql -u root -p

SELECT VERSION();
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

Înregistrați versiunea bazei de date și valorile implicite pe care Kopano le vede acum; aceste valori ajută la explicarea erorilor care au apărut doar după actualizarea bazei de date.

Nu dezactivați imediat modurile SQL stricte. O eroare de tip strict-mode poate dezvălui date vechi sau SQL nevalide care trebuie corectate. Dezactivarea modului strict poate ascunde simptomul, lăsând în urmă date care eșuează ulterior. Mai întâi, capturați instrucțiunea sau eroarea de bază de date exactă care a eșuat din jurnalul Kopano.

3. Citiți prima eroare SQL, nu doar eroarea finală a serviciului

Systemd afișează adesea doar ce kopano-servers-a terminat. Linia utilă este de obicei mai devreme în jurnal sau în jurnalul Kopano. Începeți cu:

journalctl -u kopano-server -n 100 --no-pager

Apoi clasificați defecțiunea. Tabelul următor este o hartă practică de triaj, mai degrabă decât o afirmație că o singură cauză se aplică fiecărei instalații.

Jurnalul de modificări al versiunii Kopano confirmă faptul că unele versiuni au introdus modificări de schemă care au necesitat kopano-dbadmoperațiuni specifice. De asemenea, înregistrează defectele istorice de actualizare a bazei de date, inclusiv erorile care implică definiții vechi de tabele MySQL și actualizări utf8mb4. Folosește jurnalul de modificări Kopano Core pentru a potrivi acțiunea de întreținere cu versiunea ta exactă de Kopano.

4. Comparați schema Kopano existentă cu noile setări implicite ale serverului

Verificați schema așa cum există; valorile implicite ale serverului nu vă spun cât de vechi sunt definite tabelele Kopano.

SHOW CREATE DATABASE kopano;
SHOW TABLE STATUS FROM kopano;

Inspectați definiția bazei de date Kopano existente și motoarele de stocare, păstrând în același timp eroarea originală de migrare vizibilă pentru comparație.

Dacă baza de date a fost creată inițial pe o versiune mai veche de MySQL, tabelele sale pot păstra seturi de caractere mai vechi, chiar dacă obiectele nou create au acum set implicit de caractere utf8mb4. MySQL precizează explicit că actualizarea de la versiunea 5.7 la 8.0 nu convertește automat obiectele existente ale bazei de date la noul set implicit de caractere. Această distincție este importantă: o migrare poate eșua atunci când se creează o coloană sau un index nou cu valori implicite diferite de cele ale obiectelor vecine.

Kopano a adăugat suport pentru utf8mb4 în versiunile Core ulterioare și a documentat un pas specific de întreținere a bazei de date, kopano-dbadm usmp, pentru actualizarea bazelor de date existente pentru suport Unicode pe 4 octeți. Nu executați această comandă doar pentru că MySQL are acum implicit utf8mb4; executați-o numai atunci când documentația versiunii Kopano instalate sau ieșirea serverului o solicită.

5. Dacă MariaDB a fost actualizată, finalizați mai întâi actualizarea pe partea MariaDB

Dacă backend-ul dvs. este MariaDB în loc de Oracle MySQL, finalizați procedura de actualizare a serverului de baze de date înainte de a da vina pe Kopano. MariaDB este documentată mariadb-upgradeca instrument care actualizează tabelele de sistem și verifică tabelele după modificările versiunilor majore. Documentația sa recomandă mai întâi copierea de rezervă a tuturor bazelor de date. Consultați referința oficială mariadb-upgrade .

Aceasta este o ramificare, nu o comandă universală. Nu rulați mariadb-upgradeîmpotriva Oracle MySQL. În schimb, nu aplicați presupuneri MySQL 8.0 unui server MariaDB doar pentru că ambele acceptă mysqlprotocolul client.

6. Verificați dacă contul bazei de date Kopano are încă privilegiile necesare

Manualul de administrare al Kopano precizează că serverul are nevoie de permisiuni, inclusiv ALTER, CREATE, CREATE ROUTINE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, și UPDATEasupra bazei de date Kopano. Parametrii de conectare la baza de date sunt configurați prin intermediul setărilor legate de MySQL din /etc/kopano/server.cfg. Consultați Configurarea componentelor KC .

După o migrare a unei versiuni MySQL, un administrator poate recrea utilizatori, modifica pluginurile de autentificare, muta gazda bazei de date sau restaura incomplet permisiunile. Testați același nume de gazdă și același cont pe care le folosește Kopano. Dacă autentificarea eșuează înainte de executarea oricărei migrații SQL, remediați mai întâi problema contului sau a permisiunii.

7. Reparați doar starea dovedită de eroare

În acest moment ar trebui să aveți o clasă de cedare a betonului. Aplicați cea mai mică modificare care o explică:

• Actualizare parțială a schemei Kopano: urmați instrucțiunile de actualizare Kopano specifice versiunii sau kopano-dbadmcele identificate de versiunea instalată. Nu ștergeți niciodată un marker de versiune și nu adăugați manual coloane doar pentru a executa următoarea instrucțiune.
• Nepotrivire între setul de caractere sau colaționare: identificați mai întâi tabelul și coloana afectate. Planificați conversiile pe baza unei copii restaurate înainte de a trece la producție, deoarece modificările setului de caractere pot altera dimensiunile indexului și comportamentul de comparare.
• Nepotrivire tabelă sistem MariaDB: finalizați procedura documentată de actualizare MariaDB, apoi încercați din nou Kopano.
• Permisiuni sau autentificare: corectați contul Kopano DB și verificați o autentificare de la gazda Kopano.
• Combinație de versiuni neacceptată: opriți experimentele de configurare. Restaurați mediul bazei de date pre-actualizare sau treceți la o combinație Kopano/bază de date acceptată de furnizorul sau sursa pachetului.

Ultimul caz este important. Manualul de administrare Kopano Core, accesibil publicului, provine dintr-o generație mai veche de produs, în timp ce versiunile actuale de MySQL și MariaDB au continuat să se modifice. Dacă nu găsiți o declarație de suport pentru perechea exactă, lipsa documentației nu ar trebui interpretată ca fiind compatibilitate.

8. Porniți Kopano și validați mai mult decât starea procesului

sudo systemctl start kopano-server
sudo systemctl start kopano-spooler

systemctl --no-pager --full status kopano-server
journalctl -u kopano-server -n 50 --no-pager

O stare sănătoasă a serviciului este necesară, dar nu suficientă; examinați jurnalul de pornire și apoi validați depozitele utilizatorilor și fluxul de e-mailuri.

După ce serviciul rămâne activ, testați comportamentul cu aplicația reală. Deschideți cel puțin o cutie poștală existentă, verificați dacă există foldere și mesaje vechi, trimiteți un mesaj între două conturi locale, trimiteți un mesaj de ieșire și confirmați că livrarea la intrare funcționează. Dacă utilizați IMAP, ActiveSync, arhivare, componente multi-server sau stocare externă a atașamentelor, exersați și acele căi.

Când ar trebui să schimbi abordarea?

Opriți repetarea modificărilor de schemă atunci când apare oricare dintre aceste condiții:

• Eroarea SQL se modifică după fiecare modificare manuală, sugerând o schemă migrată parțial.
• Baza de date restaurată înainte de actualizare funcționează pe vechea versiune a bazei de date, dar eșuează constant pe cea nouă.
• Nu poți stabili dacă versiunea ta Kopano este compatibilă cu versiunea majoră instalată de MySQL sau MariaDB.
• Verificările tabelelor raportează coruperea mai degrabă decât o incompatibilitate normală a schemei.
• O conversie a setului de caractere ar necesita modificarea multor tabele mari fără o rollback testată.

În aceste cazuri, calea mai sigură este adesea recrearea mediului anterior al bazei de date, restaurarea copiei de rezervă cunoscute ca fiind validă și planificarea unei actualizări în etape într-o clonă. Oracle notează că downgrade-ul MySQL 8.0 la 5.7 nu este acceptat în mod standard; alternativa acceptată este restaurarea unei copii de rezervă efectuate înainte de actualizare. Consultați notele de lansare MySQL 8.0 .

Lista de verificare finală

• Copia de rezervă a bazei de date și copia de rezervă a configurației Kopano sunt păstrate.
• Versiunea exactă de MySQL sau MariaDB este înregistrată.
• Prima eroare SQL reală a fost identificată și explicată.
• Nu a fost aplicată nicio soluție alternativă generală pentru modul SQL sau setul de caractere fără dovezi.
• Întreținerea schemei Kopano necesară corespunde versiunii Kopano instalate.
• kopano-serversupraviețuiește unei a doua reporniri.
• Cutiile poștale, folderele și mesajele existente sunt intacte.
• Testele de livrare inbound, outbound și locală au reușit.
• Componentele opționale utilizate de mediul dvs. au fost testate.

O problemă de migrare a bazei de date este rezolvată atunci când schema, serverul bazei de date și versiunea Kopano coincid din nou - nu atunci când mesajul de eroare a dispărut pur și simplu. Păstrați dovezile care au dus la reparare, deoarece acestea sunt și informațiile de care veți avea nevoie pentru următoarea actualizare a bazei de date sau a Kopano.