Baza produkcyjna w kontenerze bez stałego wolumenu

Klient utrzymywał bazę produkcyjną tak, jak API i workera: jako kontener. Manifest albo compose wyglądał spójnie. Restart, rolling update i drain węzła były zwykłymi operacjami platformy. Po jednym z takich ruchów katalog danych wrócił do stanu z obrazu. Aplikacja wstawała. Dane nie.

Z czym przyszedł klient

Silnik bazy był poprawnie opisany w pliku konfiguracyjnym. Brakowało miejsca, w którym ten plik i te dane miały przeżyć kontener. Nie było PersistentVolumeClaim. Nie było osobnego volume na hoście. Baza siedziała obok usług bezstanowych, więc dostała ten sam cykl życia.

Jak wyglądała kopia

Kopia, jeśli w ogóle istniała, leżała poza rytmem. Nikt nie odtwarzał jej na kopii środowiska. Zespół dowiadywał się o luce, gdy pod wracał z nowym identyfikatorem, a katalog był pusty. Czasem pomagał dump z laptopa. Czasem nie.

To nie był błąd silnika. InnoDB, WAL i katalog danych robiły to, do czego są zaprojektowane. Problem siedział w tym, że stan żył w warstwie zapisu obrazu, która znika razem z kontenerem.

Dlaczego to pęka przy restarcie

Kontener ma cykl życia krótszy niż baza. Nowy obraz, inny node, evict, rolling update: każdy z tych ruchów może skasować warstwę zapisu. Baza trzyma stan. Stan musi stać na wolumenie z klasą storage, z polityką dostępu i z miejscem na wzrost.

Operacja platformy, utrata zbioru

Upgrade obrazu, przeniesienie poda i restart hosta wyglądają jak zwykła praca klastra. Dla bazy są utratą zbioru, jeśli pliki silnika nie leżą poza kontenerem. Restore bez wcześniejszego testu jest wtedy zgadywaniem, nie procedurą.

W manifeście usługa bezstanowa i baza wyglądają podobnie: obraz, port, zmienne. Różnica wychodzi dopiero przy restarcie. Jedna wstaje pusta i to jest poprawne. Druga wstaje pusta i to jest incydent.

Jak to ułożyliśmy

Wydzieliliśmy dane ze ścieżki kontenera. Baza dostała wolumen: PersistentVolumeClaim, klasa storage, rozmiar i wzrost zapisane w manifeście. Deploy i restart nie ruszają plików silnika. Drain węzła ma kolejność: flush, odłączenie, start na nowym nodzie z tym samym wolumenem.

Drugi tor, nie tylko PVC

Sam wolumen nie kończy tematu. Dołożyliśmy dump logiczny w kalendarzu i snapshot wolumenu. Restore odpalamy na kopii środowiska, nie na produkcji. RPO i RTO są zapisane. Runbook aktualizacji mówi, w jakiej kolejności schodzi pod, jak czeka na flush i jak wraca.

PVC rozwiązuje przeżycie restartu. Ćwiczenie restore rozwiązuje pytanie, czy kopia w ogóle daje się odtworzyć. Oba są w zakresie, bo klient przyszedł po utracie danych, nie po samym manifeście.

Skutek

Baza przeżywa restart, przeniesienie na inny węzeł i wymianę obrazu. Dane są na wolumenie. Kopia ma właściciela. Restore ma datę w kalendarzu. Ten sam układ opisujemy w usłudze bezpieczeństwa danych.

Podsumowanie

Baza w kontenerze jest dopuszczalna, gdy stan leży na wolumenie, a kopia ma ćwiczenie. Traktowanie silnika jak workera bezstanowego kończy się pustym katalogiem w momencie, który z punktu widzenia platformy wygląda na sukces.