Jak rozmieszczenie bazy danych wpływa na niezawodność i odzyskiwanie danych w Plexie

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Niezawodność Plexa zwykle się poprawia, gdy jego aktywna baza danych i metadane znajdują się na lokalnym nośniku o niskich opóźnieniach, a duża biblioteka multimediów może być przechowywana gdzie indziej.

Serwer Plex może przesyłać filmy z dużych dysków HDD lub pamięci sieciowej, podczas gdy jego dane aplikacji wykonują wiele małych operacji odczytu i zapisu inną ścieżką. To rozróżnienie ma znaczenie, ponieważ plik multimedialny zawiera głównie dane odczytywane sekwencyjnie, natomiast baza biblioteki, metadane, miniatury i logi zachowują się bardziej jak stan aplikacji. Umiejscowienie bazy danych należy traktować jako decyzję dotyczącą opóźnień i odzyskiwania danych, a nie pojemności.

Dlaczego baza danych Plexa zachowuje się inaczej niż pliki multimedialne

Katalog danych Plexa zawiera bazę biblioteki oraz metadane, grafiki, pamięci podręczne i inne dane stanu serwera. Pliki te są używane podczas przeglądania, skanowania, przetwarzania metadanych, aktualizowania stanu odtwarzania i konserwacji, dlatego skoki opóźnień na ścieżce danych aplikacji mogą sprawić, że cały serwer będzie działał niestabilnie, nawet gdy same pliki filmów są odczytywane szybko.

Plex przechowuje często używany stan biblioteki w bazie danych SQLite, dlatego opóźnienia i integralność bazy danych należy oceniać niezależnie od przepustowości dużych plików multimedialnych; to punkt wyjścia do ustalenia sposobu umiejscowienia bazy danych i jej odzyskiwania.

Widoczny schemat jest prosty: jeśli przeglądanie, aktualizacje biblioteki i uruchamianie są powolne, a bezpośrednie odtwarzanie już otwartego pliku działa prawidłowo, należy najpierw zwrócić uwagę na ścieżkę danych aplikacji, a nie na dyski z multimediami.

Mierz opóźnienia i możliwość odzyskania danych, nie tylko przepustowość

Najważniejsze zmienne to opóźnienia losowych operacji wejścia-wyjścia, stabilność systemu plików, wolne miejsce, trwałość zapisu i sposób wykonywania kopii zapasowych. Szczytowa przepustowość sekwencyjna ma drugorzędne znaczenie, ponieważ baza danych nie zachowuje się jak duży strumień wideo.

Podczas pomiaru umiejscowienia i odzyskiwania bazy danych kontrola wąskich gardeł dla poszczególnych zasobów powinna obejmować wykorzystanie, nasycenie i błędy procesora, pamięci, sieci oraz pamięci masowej, zamiast opierać się na jednej średniej wartości.

Jeśli przeniesienie danych aplikacji skraca czas uruchamiania i przerwy podczas skanowania, ale nie zmienia przepustowości odtwarzania multimediów, oznacza to odizolowanie wąskiego gardła metadanych/bazy danych, a nie pamięci masowej z multimediami.

Kiedy szybszy nośnik przestaje pomagać

Lokalny dysk SSD nie rozwiąże problemu transkodowania ograniczonego przez procesor, wysycenia przepustowości wysyłania, nieobsługiwanych kodeków klienta ani uszkodzonego dysku z multimediami. Gdy opóźnienia bazy danych są już wystarczająco niskie i dominują inne etapy, większa liczba operacji wejścia-wyjścia na sekundę na urządzeniu z danymi aplikacji przynosi coraz mniejsze korzyści.

Na granicy awarii związanej z umiejscowieniem i odzyskiwaniem bazy danych, gdy uszkodzenie jest rzeczywiste, bezpieczniej jest podczas odzyskiwania utworzyć nową, czystą bazę danych SQLite na podstawie danych możliwych do odzyskania, zamiast wielokrotnie modyfikować uszkodzony oryginał.

Test graniczny polega na porównaniu integralności bazy danych i wolnego miejsca z momentem wystąpienia objawu. Jeśli integralność jest prawidłowa, a opóźnienia danych aplikacji są niskie, należy przenieść analizę na procesor, sieć, zgodność klienta lub ścieżkę multimediów, zamiast ponownie modernizować pamięć masową.

Zastosuj czteroetapowy test umiejscowienia

Przechowuj dane aplikacji Plexa na trwałym lokalnym systemie plików, utrzymuj aktualną kopię zapasową, a duże pliki multimedialne traktuj jako oddzielną warstwę pojemnościową. Następnie wykonaj jeden powtarzalny test działania biblioteki przed zmianą umiejscowienia i po niej. Układ pamięci masowej domowego serwera multimediów łatwiej ocenić, gdy role obliczeniowe, dane aplikacji, pamięć multimediów i sieć są zapisane oddzielnie.

Przed zaakceptowaniem zmiany dotyczącej umiejscowienia i odzyskiwania bazy danych spójna kopia zapasowa SQLite powinna pochodzić z bezpiecznego procesu tworzenia kopii zapasowej lub migawki, a nie z niekontrolowanego kopiowania aktywnych plików bazy danych podczas zapisu.

Przestań optymalizować urządzenie z bazą danych, gdy powtarzalny test przestaje wpływać na uruchamianie, nawigację lub działanie skanowania. W tym momencie kolejnym użytecznym pomiarem jest etap, który w tych samych warunkach obciążenia nadal pochłania czas.

  1. Potwierdź, że katalog danych Plexa jest trwały i ma wolne miejsce
  2. Zmierz czas uruchamiania i jednego skanowania biblioteki przed zmianą pamięci masowej
  3. Na potrzeby porównania przenieś tylko dane aplikacji, a nie wszystkie pliki multimedialne
  4. Zweryfikuj ścieżki kopii zapasowej i przywracania przed wycofaniem starej lokalizacji

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.