Wydanie rqlite 6.0, rozproszonego, odpornego na błędy systemu DBMS opartego na SQLite

Zaprezentowano wydanie rozproszonego systemu DBMS rqlite 6.0, który wykorzystuje SQLite jako silnik przechowywania danych i umożliwia organizację pracy klastra zsynchronizowanych magazynów. Jedną z cech rqlite jest łatwość instalacji, wdrażania i konserwacji rozproszonej, odpornej na awarie pamięci masowej, nieco podobnej do etcd i Consul, ale wykorzystującej relacyjny model danych zamiast formatu klucz/wartość. Kod projektu napisany jest w Go i rozpowszechniany na licencji MIT.

Aby utrzymać wszystkie węzły w stanie zsynchronizowanym, używany jest algorytm konsensusu Raft. Rqlite wykorzystuje oryginalną bibliotekę SQLite oraz standardowy sterownik go-sqlite3, na który uruchamiana jest warstwa przetwarzająca żądania klientów, wykonująca replikację do innych węzłów oraz monitorująca osiągnięcie konsensusu w sprawie wyboru węzła wiodącego.

Zmian w bazie danych może dokonać jedynie węzeł wybrany jako lider, ale połączenia z operacjami zapisu mogą być także wysyłane do innych węzłów w klastrze, co zwróci adres lidera w celu powtórzenia żądania (w kolejnej wersji będą one obietnica dodania automatycznego przekazywania żądań do lidera). Główny nacisk położony jest na odporność na błędy, więc DBMS skaluje się tylko przy operacjach odczytu, a wąskim gardłem są operacje zapisu. Możliwe jest uruchomienie klastra rqlite z pojedynczego węzła, a tego rozwiązania można użyć do zapewnienia dostępu do SQLite przez HTTP bez zapewniania odporności na awarie.

Dane SQLite w każdym węźle nie są przechowywane w pliku, ale w pamięci. Na poziomie warstwy z implementacją protokołu Raft prowadzony jest log wszystkich poleceń SQLite, które prowadzą do zmian w bazie danych. Dziennik ten wykorzystywany jest podczas replikacji (replikacji na poziomie odtwarzania żądań na innych węzłach), uruchamiania nowego węzła czy odzyskiwania danych po utracie łączności. W celu zmniejszenia rozmiaru logu stosuje się automatyczne pakowanie, które rozpoczyna się po określonej liczbie zmian i prowadzi do utrwalenia na dysku migawki, w związku z którą rozpoczyna się zapisywanie nowego logu (stan bazy danych w pamięci jest identyczny z migawką + skumulowanym dziennikiem zmian).

Funkcje rqlite:

  • Łatwe wdrażanie klastra, bez konieczności osobnej instalacji SQLite.
  • Możliwość szybkiego uzyskania replikowanej pamięci SQL.
  • Gotowy do użycia w projektach roboczych (klasa produkcyjna).
  • Obecność interfejsu API HTTP(S), który umożliwia aktualizację danych w trybie wsadowym i określenie węzła wiodącego klastra. Zapewnia także interfejs wiersza poleceń i możliwość korzystania z różnych bibliotek klienckich zbudowanych dla SQLite.
  • Dostępność usługi identyfikacji innych węzłów, umożliwiającej dynamiczne tworzenie klastrów.
  • Wsparcie dla szyfrowania wymiany danych pomiędzy węzłami.
  • Możliwość skonfigurowania poziomu sprawdzania trafności i spójności danych podczas odczytu.
  • Opcjonalna możliwość łączenia węzłów w trybie tylko do odczytu, które nie biorą udziału w ustalaniu konsensusu i służą do zwiększenia skalowalności klastra dla operacji odczytu.
  • Obsługa własnej formy transakcji w oparciu o łączenie poleceń w jednym żądaniu (nie są obsługiwane transakcje oparte na BEGIN, COMMIT, ROLLBACK, SAVEPOINT i RELEASE).
  • Wsparcie dla tworzenia gorących kopii zapasowych.

Nowa wersja wprowadza istotne zmiany w architekturze mające na celu zwiększenie niezawodności klastra poprzez usprawnienie procesu kierowania żądań odczytu i zapisu do właściwych węzłów klastra. węzły rqlite mogą teraz multipleksować między sobą wiele połączeń logicznych, korzystając z połączeń TCP nawiązywanych między węzłami przez protokół Raft. Jeśli żądanie wymaga uprawnień lidera, ale jest wysyłane do węzła dodatkowego, węzeł dodatkowy może określić adres lidera i przekazać go klientowi bez wykonywania obliczeń konsensusu Raft.

Zmiana wyeliminowała również potrzebę oddzielnego komponentu do synchronizacji metadanych i wyeliminowała oddzielną obsługę stanu Raft i metadanych. Węzły drugorzędne wysyłają teraz żądania do węzła wiodącego tylko wtedy, gdy jest to konieczne, gdy muszą znaleźć adres węzła wiodącego. API zapewnia możliwość uzyskania informacji o stanie pozostałych węzłów w klastrze. Do interfejsu wiersza poleceń dodano polecenie „.sysdump”.

Źródło: opennet.ru

Dodaj komentarz