Jak usunąć starą historię wiadomości i multimedia w Matrix Synapse

Przykładowy scenariusz (tylko ilustracyjny): Northstar Community, hipotetyczna organizacja non-profit, prowadzi serwer domowy Matrix Synapse. Jego baza danych i magazyn multimediów rosną, a administrator chce usunąć starą historię pokoju i nieaktualne multimedia bez przypadkowego usuwania bieżących dyskusji lub zdjęć profilowych. Ten przykład nie jest raportem z rzeczywistego wdrożenia ani przetestowanym rezultatem.

Kluczem jest traktowanie historii wiadomości i multimediów jako osobnych zadań czyszczenia. Synapse oferuje API czyszczenia historii pomieszczeń i osobne narzędzia do czyszczenia multimediów; ustawienie retencji multimediów pozwala również usuwać pliki, zachowując jednocześnie zdarzenia Matrix, które się do nich odwołują. Najpierw zdecyduj, co ma pozostać dostępne, a następnie utwórz kopię zapasową bazy danych i magazynu multimediów, wybierz odpowiednią metodę i zweryfikuj oba obszary pamięci masowej.

Zdecyduj, co dla Twojego serwera oznacza „stary”

Przed zmianą konfiguracji lub wywołaniem destrukcyjnego punktu końcowego, zapisz regułę retencji. W przykładzie z Northstar, załóżmy, że zarząd zatwierdza przechowywanie zwykłej historii pokoju przez 180 dni, przechowywanie lokalnych plików przesyłanych zgodnie z podobną polityką oraz traktowanie zdalnych multimediów jako pamięci podręcznej, którą można ponownie pobrać w razie potrzeby. Inna organizacja może potrzebować lat retencji ze względów prawnych, operacyjnych lub społecznych. Te okresy są przykładami, a nie uniwersalnymi zaleceniami.

Podziel dane na dwie kategorie:

• Wydarzenia w pokoju: wiadomości i inne zdarzenia przechowywane w bazie danych Synapse. Usuwanie zdarzeń zmienia zakres, w jakim użytkownicy mogą przeglądać dane w pokoju.
• Media: przesłane pliki, miniatury i kopie plików z pamięci podręcznej z innych serwerów domowych. Znajdują się one w repozytorium multimediów lub w skonfigurowanym repozytorium zewnętrznym.

Oficjalna dokumentacja Synapse opisuje zasady przechowywania zdarzeń i czyszczenia nośników niezależnie. Samo czyszczenie historii pokoju nie dowodzi, że magazyn nośników został wyczyszczony, a usunięcie pliku multimedialnego nie powoduje usunięcia powiązanego z nim zdarzenia. Zacznij od zarejestrowania rozmiaru bazy danych, rozmiaru magazynu nośników, dotkniętych pokoi i planowanego odcięcia. Zapoznaj się z podręcznikiem konfiguracji Synapse .

Przed oczyszczeniem wykonaj kopię zapasową

Wykonaj kopię zapasową bazy danych, stosując procedurę zalecaną dla Twojego silnika bazy danych, a także kopię zapasową repozytorium multimediów lub zewnętrznego magazynu multimediów. Sama kopia zapasowa bazy danych nie zachowuje przesłanych plików; sama kopia zapasowa multimediów nie przywraca zdarzeń w pomieszczeniu. Przed kontynuacją upewnij się, że kopie zapasowe są czytelne i wiesz, jak je przywrócić. Jeśli Synapse działa w kontenerach lub korzysta z oddzielnych procesów roboczych, uwzględnij odpowiednią konfigurację i woluminy pamięci masowej w swoim planie konserwacji.

W przypadku hipotetycznego serwera Northstar administrator rejestruje rozmiary bazy danych i magazynu multimediów oraz potwierdza ostatni punkt przywracania przed wprowadzeniem zmian do współdzielonych pomieszczeń. Jest to przydatne, ponieważ „czyszczenie” jest skuteczne tylko wtedy, gdy usuwa pożądane dane, pozostawiając wymaganą zawartość do odzyskania.

Wybierz zaplanowane przechowywanie w celu bieżącego czyszczenia

Jeśli chcesz, aby Synapse nadal stosował politykę, skonfiguruj oddzielnie retencję zdarzeń i retencję multimediów w konfiguracji serwera domowego. Na przykład, administrator może dostosować ten przykład do serwera, którego zatwierdzona polityka to 180 dni dla historii pokoju i multimediów lokalnych, z 30-dniową pamięcią podręczną multimediów zdalnych:

retention:
  enabled: true
  default_policy:
    max_lifetime: 180d

media_retention:
  local_media_lifetime: 180d
  remote_media_lifetime: 30d

