Baza danych

SQLite (domyślnie)

Nic do ustawiania: dane są w plugins/AdminControl/data.db. Dobre dla jednego serwera. Rób jej kopię razem z resztą folderu serwera, gdy serwer jest zatrzymany. Żeby zrobić kopię w trakcie działania serwera, kopiuj pliki własnym narzędziem SQLite zamiast menedżerem plików: sqlite3 data.db ".backup data-backup.db".

MySQL lub MariaDB

Użyj jej dla większych serwerów albo żeby dzielić bany, wyciszenia i panel między kilka serwerów.

1. Utwórz bazę i użytkownika:

   CREATE DATABASE admincontrol CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
   CREATE USER 'admincontrol'@'%' IDENTIFIED BY 'a-long-random-password';
   GRANT ALL ON admincontrol.* TO 'admincontrol'@'%';
   

2. W config.yml:

   database:
     type: mysql
     mysql:
       host: db.example.com
       port: 3306
       database: admincontrol
       user: admincontrol
       password: "a-long-random-password"
       use-ssl: true
   

3. Zrestartuj serwer. Tabele powstają przy starcie.

Baza, której używają już inne pluginy (CoreProtect, LiteBans, LuckPerms w jednej bazie), też działa: wszystkie tabele AdminControl zaczynają się od ac_, a pozostałych plugin nie rusza. Osobna baza to jednak porządniejszy wybór.

Przejście z SQLite na MySQL zaczyna się od pustej bazy: w tej wersji nie ma narzędzia do kopiowania.

Serwer, który używał MySQL, nigdy sam nie przechodzi na SQLite: gdy config.yml każe użyć SQLite (albo już nie mówi, której bazy użyć), AdminControl zostaje bez bazy i pisze o tym w konsoli, bo źle odczytany plik odciąłby serwer od sieci. Żeby celowo przenieść go na SQLite (startuje pusta), usuń plugins/AdminControl/database-type i zrestartuj serwer.

Niektóre zarządzane hostingi MySQL (np. DigitalOcean) włączają sql_require_primary_key. AdminControl wyłącza to ustawienie dla własnej sesji na czas tworzenia tabel. Jeśli hosting nie pozwala nawet na to, log serwera mówi o tym przy starcie i nic nie zostaje utworzone: ustaw sql_require_primary_key na OFF dla tej bazy w panelu hostingu albo daj użytkownikowi bazy uprawnienie SESSION_VARIABLES_ADMIN i zrestartuj serwer.

Kilka serwerów, jedna baza

Skieruj każdy serwer na tę samą bazę MySQL. Kary, gracze, ekipa, role i ustawienia są wspólne. Kara nałożona na jednym serwerze działa na pozostałych w ciągu około 2 sekund (ban albo kick wyrzuca gracza z serwera, na którym jest, wyciszenie zaczyna się tam); za proxy Velocity zobacz Sieć Velocity. Panel dowolnego serwera pokazuje całą sieć: serwery, graczy online na każdym, zgłoszenia ze wszystkich serwerów i statystyki każdego serwera, a jego konsola, czat i ogłoszenia docierają do każdego serwera (zobacz Panel sieci); nadaj każdemu serwerowi własne server-name. Zmiana ustawień albo ogłoszeń zrobiona na jednym serwerze dociera do pozostałych w ciągu minuty.

Zadania, które panel wysyła do innego serwera (komenda, wiadomość na czacie, czyszczenie czatu, ogłoszenie), czekają w ac_server_tasks i są usuwane po dniu. Linie konsoli serwera, którą ogląda panel, zostają w ac_console_lines najwyżej 10 minut.

Gdy baza nie działa

Serwer działa dalej, a panel pokazuje, że baza jest niedostępna. Dopóki nie wróci:

• wchodzący gracze są sprawdzani z listą banów trzymaną w pamięci (odczytywaną w całości co 5 minut): zbanowany gracz dostaje odmowę, każdy inny wchodzi, a konsola zapisuje checked against the in-memory list. Tylko gdy lista nie została jeszcze ani razu odczytana (baza nie działa od startu serwera), gracze wchodzą bez sprawdzenia banów, a konsola zapisuje dla każdego z nich joins without a ban check;
• wyciszenia dalej działają z tej samej listy w pamięci;
• nie da się nakładać ani zdejmować kar.

Jeśli przy starcie serwera bazy nie da się osiągnąć, AdminControl próbuje ponownie co 30 sekund. Jeśli baza padnie później, połączenie wraca samo, gdy baza znów działa; zapytanie MySQL bez odpowiedzi przez 2 minuty jest porzucane, więc połączenie zerwane po drodze nie blokuje AdminControl. Trzymaj bazę na niezawodnym hostingu albo używaj SQLite, jeśli sprawdzanie banów nie może być nigdy pominięte.