Proponuję zapoznać się z transkrypcją raportu z początku 2019 roku autorstwa Andrieja Borodina „Kopie zapasowe z WAL-G. Co tam w 2019?”
Cześć wszystkim! Nazywam się Andriej Borodin. Jestem programistą w Yandex. PostgreSQL interesuję się od 2016 roku, kiedy rozmawiałem z programistami i powiedzieli, że wszystko jest proste – bierzesz kod źródłowy, budujesz go i wszystko się ułoży. I od tamtej pory nie mogę przestać – piszę różne rzeczy.
Jedną z rzeczy, nad którymi pracuję, jest system tworzenia kopii zapasowych. . Ogólnie rzecz biorąc, w Yandex od bardzo długiego czasu pracujemy nad systemami tworzenia kopii zapasowych w PostgreSQL. A w Internecie można znaleźć serię sześciu raportów o tym, jak tworzymy systemy kopii zapasowych. I każdego roku trochę ewoluują, trochę się rozwijają i stają się bardziej niezawodne.
Ale dzisiejsze sprawozdanie nie dotyczy tylko tego, czego zrobiliśmy, ale także tego, jakie to proste i jakie jest. Ilu z Was oglądało już moje relacje o WAL-G? Dobrze, że sporo osób nie obejrzało, bo zacznę od najprostszej rzeczy.
Jeśli nagle masz klaster PostgreSQL i myślę, że każdy ma ich kilka przy sobie, i nagle nie ma jeszcze systemu tworzenia kopii zapasowych, musisz zaopatrzyć się w dowolną pamięć S3 lub pamięć kompatybilną z Google Cloud.
Możesz na przykład przyjść na nasze stoisko i odebrać kod promocyjny na Yandex Object Storage, który jest kompatybilny z S3.
Następnie utwórz Wiadro. To tylko pojemnik na informacje.
Utwórz użytkownika usługi.
Utwórz klucz dostępu dla użytkownika usługi: aws-s3-key.
Pobierz najnowszą stabilną wersję WAL-G.
Czym nasze wersje wstępne różnią się od wydań? Często jestem proszony o wcześniejsze zwolnienie. A jeśli w wersji nie ma błędu przez wystarczający czas, na przykład miesiąc, to ją wypuszczam. Oto wydanie z listopada. Oznacza to, że co miesiąc znaleźliśmy jakiś błąd, zwykle w funkcjonalnościach niekrytycznych, ale nie wydaliśmy jeszcze żadnej wersji. Poprzednia wersja jest dopiero listopadowa. Nie ma w nim znanych nam błędów, tzn. błędy były dodawane w miarę postępu projektu.
Po pobraniu WAL-G możesz uruchomić proste polecenie „lista kopii zapasowych”, przekazując zmienne środowiskowe. Połączy się z Object Storage i poinformuje Cię, jakie masz kopie zapasowe. Na początku oczywiście nie powinieneś mieć kopii zapasowych. Celem tego slajdu jest pokazanie, że wszystko jest całkiem proste. Jest to polecenie konsoli, które akceptuje zmienne środowiskowe i wykonuje podpolecenia.
Następnie możesz wykonać pierwszą kopię zapasową. Powiedz „backup-push” w WAL-G i określ w WAL-G lokalizację pgdata swojego klastra. I najprawdopodobniej PostgreSQL poinformuje Cię, jeśli nie masz jeszcze systemu kopii zapasowych, że musisz włączyć „tryb archiwalny”.
Oznacza to, że musisz przejść do ustawień i włączyć „tryb_archiwum = on” i dodać „polecenie_archiwum”, które jest również podpoleceniem w WAL-G. Ale z jakiegoś powodu ludzie często używają skryptów słupkowych na ten temat i owijają go wokół WAL-G. Proszę, nie rób tego. Skorzystaj z funkcjonalności dostępnych w WAL-G. Jeżeli czegoś Ci brakuje napisz . WAL-G zakłada, że jest to jedyny program działający w komendzie_archiwum.
Używamy WAL-G głównie do tworzenia klastra wysokiej dostępności w zarządzaniu bazą danych Yandex.
I jest zwykle używany w topologii jednego Mastera i kilku replikacji. Jednocześnie tworzy kopię zapasową w Yandex Object Storage.
Najczęstsze scenariusze polegają na tworzeniu kopii klastra przy użyciu odzyskiwania do punktu w czasie. Ale w tym przypadku wydajność systemu kopii zapasowych nie jest dla nas tak ważna. Musimy tylko wgrać nowy klaster z kopii zapasowej.
Zwykle podczas dodawania nowego węzła potrzebujemy wydajności systemu zapasowego. Dlaczego to jest ważne? Zazwyczaj ludzie dodają nowy węzeł do klastra, ponieważ istniejący klaster nie jest w stanie obsłużyć obciążenia odczytem. Muszą dodać nową replikę. Jeśli dodamy obciążenie z pg_basebackup do Mastera, Master może się zawalić. Dlatego bardzo ważne było dla nas, abyśmy mogli szybko wgrać nowy węzeł z archiwum, powodując minimalne obciążenie Mastera.
I kolejna podobna sytuacja. Jest to konieczność ponownego uruchomienia starego Mastera po przełączeniu Cluster Mastera z Data Center, z którym utracono łączność.
- W rezultacie formułując wymagania na system kopiowania zdaliśmy sobie sprawę, że pg_basebackup nie jest dla nas odpowiedni podczas pracy w chmurze.
- Chcieliśmy mieć możliwość kompresji naszych danych. Jednak prawie każdy system tworzenia kopii zapasowych inny niż dostarczony w zestawie zapewnia kompresję danych.
- Chcieliśmy wszystko zrównoleglić, ponieważ użytkownik w chmurze kupuje dużą liczbę rdzeni procesorów. Jeśli jednak w jakiejś operacji nie mamy równoległości, wówczas duża liczba rdzeni staje się bezużyteczna.
- Potrzebujemy szyfrowania, ponieważ często dane nie są nasze i nie można ich przechowywać w postaci zwykłego tekstu. Nawiasem mówiąc, nasz wkład w WAL-G zaczął się od szyfrowania. Zakończyliśmy szyfrowanie w WAL-G, po czym zapytano nas: „Może ktoś z nas rozwinie projekt?” I od tego czasu współpracuję z WAL-G już ponad rok.
- Potrzebowaliśmy też throttlingu zasobów, bo z biegiem czasu korzystając z chmury przekonaliśmy się, że czasami ludzie mają w nocy ważny ładunek spożywczy i nie da się w to obciążenie ingerować. Dlatego dodaliśmy ograniczanie zasobów.
- A także umieszczanie na liście i zarządzanie.
- I weryfikacja.
Przyjrzeliśmy się wielu różnym narzędziom. Na szczęście w PostgreSQL mamy ogromny wybór. I wszędzie czegoś nam brakowało, jakiejś małej funkcji, jakiejś małej funkcji.
Po zbadaniu istniejących systemów doszliśmy do wniosku, że będziemy rozwijać WAL-G. To był wtedy nowy projekt. Dość łatwo było wpłynąć na rozwój w kierunku infrastruktury chmurowej systemu kopii zapasowych.
Główną ideologią, której się trzymamy, jest to, że WAL-G powinien być prosty jak bałałajka.
WAL-G ma 4 polecenia. Ten:
WAL-PUSH – archiwizuj wał.
WAL-FETCH – weź wał.
BACKUP-PUSH – wykonaj kopię zapasową.
BACKUP-FETCH – uzyskaj kopię zapasową z systemu kopii zapasowych.
Tak naprawdę WAL-G zajmuje się również zarządzaniem tymi kopiami zapasowymi, czyli wyświetlaniem i usuwaniem w historii rekordów i kopii zapasowych, które w danym momencie nie są już potrzebne.
Jedną z ważnych dla nas funkcji jest funkcja tworzenia kopii delta.
Kopie delta oznaczają, że nie tworzymy pełnej kopii zapasowej całego klastra, a jedynie zmienionych stron zmienionych plików w klastrze. Wydawałoby się, że funkcjonalnie jest to bardzo podobne do możliwości odzyskiwania za pomocą WAL. Możemy jednak równolegle utworzyć jednowątkową kopię zapasową delta WAL. W związku z tym, jeśli w sobotę mamy podstawową kopię zapasową, codziennie kopie delta, a w czwartek zakończy się niepowodzeniem, wówczas musimy zebrać 4 kopie zapasowe delta i 10 godzin WAL. Zajmie to mniej więcej tyle samo czasu, ponieważ kopie zapasowe delta są wykonywane równolegle.
Delty oparte na LSN - oznacza to, że podczas tworzenia kopii zapasowej będziemy musieli połączyć każdą stronę i sprawdzić jej numer LSN z numerem LSN poprzedniej kopii zapasowej, aby zrozumieć, że się zmienił. W kopii zapasowej delta powinna znajdować się każda strona, która może potencjalnie zawierać zmienione dane.
Jak mówiłem, sporo uwagi poświęcono równoległości.
Ale interfejs API archiwum w PostgreSQL jest spójny. PostgreSQL archiwizuje jeden plik WAL i przy jego przywracaniu żąda jednego pliku WAL. Kiedy jednak baza danych żąda jednego pliku WAL za pomocą polecenia „WAL-FETCH”, wywołujemy polecenie „WAL-PREFETCH”, które przygotowuje kolejnych 8 plików do równoległego pobrania danych z magazynu obiektów.
A kiedy baza danych prosi nas o zarchiwizowanie jednego pliku, patrzymy na Archive_status i sprawdzamy, czy istnieją inne pliki WAL. Próbujemy także pobrać WAL równolegle. Zapewnia to znaczny wzrost wydajności i znacznie zmniejsza odległość w liczbie niezarchiwizowanych WAL. Wielu twórców systemów tworzenia kopii zapasowych uważa, że jest to bardzo ryzykowny system, ponieważ polegamy na naszej wiedzy o wewnętrznych elementach kodu, który nie jest API PostgreSQL. PostgreSQL nie gwarantuje nam obecności folderu Archive_status i nie gwarantuje semantyki, obecności tam sygnałów gotowości dla plików WAL. Niemniej jednak badamy kod źródłowy, widzimy, że tak jest i staramy się to wykorzystać. A my kontrolujemy kierunek rozwoju PostgreSQL, jeśli nagle ten mechanizm ulegnie uszkodzeniu, przestaniemy go używać.
W czystej postaci delta WAL oparta na sieci LSN wymaga odczytania dowolnego pliku klastra, którego czas trybu w systemie plików zmienił się od czasu poprzedniej kopii zapasowej. Żyliśmy z tym długo, prawie rok. I w końcu doszliśmy do wniosku, że mamy delty WAL.
Oznacza to, że za każdym razem, gdy archiwizujemy WAL na Masterze, nie tylko go kompresujemy, szyfrujemy i wysyłamy do sieci, ale także jednocześnie odczytujemy. Analizujemy i czytamy znajdujące się w nim zapisy. Rozumiemy, które bloki uległy zmianie i zbieramy pliki delta.
Plik delta opisuje pewien zakres plików WAL, opisuje informacje o tym, które bloki zostały zmienione w tym zakresie WAL. Następnie te pliki delta są również archiwizowane.
Tutaj mamy do czynienia z tym, że dość szybko wszystko zrównolegliliśmy, ale nie możemy czytać historii sekwencyjnej równolegle, bo w pewnym fragmencie możemy spotkać koniec poprzedniego zapisu WAL, z którym nie mamy jeszcze nic wspólnego, bo czytanie równoległe doprowadziło do tego, że najpierw analizujemy przyszłość, która nie ma jeszcze przeszłości.
W rezultacie musieliśmy umieścić niezrozumiałe fragmenty w plikach _delta_partial. Dzięki temu, kiedy wrócimy do przeszłości, skleimy fragmenty zapisu WAL w jedną całość, a następnie przeanalizujemy go i zrozumiemy, co się w nim zmieniło.
Jeśli w historii naszego parsowania szybu choć raz pojawi się moment, w którym nie zrozumiemy co się dzieje, to odpowiednio przy kolejnym kopiowaniu będziemy zmuszeni ponownie odczytać cały klaster, tak jak to zrobiliśmy w przypadku zwykłego LSN oparta na delcie.
W rezultacie całe nasze cierpienie doprowadziło do tego, że udostępniliśmy bibliotekę analizującą WAL-G na zasadach open source. Z tego co wiem, nikt jeszcze z niego nie korzysta, ale jeśli ktoś chce, pisze i używa, to jest w domenie publicznej. (Zaktualizowany link )
W rezultacie cały przepływ informacji wygląda na dość skomplikowany. Nasz Mistrz archiwizuje wał i archiwizuje pliki delta. Replika tworząca kopię zapasową musi otrzymywać pliki delta w czasie, jaki upłynął pomiędzy kopiami zapasowymi. W takim przypadku części historii będą musiały zostać dodane zbiorczo i przeanalizowane, ponieważ nie cała historia mieści się w dużych segmentach. I dopiero wtedy replika może zarchiwizować pełną kopię zapasową delta.
Na wykresach wszystko wygląda dużo prościej. To jest plik do pobrania z jednego z naszych prawdziwych klastrów. Mamy oparte na LSN, wykonane w jeden dzień. Widzimy, że kopia zapasowa delta oparta na sieci LSN działała od trzeciej nad ranem do piątej rano. Jest to obciążenie w liczbie rdzeni procesora. WAL-delta zajęła nam tutaj około 20 minut, czyli stało się znacznie szybciej, ale jednocześnie nastąpiła intensywniejsza wymiana przez sieć.
Ponieważ mamy informacje o tym, które bloki uległy zmianie i w którym momencie historii bazy danych, poszliśmy dalej i zdecydowaliśmy się na integrację funkcjonalności - rozszerzenie PostgreSQL o nazwie „pg_prefaulter”
Oznacza to, że gdy baza rezerwowa wykona polecenie przywracania, mówi WAL-G, aby pobrał następny plik WAL. Rozumiemy, do jakich bloków danych w najbliższej przyszłości będzie miał dostęp proces odzyskiwania WAL, i inicjujemy operację odczytu tych bloków. Dokonano tego w celu zwiększenia wydajności kontrolerów SSD. Ponieważ rolka WAL dotrze do strony, którą należy zmienić. Ta strona znajduje się na dysku i nie znajduje się w pamięci podręcznej strony. I będzie czekał synchronicznie na przybycie tej strony. Ale niedaleko jest WAL-G, który wie, że w ciągu najbliższych kilkuset megabajtów WAL-a będziemy potrzebować pewnych stron i jednocześnie zaczyna je podgrzewać. Inicjuje dostęp do wielu dysków, dzięki czemu są one wykonywane równolegle. Działa to dobrze na dyskach SSD, ale niestety absolutnie nie ma zastosowania w przypadku dysku twardego, ponieważ ingerujemy w to tylko za pomocą naszych podpowiedzi.
To jest to, co jest teraz w kodzie.
Są funkcje, które chcielibyśmy dodać.
To zdjęcie pokazuje, że WAL-delta zajmuje stosunkowo krótki czas. A to jest odczytanie zmian jakie zaszły w bazie w ciągu dnia. WAL-deltę moglibyśmy robić nie tylko nocą, bo nie jest to już znaczące źródło obciążenia. Możemy czytać WAL-delta co minutę, ponieważ jest tania. W ciągu jednej minuty jesteśmy w stanie przeskanować wszystkie zmiany jakie zaszły w klastrze. Można to nazwać „natychmiastową deltą WAL”.
Chodzi o to, że przywracając klaster, zmniejszamy liczbę historii, które musimy po kolei zwijać. Oznacza to, że należy zmniejszyć ilość WAL rzucaną przez PostgreSQL, ponieważ zajmuje to dużo czasu.
Ale to nie wszystko. Jeśli wiemy, że jakiś blok zostanie zmieniony do punktu spójności kopii zapasowej, nie możemy tego zmienić w przeszłości. Oznacza to, że teraz mamy optymalizację pliku po pliku przesyłania WAL-delta. Oznacza to, że jeśli np. we wtorek usunięto całkowicie tabelę lub w całości usunięto z tabeli jakieś pliki, to gdy w poniedziałek nastąpi przeniesienie delty i przywrócony zostanie sobotni pg_basebackup, to nawet tych danych nie utworzymy.
Chcemy rozszerzyć tę technologię na poziom strony. Oznacza to, że jeśli w poniedziałek jakaś część pliku zmieni się, ale w środę zostanie nadpisana, to przywracając stan do stanu w czwartek, nie musimy zapisywać na dysk kilku pierwszych wersji stron.
Jednak jest to nadal pomysł, który jest w nas aktywnie omawiany, ale nie osiągnął jeszcze kodu.
Chcemy wprowadzić jeszcze jedną funkcję w WAL-G. Chcemy, aby był on rozszerzalny, ponieważ potrzebujemy obsługi różnych baz danych i chcielibyśmy móc w ten sam sposób podejść do zarządzania kopiami zapasowymi. Problem polega jednak na tym, że interfejsy API MySQL są radykalnie różne. W MySQL PITR nie opiera się na fizycznym logu WAL, ale na binlogu. Nie mamy też systemu archiwizacji w MySQL, który informowałby jakiś system zewnętrzny, że ten dziennik binarny jest zakończony i należy go zarchiwizować. Musimy stanąć gdzieś w cronie z bazą danych i sprawdzić czy jest coś gotowe?
I w ten sam sposób podczas przywracania MySQL nie ma polecenia przywracania, które mogłoby powiedzieć systemowi, że potrzebuję takich a takich plików. Zanim zaczniesz odbudowywać klaster, musisz wiedzieć, jakich plików będziesz potrzebować. Sam musisz zgadnąć, jakie pliki będą potrzebne. Ale te problemy można w jakiś sposób obejść. (Wyjaśnienie: MySQL jest już obsługiwany)
W raporcie chciałem także omówić przypadki, w których WAL-G nie jest dla Ciebie odpowiedni.
Jeżeli nie posiadasz repliki synchronicznej, WAL-G nie gwarantuje, że ostatni segment zostanie zachowany. A jeśli archiwizacja pozostaje w tyle za kilkoma ostatnimi segmentami historii, jest to ryzyko. Jeśli nie ma repliki synchronicznej, nie polecam używania WAL-G. Mimo to jest przeznaczony głównie do instalacji w chmurze, co oznacza rozwiązanie High Availability z repliką synchroniczną, która odpowiada za bezpieczeństwo ostatnich przekazanych bajtów.
Często widzę ludzi próbujących jednocześnie uruchomić WAL-G i WAL-E. Obsługujemy kompatybilność wsteczną w tym sensie, że WAL-G może przywrócić plik z WAL-E i może przywrócić kopię zapasową utworzoną w WAL-E. Ponieważ jednak oba te systemy korzystają z równoległego systemu Wal-Push, zaczynają kraść sobie pliki. Jeśli naprawimy to w WAL-G, nadal pozostanie w WAL-E. W WAL-E sprawdza stan archiwum, widzi gotowe pliki i archiwizuje je, podczas gdy inne systemy po prostu nie będą wiedziały, że ten plik WAL istniał, ponieważ PostgreSQL nie będzie próbował go archiwizować po raz drugi.
Co będziemy naprawiać tutaj, po stronie WAL-G? Nie poinformujemy PostgreSQL, że ten plik był przesyłany równolegle, a gdy PostgreSQL poprosi nas o jego zarchiwizowanie, będziemy już wiedzieć, że taki plik z tym czasem trybu i tym md5 został już zarchiwizowany i powiemy po prostu PostgreSQL - OK, wszystko jest gotowe, praktycznie bez robienia czegokolwiek.
Jest jednak mało prawdopodobne, aby problem ten został rozwiązany po stronie WAL-E, dlatego obecnie nie jest możliwe utworzenie polecenia archiwizacji, które zarchiwizuje plik zarówno w WAL-G, jak i WAL-E.
Ponadto zdarzają się przypadki, w których WAL-G nie jest teraz dla Ciebie odpowiedni, ale na pewno to naprawimy.
Po pierwsze, obecnie nie mamy wbudowanej weryfikacji kopii zapasowej. Nie mamy weryfikacji ani podczas tworzenia kopii zapasowej, ani odzyskiwania. Oczywiście jest to realizowane w chmurze. Ale można to osiągnąć po prostu poprzez wstępne sprawdzenie, po prostu poprzez przywrócenie klastra. Chciałbym udostępnić tę funkcjonalność użytkownikom. Ale poprzez weryfikację zakładam, że w WAL-G będzie można przywrócić klaster i uruchomić go oraz przeprowadzić testy dymne: pg_dumpall do /dev/null i weryfikację indeksu amcheck.
Obecnie w WAL-G nie ma możliwości odroczenia jednej kopii zapasowej z WAL. Oznacza to, że obsługujemy pewne okno. Na przykład przechowywanie ostatnich siedmiu dni, przechowywanie ostatnich dziesięciu kopii zapasowych, przechowywanie ostatnich trzech pełnych kopii zapasowych. Dość często ludzie przychodzą i mówią: „Potrzebujemy kopii zapasowej tego, co wydarzyło się w Nowy Rok i chcemy ją zachować na zawsze”. WAL-G jeszcze nie wie, jak to zrobić. (Uwaga - zostało to już naprawione. Czytaj więcej - Opcja znaku kopii zapasowej w )
Podczas sprawdzania poprawności PITR nie mamy sum kontrolnych stron ani kontroli integralności dla wszystkich segmentów wału.
Z tego wszystkiego stworzyłem projekt na Google Summer of Code. Jeśli znasz mądrych studentów, którzy chcieliby napisać coś w Go i zyskać kilka tysięcy dolarów od jednej firmy na literę „G”, to poleć im nasz projekt. Będę mentorem w tym projekcie, oni mogą to zrobić. Jeśli nie będzie studentów, to wezmę to i zrobię to sam w lecie.
Mamy także wiele innych drobnych problemów, nad którymi stopniowo pracujemy. I dzieją się dość dziwne rzeczy.
Na przykład, jeśli dasz WAL-G pustą kopię zapasową, po prostu upadnie. Na przykład, jeśli powiesz mu, że musi wykonać kopię zapasową pustego folderu. Pliku pg_control tam nie będzie. I pomyśli, że czegoś nie rozumie. Teoretycznie w tym przypadku trzeba napisać do użytkownika zwykłą wiadomość, w której wyjaśnimy mu, jak korzystać z narzędzia. Ale to nawet nie jest cecha programowania, ale cecha dobrego, zrozumiałego języka.
Nie wiemy, jak wykonać kopię zapasową offline. Jeśli baza danych kłamie, nie możemy jej wykonać kopii zapasowej. Ale tutaj wszystko jest bardzo proste. Kiedy to się zaczęło, wzywamy kopie zapasowe przez LSN. Numer LSN bazowej bazy należy odczytać z pliku kontrolnego. A to taka niezrealizowana funkcja. Wiele systemów tworzenia kopii zapasowych może tworzyć kopie zapasowe podstawowej bazy danych. I jest to wygodne.
Obecnie nie jesteśmy w stanie prawidłowo poradzić sobie z brakiem miejsca na kopie zapasowe. Ponieważ zazwyczaj pracujemy z dużymi kopiami zapasowymi w domu. I nie zajęli się tym. Jeśli jednak ktoś chce teraz programować w Go, dodaj do wiadra obsługę błędów związanych z brakiem miejsca. Na pewno rozważę prośbę o ściągnięcie.
A najważniejszą rzeczą, która nas martwi, jest to, że chcemy jak najwięcej testów integracji z dokerem, które sprawdzają różne scenariusze. W tej chwili testujemy tylko podstawowe scenariusze. Przy każdym zatwierdzeniu, ale chcemy sprawdzać zatwierdzenie po zatwierdzeniu wszystkich obsługiwanych przez nas funkcji. W szczególności będziemy mieli wystarczającą obsługę PostgreSQL 9.4-9.5. Wspieramy je, ponieważ społeczność obsługuje PostgreSQL, ale nie sprawdzamy zatwierdzania po zatwierdzeniu, aby upewnić się, że wszystko nie jest zepsute. I wydaje mi się, że jest to dość poważne ryzyko.
Mamy WAL-G działający w ponad tysiącu klastrów w zarządzaniu bazą danych Yandex. Codziennie tworzy kopie zapasowe kilkuset terabajtów danych.
W naszym kodzie mamy mnóstwo rzeczy do zrobienia. Jeśli chcesz programować przyjdź, czekamy na pull requesty, czekamy na pytania.
pytania
Dobry wieczór! Dziękuję! Domyślam się, że jeśli używasz WAL-delta, prawdopodobnie w dużym stopniu polegasz na zapisach całostronicowych. A jeśli tak, czy przeprowadziłeś testy? Pokazałeś piękny wykres. O ile piękniej będzie, gdy FPW zostanie wyłączone?
Zapisy na całej stronie są dla nas włączone, nie próbowaliśmy tego wyłączać. Oznacza to, że jako programista nie próbowałem tego wyłączać. Administratorzy systemu, którzy badali, prawdopodobnie badali ten problem. Ale potrzebujemy FPW. Prawie nikt tego nie wyłącza, bo w przeciwnym razie nie da się wykonać kopii zapasowej z repliki.
Dziękujemy za raport! Mam dwa pytania. Pierwsze pytanie brzmi: co stanie się z obszarami tabel?
Czekamy na żądanie ściągnięcia. Nasze bazy danych znajdują się na dyskach SSD i NMVE i tak naprawdę nie potrzebujemy tej funkcji. Nie jestem teraz gotowy, aby spędzać poważny czas na robieniu tego dobrze. Z całego serca opowiadam się za tym, abyśmy to poparli. Są ludzie, którzy go wspierali, ale wspierali go w sposób, który im odpowiada. Zrobili widelec, ale nie wykonują żądań ściągnięcia. (Dodano w wersji 0.2.13)
I drugie pytanie. Mówiłeś na samym początku, że WAL-G zakłada, że działa sam i nie potrzebuje żadnych wrapperów. Sama korzystam z wrapów. Dlaczego nie warto ich używać?
Chcemy, żeby to było proste jak bałałajka. Oznacza to, że nie potrzebujesz niczego poza bałałajką. Chcemy, żeby system był prosty. Jeśli masz funkcjonalność, którą musisz wykonać w skrypcie, przyjdź i powiedz nam – zrobimy to w Go.
Dobry wieczór! Dziękujemy za raport! Nie udało nam się zmusić WAL-G do współpracy z deszyfrowaniem GPG. Szyfruje normalnie, ale nie chce odszyfrować. Czy jest to coś, co nam nie wyszło? Sytuacja jest przygnębiająca.
Utwórz problem w GitHubie i rozwiążmy go.
To znaczy, nie spotkałeś się z tym?
Raport o błędach ma taką cechę, że gdy WAL-G nie rozumie, jaki to rodzaj pliku, pyta: „Może jest zaszyfrowany?” Być może problemem wcale nie jest szyfrowanie. Chcę poprawić rejestrowanie w tym temacie. Musi to rozszyfrować. Aktualnie pracujemy nad tym tematem w tym sensie, że nie do końca podoba nam się sposób organizacji systemu pozyskiwania kluczy publicznych i prywatnych. Ponieważ wywołujemy zewnętrzny GPG, aby przekazał nam swoje klucze. Następnie bierzemy te klucze i przesyłamy je do wewnętrznego GPG, czyli otwartego PGP, który jest dla nas kompilowany w WAL-G i tam nazywamy szyfrowaniem. W związku z tym chcemy ulepszyć system i chcemy obsługiwać szyfrowanie Libsodium (dodano w wersji 0.2.15). Oczywiście dekodowanie powinno działać, rozwiążmy to - potrzebujesz więcej symptomu niż kilku słów. Możesz czasem zebrać się w pokoju mówców i przyjrzeć się systemowi. (szyfrowanie PGP bez zewnętrznego GPG - v0.2.9)
Cześć! Dziękujemy za raport! Mam dwa pytania. Mam dziwną chęć zrobienia pg_basebackup i logowania WAL u dwóch dostawców, tj. chcę zrobić jedną chmurę i drugą. Czy jest na to jakiś sposób?
Teraz tego nie ma, ale to ciekawy pomysł.
Po prostu nie ufam jednemu dostawcy, chcę mieć to samo u innego, na wszelki wypadek.
Pomysł jest interesujący. Technicznie rzecz biorąc, nie jest to wcale trudne do wdrożenia. Czy mogę poprosić Cię o zgłoszenie problemu w serwisie GitHub, aby zapobiec zagubieniu się pomysłu?
Tak, oczywiście.
A potem, gdy uczniowie przyjdą na Google Summer of Code, dodamy ich do projektu, aby było więcej pracy, aby wydobyć z nich więcej.
I drugie pytanie. Wystąpił problem w GitHubie. Myślę, że jest już zamknięte. Podczas przywracania panuje panika. Aby go pokonać, zorganizowaliście oddzielne zgromadzenie. To słuszne w kwestiach. Istnieje możliwość wykonania zmiennego środowiska w jednym wątku. I dlatego działa bardzo wolno. Napotkaliśmy ten problem, który nie został jeszcze naprawiony.
Problem polega na tym, że z jakiegoś powodu pamięć (CEPH) resetuje połączenie, gdy dochodzimy do niego z dużą współbieżnością. Co można zrobić na ten temat? Logika ponawiania prób wygląda następująco. Próbujemy pobrać plik ponownie. W jednym przebiegu mieliśmy niepobraną pewną liczbę plików, zrobimy drugi dla wszystkich, którzy się nie zalogowali. I dopóki co najmniej jeden plik jest ładowany na iterację, powtarzamy i powtarzamy. Poprawiliśmy logikę ponawiania prób — wykładnicze wycofywanie. Nie jest jednak do końca jasne, co zrobić z faktem, że połączenie po prostu zostaje zerwane po stronie systemu pamięci masowej. Oznacza to, że gdy wrzucimy do jednego strumienia, nie zrywa to tych połączeń. Co możemy tutaj poprawić? Mamy dławienie sieci, możemy ograniczyć każde połączenie liczbą wysyłanych bajtów. Inaczej nie wiem jak sobie poradzić z tym, że pamięć obiektowa nie pozwala nam na pobieranie lub pobieranie z niej równolegle.
Brak umowy SLA? Czyż nie jest im napisane, jak pozwalają się dręczyć?
Rzecz w tym, że osoby, które zadają to pytanie, zazwyczaj mają swój własny skarbiec. Oznacza to, że nikt nie pochodzi z Amazon, Google Cloud czy Yandex Object Storage.
Może to pytanie nie jest już dla Ciebie?
Pytanie tutaj w tym przypadku nie ma znaczenia dla kogo. Jeśli są jakieś pomysły jak sobie z tym poradzić, zróbmy to w WAL-G. Ale jak dotąd nie mam dobrych pomysłów, jak sobie z tym poradzić. Istnieją pewne obiekty Object Storage, które obsługują wyświetlanie kopii zapasowych w inny sposób. Prosisz ich o wyświetlenie listy obiektów, a oni dodają tam folder. WAL-G się tego boi – jest tu coś, co nie jest plikiem, nie mogę go przywrócić, czyli kopia zapasowa nie została przywrócona. Oznacza to, że w rzeczywistości masz całkowicie przywrócony klaster, ale zwraca on błędny status, ponieważ Object Storage zwrócił jakieś dziwne informacje, których nie do końca zrozumiał.
Dzieje się tak w chmurze Mail.
Jeśli potrafisz zbudować reprodukcję...
Jest konsekwentnie powielany...
Jeśli uda się powtórzyć, myślę, że poeksperymentujemy ze strategiami ponawiania prób i wymyślimy, jak ponowić próbę i zrozumieć, czego wymaga od nas chmura. Może na trzech połączeniach będzie nam stabilnie i nie zerwie połączenia, wtedy ostrożnie dotrzemy do trzech. Bo teraz bardzo szybko zrywamy połączenie, czyli jeśli uruchomiliśmy odzyskiwanie z 16 wątkami, to po pierwszej ponownej próbie zostanie 8 wątków, 4 wątki, 2 wątki i jeden. A następnie przeciągnie plik do jednego strumienia. Jeśli istnieją jakieś magiczne wartości, takie jak 7,5 wątku, które są najlepsze do pompowania, zatrzymamy się nad nimi i spróbujemy zrobić kolejne 7,5 wątku. Oto pomysł.
Dziękujemy za raport! Jak wygląda kompletny przebieg pracy z WAL-G? Na przykład w głupim przypadku, gdy na stronach nie ma delty. Bierzemy i usuwamy początkową kopię zapasową, a następnie archiwizujemy wał, aż zrobimy się niebiescy na twarzy. Tutaj, jak rozumiem, następuje załamanie. W pewnym momencie musisz wykonać kopię zapasową stron delta, tj. steruje tym jakiś proces zewnętrzny lub jak to się dzieje?
Interfejs API kopii zapasowych delta jest dość prosty. Jest tam liczba – maksymalne kroki delta, tak to się nazywa. Domyślnie wynosi zero. Oznacza to, że za każdym razem, gdy wykonujesz kopię zapasową typu push, pobierana jest pełna kopia zapasowa. Jeśli zmienisz ją na dowolną liczbę dodatnią, na przykład 3, przy następnym przesyłaniu kopii zapasowej zostanie sprawdzona historia poprzednich kopii zapasowych. Widzi, że nie przekraczasz łańcucha 3 delt i tworzy deltę.
Oznacza to, że za każdym razem, gdy uruchamiamy WAL-G, próbuje on wykonać pełną kopię zapasową?
Nie, my uruchamiamy WAL-G, który próbuje utworzyć deltę, jeśli pozwalają na to twoje zasady.
Z grubsza mówiąc, jeśli uruchomisz go za każdym razem z zerem, czy będzie zachowywał się jak pg_basebackup?
Nie, nadal będzie działać szybciej, ponieważ wykorzystuje kompresję i równoległość. Pg_basebackup umieści wał obok ciebie. WAL-G zakłada, że masz skonfigurowaną archiwizację. Wyświetli ostrzeżenie, jeśli nie zostanie skonfigurowane.
Pg_basebackup można uruchomić bez wałków.
Tak, wtedy będą zachowywać się prawie tak samo. Pg_basebackup kopiuje do systemu plików. Przy okazji, mamy nową funkcję, o której zapomniałem wspomnieć. Możemy teraz wykonać kopię zapasową systemu plików z pg_basebackup. Nie wiem, dlaczego jest to potrzebne, ale tak jest.
Na przykład na CephFS. Nie każdy chce konfigurować Object Storage.
Tak, prawdopodobnie dlatego zadali pytanie dotyczące tej funkcji, abyśmy mogli to zrobić. I zrobiliśmy to.
Dziękujemy za raport! Pozostaje tylko pytanie o kopiowanie do systemu plików. Czy po wyjęciu z pudełka obsługujesz teraz kopiowanie do magazynu zdalnego, na przykład, jeśli w centrum danych znajduje się półka lub coś innego?
W tym sformułowaniu jest to trudne pytanie. Tak, obsługujemy, ale ta funkcja nie jest jeszcze uwzględniona w żadnej wersji. Oznacza to, że wszystkie wersje wstępne obsługują tę funkcję, ale wersje wydawnicze nie. Funkcjonalność ta została dodana w wersji 0.2. Na pewno zostanie wydany wkrótce, gdy tylko naprawimy wszystkie znane błędy. Jednak w tej chwili można to zrobić tylko w wersji przedpremierowej. Wersja przedpremierowa zawiera dwa błędy. Problem z odzyskiwaniem WAL-E, nie naprawiliśmy go. W najnowszej wersji wstępnej dodano błąd dotyczący tworzenia kopii zapasowych delta. Dlatego zalecamy wszystkim korzystanie z wersji Release. Jak tylko w wersji wstępnej nie będzie już więcej błędów, możemy powiedzieć, że obsługujemy Google Cloud, rzeczy kompatybilne z S3 i przechowywanie plików.
Witam, dziękuję za raport. O ile rozumiem, WAL-G nie jest jakimś scentralizowanym systemem na wzór barmanów? Czy planujecie podążać w tym kierunku?
Problem w tym, że odeszliśmy od tego kierunku. WAL-G działa na hoście podstawowym, hoście w klastrze i na wszystkich hostach w klastrze. Kiedy przeprowadziliśmy się do kilku tysięcy klastrów, mieliśmy wiele instalacji barmańskich. I za każdym razem, gdy coś się w nich rozpada, jest to duży problem. Ponieważ wymagają naprawy, musisz dowiedzieć się, które klastry nie mają teraz kopii zapasowych. Nie planuję rozwijać WAL-G w kierunku sprzętu fizycznego do systemów kopii zapasowych. Jeśli społeczność chce tutaj jakiejś funkcjonalności, nie mam nic przeciwko.
Posiadamy zespoły odpowiedzialne za magazynowanie. I czujemy się tak dobrze, że to nie my, że są wyjątkowi ludzie, którzy umieszczają nasze pliki w bezpiecznym miejscu. Wykonują tam różnego rodzaju sprytne kodowanie, aby wytrzymać utratę określonej liczby plików. Odpowiadają za przepustowość sieci. Jeśli masz barmana, możesz nagle odkryć, że na tym samym serwerze zebrały się małe bazy danych o dużym ruchu. Wygląda na to, że masz na nim dużo miejsca, ale z jakiegoś powodu wszystko nie mieści się w sieci. Może się to potoczyć odwrotnie. Jest tam dużo sieci, są rdzenie procesorów, ale tu nie ma dysków. I znudziła nam się ta potrzeba żonglowania czymś i przeszliśmy do tego, że przechowywanie danych to osobna usługa, za którą odpowiadają osobne, specjalne osoby.
PS Wydano nową wersję , w którym można skorzystać z pliku konfiguracyjnego .walg.json, który domyślnie znajduje się w katalogu domowym postgres. Możesz porzucić skrypty bash. Przykład .walg.json znajduje się w tym numerze
Video:
Źródło: www.habr.com