Jak bezpiecznie optymalizować indeksy bazy danych ownCloud 10
Powolne wyświetlanie listy folderów ownCloud, opóźniona synchronizacja lub długotrwałe zadanie cron mogą wskazywać na wąskie gardło bazy danych, ale bezmyślne dodawanie indeksów może zmniejszyć niezawodność serwera. W przypadku serwera ownCloud 10 bezpiecznym punktem wyjścia jest sprawdzenie dokładnej wersji i bazy danych, utworzenie kopii zapasowej instancji, a następnie korzystanie wyłącznie ze zmian schematu udokumentowanych dla danej wersji ownCloud. Indeksy mogą wspomagać selektywne wyszukiwania i łączenia; zajmują również pamięć masową i zwiększają obciążenie operacji wstawiania i aktualizacji.
Istnieje istotna różnica między wersjami: aktualny oficjalny dokument referencyjny poleceń serwera ownCloud 10.16 dokumentuje operacje na bazie danych, takie jak konwersja bazy danych, ale nie opisuje ogólnego db:add-missing-indicespolecenia naprawy. To polecenie pojawia się w poradniku NextCloud, który jest oddzielnym produktem. Sprawdź polecenia na własnym serwerze przed uruchomieniem polecenia skopiowanego z innego projektu.
Polecenie occ statuspotwierdza, że interfejs CLI nawiązuje połączenie z instalacją ownCloud przed rozpoczęciem pracy nad bazą danych.
Co indeks bazy danych może, a czego nie może naprawić
Indeks bazy danych to struktura pomocnicza, która pomaga bazie danych zlokalizować pasujące wiersze bez konieczności skanowania całej tabeli. Może usprawnić zapytanie filtrujące, łączące lub sortujące według indeksowanych kolumn, gdy zapytanie i rozkład danych sprawiają, że indeks jest użyteczny. Nie jest to ogólny przełącznik szybkości: optymalizator bazy danych może prawidłowo wybrać skanowanie tabeli w przypadku małych tabel lub zapytań zwracających dużą część wierszy.
Indeksy również wiążą się z kosztami. Zajmują miejsce na dysku, wymagają aktualizacji w przypadku zmiany wierszy i mogą spowalniać pracę związaną z dużym obciążeniem zapisu. Dodatkowe indeksy w tabelach core ownCloud mogą kolidować z migracjami schematów lub oczekiwaniami aplikacji. Nie dodawaj indeksu tylko dlatego, że nazwa kolumny wydaje się ważna; najpierw zidentyfikuj powolne żądanie i upewnij się, że rzeczywisty plan zapytania jest nieefektywny.
1. Potwierdź kompilację ownCloud i bazę danych
Uruchom polecenia z katalogu instalacyjnego ownCloud jako konto serwera WWW. W typowej instalacji Debiana lub Ubuntu to konto wygląda następująco www-data:
cd /var/www/owncloud
sudo -u www-data php occ status
sudo -u www-data php occ list
Użyj ścieżki i konta usługi skonfigurowanych na hoście. W Dockerze użyj udokumentowanej formy poleceń kontenera – na przykład w podręczniku ownCloud użyto docker compose exec owncloud occ …. Dane wyjściowe statusu identyfikują wersję ownCloud i typ bazy danych. Lista poleceń pokazuje, co ta instalacja faktycznie obsługuje; jeśli polecenie naprawy bazy danych nie jest wymienione, nie zakładaj, że instrukcje Nextcloud mają zastosowanie.
Sprawdź w przeglądzie administratora ownCloud ostrzeżenia dotyczące konfiguracji i zanotuj dokładne nazwy tabel i indeksów, jeśli zgłosi brak indeksu. Zapisz również, co jest powolne: wyszukiwanie konkretnych plików, strona udostępniania, zadanie w tle lub operacja synchronizacji. Niejasna skarga, taka jak „ownCloud jest powolny”, nie wystarczy, aby uzasadnić zmianę schematu.
Użyj zainstalowanej occlisty poleceń jako sprawdzenia wersji; dostępność poleceń może się różnić w zależności od platformy ownCloud i Nextcloud.
2. Przed zmianą struktury bazy danych wykonaj kopię zapasową
Przed utworzeniem indeksu, migracją bazy danych lub naprawą należy wykonać spójną kopię zapasową bazy danych i konfiguracji ownCloud oraz upewnić się, że wiesz, jak ją przywrócić. Przewodnik po tworzeniu kopii zapasowych ownCloud zaleca włączenie trybu konserwacji przed utworzeniem kopii zapasowej bazy danych. Dokładne polecenie zrzutu bazy danych zależy od tego, czy serwer korzysta z MySQL, MariaDB, PostgreSQL czy SQLite; należy używać odpowiednich narzędzi dostawcy bazy danych oraz chronić dane uwierzytelniające i pliki kopii zapasowej.
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
Tryb konserwacji uniemożliwia normalne użytkowanie podczas prac konserwacyjnych. Zaplanuj okno serwisowe na produkcję. Nie kopiuj pliku aktywnej bazy danych zamiast kopii zapasowej uwzględniającej bazę danych. Po zakończeniu prac i podstawowych kontroli przywróć instancję do trybu normalnego:
sudo -u www-data php occ maintenance:mode --off
Przed podjęciem próby zmiany indeksu lub schematu wykonaj kopię zapasową bazy danych i konfiguracji, którą można przywrócić.
3. Użyj migracji zarządzanych przez ownCloud w przypadku zmian schematu ownCloud
Najpierw przenieś ownCloud i kompatybilne aplikacje do obsługiwanej wersji, postępując zgodnie z oficjalnymi instrukcjami aktualizacji i informacjami o wydaniu. Aktualizacje ownCloud uruchamiają migracje bazy danych, które rozwijają schemat, w tym zmiany wymagane przez rdzeń i aplikacje. Oficjalne wytyczne zalecają przeprowadzenie aktualizacji bazy danych w occprzypadku większych systemów, w których żądanie sieciowe może przekroczyć limit czasu.
Jeśli w przeglądzie administratora nadal występuje brak indeksu, sprawdź sudo -u www-data php occ listodpowiednią oficjalną dokumentację dla konkretnej kompilacji ownCloud. Niektóre poradniki firm trzecich wyświetlają db:add-missing-indicespolecenie , ale nie jest ono udokumentowane w sekcji poleceń bazy danych ownCloud 10.16, omówionej w tym artykule. Jeśli Twoja kompilacja zawiera to polecenie, przeczytaj jego lokalną pomoc i potwierdź procedurę w dokumentacji lub u dostawcy aplikacji przed jej uruchomieniem. Jeśli polecenie jest niedostępne, nie instaluj polecenia NextCloud, nie edytuj ręcznie głównych tabel ownCloud ani nie kopiuj kodu SQL z innej wersji. Udostępnij ostrzeżenie, wersję ownCloud, typ bazy danych i odpowiednie logi ownCloud lub administratorowi aplikacji.
Polecenia bazy danych przedstawione w podręczniku ownCloud — takie jak db:convert-type„lub” db:convert-mysql-charset— służą do realizacji konkretnych zadań konwersji; nie są to ogólne polecenia dostrajania indeksów. Nie należy używać polecenia konwersji w celu zwiększenia szybkości zapytań.
4. Zbadaj wolne zapytanie za pomocą narzędzi natywnych dla bazy danych
Gdy zidentyfikujesz wolne zapytanie SQL, skorzystaj z narzędzi analitycznych dostarczonych przez bazę danych. MySQL i MariaDB oferują EXPLAIN; PostgreSQL również oferuje EXPLAIN, z własnym wynikiem i opcjami. Zacznij od planu, który wyjaśnia zapytanie bez jego wykonywania. Zachowaj ostrożność przy wyborze opcji „analysis”: niektóre warianty bazy danych wykonują instrukcję, co może być niebezpieczne dla operacji zapisu lub kosztowne w przypadku obciążonej bazy danych produkcyjnej.
EXPLAIN SELECT ... FROM oc_filecache WHERE ...;
Sprawdź, czy plan odczytuje znacznie więcej wierszy niż zwraca zapytanie, czy brany jest pod uwagę oczekiwany indeks oraz czy sortowanie lub łączenie nie jest dominującym elementem pracy. Indeks niewybrany przez optymalizator nie jest automatycznie pomijany: jeśli zapytanie zwróci wiele wierszy, skanowanie może być tańsze. Porównaj to samo obciążenie na reprezentatywnej kopii tymczasowej przed wprowadzeniem zmian specyficznych dla bazy danych. Układy baz danych SQL i tabel OwnCloud mogą się zmieniać w zależności od wersji, więc indeks, który wydaje się przydatny dzisiaj, może stać się zbędny lub niebezpieczny po aktualizacji.
Przed rozważeniem wykonania jakiegokolwiek niestandardowego indeksu należy zapoznać się z planem zapytania specyficznym dla danej bazy danych, dotyczącym naprawdę powolnego zapytania.
5. Sprawdź ponownie pierwotny objaw
Po zakończeniu obsługiwanej migracji lub zatwierdzonej naprawy indeksu, sprawdź ponownie przegląd administratora ownCloud i przejrzyj logi serwera i bazy danych pod kątem błędów. Powtórz tę samą czynność użytkownika lub zadanie w tle, które było powolne, używając podobnej ilości danych i warunków. Porównaj czas reakcji, obciążenie procesora lub wejścia/wyjścia bazy danych oraz wiersze, w których baza danych ujawnia te pomiary. Nie zgłaszaj wzrostu wydajności z pojedynczego, małego testu lub niezwiązanego z nim obciążenia strony.
Jeśli ostrzeżenie zniknęło, ale ta sama akcja nadal działa powoli, wąskie gardło może leżeć gdzie indziej: opóźnienia w pamięci masowej, procesy PHP, obiegi sieci, zaległości w cronie, blokowanie plików lub buforowanie pamięci. OwnCloud zaleca buforowanie pamięci i zewnętrzne blokowanie plików transakcyjnych w celu zmniejszenia obciążenia bazy danych. Ustawienia te dotyczą innych zadań niż indeks bazy danych, dlatego należy je skonfigurować zgodnie z oficjalną instrukcją i topologią wdrożenia.
Szybka lista kontrolna
Rejestruj wersję ownCloud, typ bazy danych, działania, których dotyczy problem, a także wszelkie dokładne ostrzeżenia dotyczące konfiguracji.
Sprawdź zainstalowaną occlistę poleceń i rozróżnij instrukcje ownCloud od instrukcji Nextcloud.
Przed rozpoczęciem pracy nad schematem wykonaj i zweryfikuj spójną kopię zapasową bazy danych i konfiguracji.
Skorzystaj z obsługiwanych kroków aktualizacji ownCloud i migracji aplikacji; nie modyfikuj ręcznie tabel głównych bez instrukcji dotyczących konkretnej wersji.
Użyj narzędzi planu zapytań dostawcy bazy danych na rzeczywiście wolnym zapytaniu, a następnie powtórz to samo obciążenie, aby zweryfikować wynik.
Nie ma uniwersalnego zestawu indeksów, który przyspieszyłby każdą instalację ownCloud 10. Trwałe podejście polega na utrzymywaniu aktualnego schematu, diagnozowaniu rzeczywistego zapytania, zmienianiu tylko tego, co dokumentuje odpowiedni dostawca lub administrator, a następnie weryfikowaniu tego samego obciążenia.