Cum să optimizați în siguranță indexurile bazei de date ownCloud 10

O listare lentă a folderelor ownCloud, o sincronizare întârziată sau un cron job care rulează mult timp pot indica un blocaj al bazei de date, dar adăugarea orbește a indexurilor poate face serverul mai puțin fiabil. În ownCloud Server 10, punctul de plecare sigur este verificarea versiunii exacte și a bazei de date, crearea unei copii de rezervă a instanței, apoi utilizarea doar a modificărilor de schemă documentate pentru versiunea respectivă de ownCloud. Indexurile pot ajuta la căutări și joncțiuni selective; de ​​asemenea, consumă spațiu de stocare și adaugă efort la inserări și actualizări.

Există o distincție importantă între versiuni: referința oficială actuală a comenzilor ownCloud Server 10.16 documentează operațiunile din baza de date, cum ar fi conversia bazei de date, dar nu documentează o db:add-missing-indicescomandă generală de reparare. Comanda respectivă apare în ghidul Nextcloud, care este un produs separat. Verificați comenzile pe propriul server înainte de a rula o comandă copiată dintr-un alt proiect.

Ce poate și ce nu poate corecta un index al bazei de date

Un index al bazei de date este o structură auxiliară care ajută baza de date să găsească rânduri corespondente fără a scana un întreg tabel. Poate îmbunătăți o interogare care filtrează, unește sau sortează pe coloane indexate atunci când interogarea și distribuția datelor fac indexul respectiv util. Nu este o schimbare generală de viteză: optimizatorul bazei de date poate alege corect o scanare a tabelului pentru tabele mici sau interogări care returnează o mare parte din rânduri.

Indexurile au și costuri. Ocupă spațiu pe disc, trebuie întreținute atunci când rândurile se modifică și pot încetini munca grea de scriere. Indexurile suplimentare din tabelele principale ownCloud pot intra în conflict cu migrările schemei sau cu așteptările aplicației. Nu adăugați un index deoarece numele unei coloane pare important; identificați mai întâi solicitarea lentă și confirmați că planul de interogare real este ineficient.

1. Confirmați versiunea și baza de date ownCloud

Executați comenzi din directorul de instalare ownCloud ca și cont de server web. Într-o instalare tipică Debian sau Ubuntu, acel cont este www-data:

cd /var/www/owncloud
sudo -u www-data php occ status
sudo -u www-data php occ list

Folosește calea și contul de serviciu configurate pe gazdă. În Docker, folosește formularul de comandă documentat al containerului - de exemplu, manualul ownCloud folosește docker compose exec owncloud occ …. Ieșirea de stare identifică versiunea ownCloud și tipul bazei de date. Lista de comenzi arată ce acceptă de fapt această instalare; dacă o comandă de reparare a bazei de date nu este listată, nu presupune că se aplică instrucțiunile Nextcloud.

Verificați prezentarea generală a administratorului ownCloud pentru avertismente de configurare și notați numele exacte ale tabelelor și indexurilor dacă raportează un index lipsă. De asemenea, înregistrați ce este lent: o anumită căutare de fișiere, o pagină de partajare, un job în fundal sau o operațiune de sincronizare. O reclamație vagă, cum ar fi „ownCloud este lent”, nu este suficientă pentru a justifica o modificare a schemei.

2. Faceți o copie de rezervă înainte de a modifica structurile bazei de date

Înainte de orice creare de index, migrare a bazei de date sau reparare, faceți o copie de rezervă consistentă a bazei de date și a configurației ownCloud și asigurați-vă că știți cum să o restaurați. Ghidul de backup ownCloud recomandă activarea modului de întreținere înainte de a face o copie de rezervă a bazei de date. Comanda exactă de dump a bazei de date depinde de utilizarea serverului, MySQL sau MariaDB, PostgreSQL sau SQLite; utilizați instrumentele furnizorului de baze de date corespunzător și protejați acreditările și fișierele de backup.

sudo -u www-data php occ maintenance:mode --on
# Back up the database and ownCloud configuration with your vendor's procedure
# Confirm that the backup can be restored before proceeding

Modul de întreținere previne utilizarea obișnuită în timp ce întreținerea este în desfășurare; planificați o fereastră de service pentru producție. Nu copiați un fișier de bază de date activ ca înlocuitor pentru o copie de rezervă compatibilă cu baza de date. După finalizarea lucrărilor și a verificărilor de bază, reveniți instanța la modul normal:

sudo -u www-data php occ maintenance:mode --off

3. Folosește migrările gestionate de ownCloud pentru modificările schemei ownCloud

Mai întâi, aduceți ownCloud și aplicațiile sale compatibile la o versiune acceptată urmând instrucțiunile oficiale de actualizare și notele de lansare. Actualizările ownCloud execută migrări ale bazei de date care evoluează schema, inclusiv modificările necesare nucleului și aplicațiilor. Ghidul oficial recomandă rularea pas cu pas a actualizării bazei de date occpentru sistemele mai mari, unde o solicitare web poate expira.