To jest konfiguracja przykładowa, a nie polityka typu „drop-in” dla każdego serwera. Synapse dokumentuje funkcję przechowywania zdarzeń jako domyślnie wyłączoną. default_policyDotyczy to pokoi, które nie mają m.room.retentionzdarzenia stanu; administratorzy pokoi mogą ustawiać zasady dla pokoi, podczas gdy administratorzy serwerów mogą ograniczać czas życia zasad za pomocą udokumentowanych ustawień dozwolonego czasu życia. Jeśli potrzebujesz spójnego górnego limitu, sprawdź te elementy sterujące i już używane zasady dla pokoi, zamiast zakładać, że domyślne ustawienie obejmuje każdy pokój.

Czasy życia multimediów są oparte na czasie od ostatniego dostępu do elementu multimedialnego. Jeśli do elementu nigdy nie uzyskano dostępu, Synapse używa czasu jego utworzenia. Ustawienie dotyczy oryginałów i miniatur; nieustawione lub zerowe czasy życia nie powodują usunięcia danej kategorii multimediów. Zdalny element z pamięci podręcznej może zostać ponownie zażądany z jego źródła po usunięciu. Nośniki poddane kwarantannie i lokalnie chronione stanowią wyjątki i nie są usuwane przez te ustawienia przechowywania. Czyszczenie multimediów jest uruchamiane w procesie lub procesie roboczym Synapse, który został enable_media_repowłączony. Sprawdź bieżące informacje dotyczące przechowywania i media_retention , a następnie zastosuj konfigurację, wykonując standardową procedurę ponownego uruchomienia lub wdrożenia instalacji.

Przed zastosowaniem przykładu porównaj jego działanie z Twoimi potrzebami. Jeśli wiadomość w pokoju musi pozostać czytelna wraz z załącznikiem przez 180 dni, nie wybieraj krótszego czasu życia multimediów, chyba że akceptujesz, że wiadomość może przetrwać dłużej niż lokalnie dostępny plik. Sprawdź, czy Twoje media są przechowywane w samym Synapse, czy w zewnętrznym repozytorium multimediów; API usuwania lokalnych multimediów w Synapse nie usuwa multimediów przechowywanych w zewnętrznym repozytorium.

Usuń starsze wydarzenia w pokoju na żądanie

Aby wykonać jednorazowe czyszczenie, skorzystaj z interfejsu API administratora Synapse Purge History. Wymaga to tokenu dostępu administratora serwera ; bycie administratorem pojedynczego pokoju to nie to samo uprawnienie. Synapse zaleca, aby interfejs API administratora był ukryty i nie był widoczny publicznie, a żądania były zazwyczaj wysyłane z serwera lub zaufanego hosta administracyjnego. Nie wklejaj aktywnego tokenu dostępu do współdzielonej historii powłoki, zgłoszeń ani logów.

Żądanie musi określać punkt odcięcia za pomocą identyfikatora zdarzenia lub znacznika czasu systemu Unix w milisekundach. Poniższy przykład powłoki jest ilustracją. Zastąp serwer domowy, identyfikator pokoju, zmienną tokena i punkt odcięcia przykładu wartościami, które sprawdziłeś. Przykład wyraźnie żąda również usunięcia zdarzeń komunikatów użytkownika lokalnego:

export SYNAPSE_ADMIN_TOKEN='replace-with-a-server-admin-token'
PURGE_CUTOFF_MS=1760000000000  # replace with the approved UTC cutoff

curl --fail-with-body -X POST \
  -H "Authorization: Bearer $SYNAPSE_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"purge_up_to_ts\": $PURGE_CUTOFF_MS, \"delete_local_events\": true}" \
  "https://matrix.example.org/_synapse/admin/v1/purge_history/!room:example.org"

Bez [brakuje delete_local_events: truewartości], Synapse domyślnie zachowuje zdarzenia wysłane przez użytkowników lokalnych; zdarzenia wysłane zdalnie mogą zostać usunięte. Stan pokoju, taki jak członkostwo i stan tematu, jest zachowywany. Synapse przechowuje również co najmniej jedną wiadomość w każdym pokoju. Operacja może trwać kilka minut lub dłużej, a użytkownicy nie mogą przeglądać wstecz fragmentu czyszczonego podczas jej działania. API natychmiast zwraca identyfikator czyszczenia; odpytuj, /_synapse/admin/v1/purge_history_status/<purge_id>aż status będzie równy [brakuje wartości] completelub zbadaj błąd, jeśli jest równy [brakuje wartości] failed. Przed wybraniem punktu odcięcia zapoznaj się z dokumentacją API historii czyszczenia . W szczególności sprawdź, czy usuwanie zdarzeń lokalnych jest odpowiednie dla Twoich pokoi.

Wyczyść oddzielnie lokalne nośniki i zdalną pamięć podręczną

W przypadku cyklicznego czyszczenia użyj media_retentioni wybierz okresy życia odpowiadające dostępności, którą obiecujesz użytkownikom. W przypadku jednorazowego czyszczenia Synapse udostępnia oddzielne punkty końcowe:

