Mam maszynę wirtualną (Debian) działającą na hoście maszyny fizycznej. Maszyna wirtualna działa jako bufor dla danych, które często otrzymuje przez sieć lokalną (okres dla tych danych wynosi 0,5 s, więc dość wysoka przepustowość). Wszelkie otrzymane dane są przechowywane na maszynie wirtualnej i wielokrotnie przekazywane do zewnętrznego serwera przez UDP. Gdy serwer zewnętrzny potwierdzi (przez UDP), że otrzymał pakiet danych, oryginalne dane są usuwane z maszyny wirtualnej i nie są ponownie wysyłane na serwer zewnętrzny. Połączenie internetowe łączące maszynę wirtualną z zewnętrznym serwerem jest zawodne, co oznacza, że może być wyłączone przez kilka dni.
Fizyczna maszyna, na której znajduje się maszyna wirtualna, jest losowo odcinana kilka razy dziennie. Nie ma sposobu, aby powiedzieć, kiedy to nastąpi, i nie można dodać zasilacza UPS, baterii ani podobnego rozwiązania do systemu.
Pierwotnie dane były przechowywane w bazie danych HSQLDB opartej na plikach na maszynie wirtualnej. Jednak częste przerwy w dostawie prądu ostatecznie powodują uszkodzenie pliku skryptu bazy danych (nie na poziomie systemu plików, tzn. Jest on czytelny, ale HSQLDB nie może tego zrozumieć), co prowadzi do mojego pytania:
Jak dane powinny być przechowywane w środowisku, w którym przerwy w dostawie prądu mogą się często zdarzać?
Jedną z opcji, o której mogę myśleć, jest używanie plików płaskich, zapisywanie każdego pakietu danych jako pliku w systemie plików. W ten sposób, jeśli plik jest uszkodzony z powodu utraty zasilania, można go zignorować, a reszta danych pozostanie nienaruszona. Powoduje to jednak kilka problemów, głównie związanych z ilością danych, które prawdopodobnie są przechowywane na maszynie wirtualnej. Co 0,5 sekundy między każdą częścią danych, w ciągu 10 dni zostanie wygenerowanych 1 728 000 plików. Oznacza to co najmniej użycie systemu plików ze zwiększoną liczbą i-węzłów do przechowywania tych danych (w bieżącej konfiguracji systemu plików zabrakło i-węzłów przy ~ 250 000 komunikatów i zużyte 30% miejsca na dysku). Ponadto zarządzanie jest trudne (nie niemożliwe).
Są jakieś inne opcje? Czy istnieją silniki baz danych działające na Debianie, które nie uległyby uszkodzeniu w wyniku awarii zasilania? Jakiego systemu plików należy w tym celu użyć? ext3 jest obecnie używany.
Oprogramowanie działające na maszynie wirtualnej jest napisane w Javie 6, więc mam nadzieję, że rozwiązanie nie będzie niezgodne.
źródło
Odpowiedzi:
Szczerze mówiąc, Twoim najlepszym podejściem jest naprawienie awarii zasilania lub wdrożenie innego systemu w lepszej lokalizacji.
Tak, istnieją systemy takie jak redis, które będą przechowywać dane w dzienniku tylko do dołączania w celu odtworzenia, ale ryzykujesz uszkodzenie na niższych poziomach - np. Jeśli twój system plików jest zaszyfrowany, dane na dysku są potencjalnie zagrożone.
Doceniam, że jakakolwiek poprawa byłaby dla ciebie przydatna, ale tak naprawdę nie jest to problem, który można rozwiązać, biorąc pod uwagę nakreślony przez ciebie scenariusz.
źródło
Twoje podejście może działać. Pozwól, że zasugeruję kilka ulepszeń. Wystąpiło pytanie o przepełnienie stosu podczas zapisu atomowego do pliku . Zasadniczo zapisujesz każdy pakiet danych w pliku tymczasowym, a następnie zmieniasz jego nazwę na jego ostateczną nazwę. Zmiana nazwy jest operacją atomową, która będzie bezpieczna od awarii zasilania. W ten sposób masz pewność, że wszystkie twoje pliki w miejscu docelowym zostały poprawnie zapisane bez żadnych uszkodzeń.
To, co możesz zrobić, aby poradzić sobie z problemem posiadania milionów plików. Czy cron to zadanie uruchamiane może co godzinę, które zajmuje wszystkie pliki starsze niż godzinę i łączy je w jeden duży plik, używając ponownie operacji na plikach atomowych, dzięki czemu zadanie to działa bezpiecznie nawet podczas awarii zasilania, a następnie usuwa stare pliki. Coś w rodzaju rotacji kłody. Pliki warte godziny będą około 7200 plików. Dlatego w żadnym momencie nie powinieneś mieć więcej niż 20 000 plików na dysku.
źródło
Instalujesz UPS lub kartę RAID z zasilaną bateryjnie pamięcią podręczną zapisu do systemu, a już za 49,95 USD osiągasz to , czego nie da się osiągnąć w samym oprogramowaniu.
Twierdzenie, że w jakiś sposób nie można podłączyć tego serwera do zasilacza UPS lub baterii ... jest po prostu niewiarygodne.
źródło
My PHB won't let me hook this up to a UPS/battery
jest czymś zupełnie innym niżit is not possible to add a UPS, a battery, or a similar solution to the system.
niezbyt pedantycznym, ale jest to ważne rozróżnienie, ponieważ zmienia podejście i dostępne rozwiązania.Zamontuj cały system tylko do odczytu, z wyjątkiem urządzenia blokowego, które przechowuje wszystkie dane. Skorzystaj bezpośrednio z tego urządzenia blokowego i za pomocą tego surowego urządzenia blokowego zaimplementuj własny mechanizm przechowywania danych.
źródło