Dacă prezentarea generală a administratorului raportează în continuare lipsă de index, verificați sudo -u www-data php occ listdocumentația oficială relevantă pentru versiunea exactă a versiunii ownCloud. Unele ghiduri terțe arată db:add-missing-indices, dar comanda nu este documentată în secțiunea comenzilor bazei de date ownCloud 10.16, analizată pentru acest articol. Dacă versiunea dvs. listează comanda respectivă, citiți ajutorul local și confirmați procedura cu documentația sau furnizorul aplicației pentru versiunea respectivă înainte de a o rula. Dacă comanda lipsește, nu instalați o comandă Nextcloud, nu editați manual tabelele principale ale ownCloud și nu copiați SQL dintr-o altă versiune. Partajați avertismentul, versiunea ownCloud, tipul bazei de date și jurnalele relevante cu ownCloud sau cu administratorul aplicației.

Comenzile bazei de date afișate în manualul ownCloud — cum ar fi db:convert-typesau db:convert-mysql-charset— deservesc sarcini specifice de conversie; acestea nu sunt comenzi generice de ajustare a indexului. Nu utilizați o comandă de conversie pentru a încerca să îmbunătățiți viteza interogărilor.

4. Investigați o interogare lentă cu instrumente native pentru baze de date

Când puteți identifica o interogare SQL lentă, utilizați instrumentele de analiză furnizate de baza de date. MySQL și MariaDB oferă EXPLAIN; PostgreSQL oferă, de asemenea EXPLAIN, cu propriile ieșiri și opțiuni. Începeți cu un plan care explică interogarea fără a o executa. Aveți grijă cu o opțiune de analiză: unele variante de baze de date execută instrucțiunea, ceea ce poate fi nesigur pentru scrieri sau costisitor într-o bază de date de producție aglomerată.

EXPLAIN SELECT ... FROM oc_filecache WHERE ...;

Verificați dacă planul citește mult mai multe rânduri decât returnează interogarea, dacă indexul așteptat este luat în considerare și dacă sortarea sau unirea domină lucrarea. Un index care nu este ales de optimizator nu lipsește automat: dacă interogarea returnează multe rânduri, o scanare poate fi mai ieftină. Comparați aceeași sarcină de lucru pe o copie reprezentativă de testare înainte de a face modificări specifice bazei de date. SQL-ul de bază și aspectele tabelelor OwnCloud se pot schimba de la o versiune la alta, astfel încât un index care pare util astăzi poate deveni redundant sau nesigur după o actualizare.

5. Verificați din nou simptomul inițial

După finalizarea unei migrări acceptate sau a unei reparări aprobate a indexului, verificați din nou prezentarea generală a administratorului ownCloud și examinați jurnalele serverului și bazei de date pentru erori. Repetați aceeași acțiune a utilizatorului sau job în fundal care a fost lent, utilizând un volum de date și condiții similare. Comparați timpul de răspuns, CPU-ul sau I/O-ul bazei de date și rândurile examinate unde baza de date expune aceste măsurători. Nu raportați o creștere a performanței dintr-un singur test mic sau o încărcare a paginii fără legătură.

Dacă avertismentul a dispărut, dar aceeași acțiune este în continuare lentă, blocajul ar putea fi în altă parte: latența stocării, serverele PHP, rundele de rețea, cron backlog, blocarea fișierelor sau caching-ul memoriei. ownCloud recomandă caching-ul memoriei și blocarea fișierelor tranzacționale externe pentru a reduce încărcarea bazei de date. Aceste setări abordează sarcini diferite față de un index al bazei de date, așadar configurați-le conform manualului oficial și topologiei de implementare.

Listă de verificare rapidă

• Înregistrați versiunea ownCloud, tipul bazei de date, acțiunea afectată și orice avertisment exact de configurare.
• Verificați occlista de comenzi instalate; distingeți instrucțiunile ownCloud de instrucțiunile Nextcloud.
• Realizați și verificați o copie de rezervă consistentă a bazei de date și a configurației înainte de a lucra la schemă.
• Folosește pașii acceptați pentru actualizarea și migrarea aplicațiilor ownCloud; nu modifică manual tabelele de bază fără instrucțiuni specifice versiunii.
• Folosește instrumentele de planificare a interogărilor ale furnizorului bazei de date pentru interogarea cu adevărat lentă, apoi repetă aceeași sarcină de lucru pentru a verifica rezultatul.

Nu există un set universal de indexuri care să accelereze fiecare instalare ownCloud 10. Abordarea durabilă este de a menține schema acceptată actualizată, de a diagnostica interogarea reală, de a modifica doar ceea ce documentează furnizorul sau întreținătorul relevant și de a verifica ulterior aceeași sarcină de lucru.

Referințe oficiale

• Referință comenzi ownCloud Server 10.16 occ
• Configurarea bazei de date ownCloud Server 10.16
• Ghid de backup pentru ownCloud Server 10.16
• Ghid de actualizare ownCloud Classic
• Documentația de caching a memoriei ownCloud
• Documentația MySQL 8.4 EXPLAIN
• Documentația PostgreSQL EXPLAIN