• Media lokalne: POST /_synapse/admin/v1/media/delete?before_ts=<timestamp_ms> usuwa kwalifikujące się media lokalne na podstawie czasu ich ostatniego użycia. Interfejs API akceptuje również próg rozmiaru. Media profilowe i awatara pokoju są domyślnie zachowywane; nie wyłączaj tej ochrony, chyba że celowo sprawdzisz konsekwencje.
• Zdalne nośniki w pamięci podręcznej: POST /_synapse/admin/v1/purge_media_cache?before_ts=<timestamp_ms> usuwa zbuforowane zdalne nośniki, do których ostatni dostęp nastąpił przed momentem odcięcia. Jeśli użytkownik zażąda usuniętego pliku zdalnego później, Synapse może ponownie zażądać go z serwera macierzystego.

Oba punkty końcowe używają dodatniego znacznika czasu Unix w milisekundach, a odcięcie multimediów jest oparte na ostatnim dostępie, a nie tylko na dacie przesłania lub utworzenia. Interfejs API usuwania lokalnych multimediów usuwa plik i miniatury z pamięci masowej Synapse, w tym z lokalnych kopii plików zdalnych przechowywanych w pamięci podręcznej; nie czyści zewnętrznego repozytorium multimediów. Odpowiedź raportuje liczbę usuniętych elementów. Przed uruchomieniem żądania sprawdź bieżące parametry i szczegóły punktu końcowego w interfejsie API administrowania multimediami Synapse .

W przykładzie Northstar administrator najpierw przetestowałby wartość odcięcia z zatwierdzoną polityką i sprawdził, czy identyfikatory lub liczniki zwrócone przez punkt końcowy są zgodne z oczekiwaniami. Jeśli zdalna pamięć podręczna jest jedynym źródłem wzrostu, czyszczenie lokalnych plików przesłanych przez serwer byłoby niewłaściwą operacją. Jeśli lokalne pliki przesłane muszą pozostać dostępne, należy wybrać dłuższy lokalny czas życia lub unikać punktu końcowego czyszczenia nośników lokalnych.

Zmierz wynik i zmień kurs, gdy będzie to konieczne

Po każdym zadaniu sprawdź, czy czyszczenie zakończyło się pomyślnie, przejrzyj liczbę odpowiedzi API, potwierdź, że reprezentatywne pomieszczenia wyświetlają oczekiwaną granicę historii i porównaj osobno wykorzystanie bazy danych i magazynu nośników. Zmniejszenie liczby wierszy w bazie danych może nie być od razu widoczne jako równoznaczne ze zmniejszeniem wykorzystania dysku systemu operacyjnego; odzyskiwanie miejsca w bazie danych zależy od silnika bazy danych i jego procedur konserwacyjnych. Postępuj zgodnie ze wskazówkami dostawcy bazy danych, zamiast ręcznie usuwać pliki bazy danych.

Jeśli baza danych się kurczy, ale magazyn nośników nie, sprawdź retencję nośników, pracownika nośników z enable_media_repokwarantanną lub statusem ochrony oraz czy pliki są przechowywane zewnętrznie. Jeśli użycie nośników spada, ale pozostają stare wiadomości, jest to normalne, gdy tylko nośnik został oczyszczony. Jeśli zdarzenia nieoczekiwanie się utrzymują, sprawdź, czy retencja jest włączona, czy pomieszczenie ma własny stan retencji, czy zdarzenia lokalne zostały celowo zachowane i czy status czyszczenia został zakończony.

Dla Northstar kryterium sukcesu nie jest po prostu „mniejszy dysk”. Chodzi o to, aby zatwierdzona granica starej historii była widoczna, wymagane bieżące wiadomości i załączniki nadal działały, docelowa kategoria multimediów została wyczyszczona, a obie kopie zapasowe pozostają dostępne. Jeśli te kontrole się nie powiodą, należy przerwać dalsze czyszczenie i sprawdzić politykę pokoju, odpowiedź API, konfigurację pracownika oraz zaplecze pamięci masowej przed rozszerzeniem czyszczenia.

Ograniczenia, o których należy pamiętać

Zasady przechowywania danych nie zastępują kontroli prawnej ani kontroli przechowywania danych w organizacji. Federacja oznacza, że ​​inne serwery domowe mogą przechowywać własne kopie zdarzeń lub multimediów, a Synapse nie może zagwarantować usunięcia danych z tych serwerów. Zdalne czyszczenie multimediów usuwa pamięć podręczną tego serwera; nie usuwa pliku źródłowego na serwerze domowym, z którego pochodzi. Podobnie, usunięcie lokalnego zdarzenia lub obiektu multimedialnego z Synapse nie powoduje przywrócenia kopii pobranej już przez innego uczestnika.

Użyj zaplanowanego przechowywania, gdy potrzebujesz powtarzalnej polityki; użyj interfejsów API administratora, aby przeprowadzić weryfikację i ukierunkowane czyszczenie. Zachowaj te dwie operacje oddzielnie w rekordzie zmian, ponieważ ich sygnały sukcesu i skutki są różne.