Ochrona danych i ciągłość działania

Zarządzanie, ład danych i współpraca w Snowflake

Emily Melhuish

Technical Curriculum Developer, Snowflake

Problem ciągłości działania

Diagram przedstawiający trzy scenariusze ryzyka: przypadkowe usunięcie, awaria regionu i rezydencja danych między regionami, każdy z odpowiednim rozwiązaniem Snowflake

Analityk przypadkowo usuwa rekordy – obsługuje to Time Travel
Awaria regionu chmurowego uniemożliwia dostęp do konta Claro – obsługują to grupy failover
Użytkownicy z UE potrzebują danych dostępnych tylko na koncie US – obsługuje to replikacja
Różne ryzyka wymagają różnych narzędzi

Time Travel i Fail-Safe

Diagram osi czasu

Time Travel umożliwia przywrócenie danych do poprzedniego stanu
Głębokość okna zależy od edycji
- Standard: do 1 dnia
- Enterprise: do 90 dni
Fail-Safe: 7-dniowy bufor odtwarzania poza oknem Time Travel – wymaga kontaktu z pomocą techniczną Snowflake

Zero-Copy Cloning: wzorce operacyjne

Sklonuj tabelę przed ryzykowną operacją zbiorczą
Natychmiastowa kopia – brak narzutu na przestrzeń dyskową przy tworzeniu
Jeśli migracja się nie powiedzie, przywróć dane z klona
Zapis do klona nie modyfikuje źródła

Zero Copy Cloning.png

¹ Snowflake Learning Material

Czym jest replikacja?

Kopiuje dane między kontami
Asynchroniczna – cel jest niemal aktualny, ale nie jest lustrem na żywo

Przypadki użycia

Screenshot 2026-05-17 at 7.33.30 pm.png

Przykład replikacji.png

Grupy replikacji

Diagram grupy replikacji zawierającej dwie bazy danych na koncie głównym US-East, ze strzałkami do replik tylko do odczytu na koncie pomocniczym EU-West

Tworzenie grupy replikacji

-- On the primary account
CREATE REPLICATION GROUP claro_replication_group
  OBJECT_TYPES = DATABASES
  ALLOWED_DATABASES = claro_db, claro_users_db
  ALLOWED_ACCOUNTS = claro.eu_west;

-- On the secondary account
CREATE REPLICATION GROUP claro_replication_group
  AS REPLICA OF claro.us_east.claro_replication_group;

-- Trigger a refresh
ALTER REPLICATION GROUP claro_replication_group REFRESH;

Grupy failover: co wnoszą

Rozszerza grupy replikacji o jeden kluczowy element
Konto pomocnicze może przejąć rolę głównego w razie jego awarii
Konto pomocnicze jest zawsze tylko do odczytu
Po promocji staje się zapisywalne i przejmuje rolę źródła danych
Replikuje też obiekty konta: użytkowników, role, magazyny, monitory zasobów

Przykład failover.png

Mechanika planowanego i nieplanowanego failover

Planowany failover – zaplanowany: konto główne degraduje się, pomocnicze awansuje; brak utraty danych
Failover – nieplanowany: konto główne niedostępne, pomocnicze awansuje natychmiast
Replikacja jest asynchroniczna – zmiany po ostatnim odświeżeniu nie są na koncie pomocniczym
Częstotliwość odświeżania to kluczowa decyzja projektowa dla RPO

Przykład failover.png

Czas na ćwiczenia!

Zarządzanie, ład danych i współpraca w Snowflake