CLI

vendor/bin/storh stats <root> [collection] [doc|log|queue]
vendor/bin/storh verify <root> [collection] [doc|log|queue]
vendor/bin/storh compact <root> [collection] [doc|log]
vendor/bin/storh reindex <root> [collection]

<root> to katalog główny magazynu, z którym otwarto silniki; jest to ścieżka zwracana przez StorageRoot::resolve(): katalog bazowy wraz z przestrzenią nazw. Magazyn otwarty w StorageRoot::resolve(__DIR__ . '/var/storh', 'app') znajduje się w var/storh/app:

vendor/bin/storh stats var/storh/app pages doc
vendor/bin/storh verify var/storh/app events log
vendor/bin/storh compact var/storh/app events log
vendor/bin/storh reindex var/storh/app pages

Przekazanie samego katalogu bazowego (var/storh) wskazuje polecenia na kolekcję, która jeszcze nie istnieje, więc zgłaszają pustą kolekcję zamiast kończyć się błędem.

vendor/bin/storh wymaga storh 0.5.2 lub nowszej wersji, gdy storh jest zainstalowane jako zależność. Wcześniejsze wersje szukały autoloadera Composer wyłącznie w katalogu vendor/ pakietu i kończyły się błędem require.

CLI wyświetla stabilne JSON, dzięki czemu można używać go w zadaniach cron i kontrolach stanu wdrożenia. Domyślną kolekcją jest default; domyślnym silnikiem dla stats, verify i reindex jest doc, a dla compact — log.

Metody konserwacyjne używane przez polecenia

Wszystkie silniki udostępniają metody konserwacyjne używane przez CLI:

$store->stats();
$store->health();
$store->verify();
$store->repair();

DocStore dodaje:

$docs->reindex();
$docs->compact(); // no-op report for API symmetry

SegmentedLog dodaje:

$log->compact();
$log->recover();
$log->state_index();

W przypadku DocStore verify() sprawdza, czy rekordy są poprawnie parsowane, a indeksy równościowe, zakresowe i złożone odpowiadają pełnemu skanowi rekordów. repair() poddaje kwarantannie uszkodzone pliki rekordów w .storh/corrupt/ i odbudowuje indeksy na podstawie poprawnych rekordów.

W przypadku SegmentedLog verify() dekoduje wiersze segmentów i porównuje bieżący indeks stanu pochodnego z odtworzeniem segmentów od początku. repair() odbudowuje stan pochodny i obcina urwane końcowe wiersze.

W przypadku Queue verify() dekoduje każde trwałe zdarzenie i porównuje stany oczekujące, przetwarzane i zakończone, ładunek oraz kolejność przejęć z odtworzeniem queue.log od początku. repair() odbudowuje stan kolejki z logu i ponownie umieszcza w kolejce zadania przetwarzane, których limit czasu upłynął.