Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
DOTYCZY:
NoSQL
MongoDB
Gremlin
Stół
Funkcja przywracania do punktu w czasie usługi Azure Cosmos DB pomaga w wielu scenariuszach, w tym:
- Odzyskiwanie po przypadkowej operacji zapisu lub usuwania w kontenerze.
- Przywracanie usuniętego konta, bazy danych lub kontenera.
- Przywracanie do dowolnego regionu (w którym istniały kopie zapasowe) w punkcie przywracania w czasie.
Usługa Azure Cosmos DB wykonuje kopię zapasową danych w tle bez korzystania z dodatkowej aprowizowanej przepływności (RU) ani wpływu na wydajność i dostępność bazy danych. Ciągłe tworzenie kopii zapasowych jest wykonywane w każdym regionie, w którym istnieje konto. Na przykład konto może mieć region zapisu w regionie Zachodnie stany USA i regiony odczytu w regionach Wschodnie stany USA i Wschodnie stany USA 2. Te regiony repliki można następnie utworzyć kopię zapasową na zdalnym koncie usługi Azure Storage w każdym odpowiednim regionie. Domyślnie każdy region przechowuje kopię zapasową na kontach magazynu lokalnie nadmiarowego. Jeśli region ma włączone strefy dostępności, kopia zapasowa jest przechowywana na kontach magazynowych ze strefową nadmiarowością.
Przedział czasu dostępny do przywrócenia (znany również jako okres przechowywania) to niższa wartość następujących dwóch opcji: 30-dniowa i 7-dniowa.
Wybrana opcja zależy od wybranej warstwy ciągłej kopii zapasowej. Punkt w czasie przywracania może być dowolnym znacznikiem czasu w okresie przechowywania nie dalej niż punkt utworzenia zasobu. W trybie silnej spójności kopie zapasowe wykonywane w regionie zapisu są bardziej aktualne w porównaniu z regionami odczytu. Regiony odczytu mogą opóźnić się z powodu problemów z siecią lub innymi przejściowymi problemami. Podczas przywracania można uzyskać najnowszy znacznik czasu możliwy do przywrócenia dla danego zasobu w określonym regionie. Odwołanie się do najnowszego znacznika czasu możliwego do przywrócenia pomaga potwierdzić, że kopie zapasowe zasobów są do danego znacznika czasu i mogą być przywracane w tym regionie.
Obecnie możesz przywrócić konto usługi Azure Cosmos DB (interfejs API dla noSQL lub MongoDB, interfejs API dla tabel, interfejs API dla języka Gremlin) w określonym punkcie w czasie do innego konta. Tę operację przywracania można wykonać za pośrednictwem witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub szablonów usługi Azure Resource Manager.
Nadmiarowość magazynu kopii zapasowych
Domyślnie usługa Azure Cosmos DB przechowuje dane kopii zapasowej w trybie ciągłym w obiektach blob magazynu lokalnie nadmiarowego. W przypadku regionów, w których skonfigurowano nadmiarowość strefy, kopia zapasowa jest przechowywana w obiektach blob magazynu strefowo nadmiarowego. W trybie ciągłej kopii zapasowej nie można zaktualizować nadmiarowości magazynu kopii zapasowych.
Różne sposoby przywracania
Tryb ciągłej kopii zapasowej obsługuje dwa sposoby przywracania usuniętych kontenerów i baz danych. Można je przywrócić na nowe konto lub na istniejące konto. Wybór między tymi dwoma trybami zależy od scenariuszy. W większości przypadków preferowane jest przywrócenie usuniętych kontenerów i baz danych na istniejącym koncie. Pozwala to uniknąć kosztów transferu danych wymaganych podczas przywracania do nowego konta. W przypadku scenariuszy, w których dokonano przypadkowej modyfikacji danych, przywrócenie do nowego konta może być preferowaną opcją.
Co zostało przywrócone do nowego konta?
W stanie stałym wszystkie mutacje wykonywane na koncie źródłowym (w tym bazy danych, kontenery i elementy) są tworzone asynchronicznie w ciągu 100 sekund. Jeśli nośnik kopii zapasowej usługi Azure Storage nie działa lub jest niedostępny, mutacje są utrwalane lokalnie do momentu udostępnienia nośnika. Następnie mutacje są wypłukiwane, aby zapobiec utracie wierności operacji, które można przywrócić.
Można przywrócić dowolną kombinację kontenerów z aprowizowaną przepływnością, bazę danych z udostępnioną przepływnością lub całe konto. Akcja przywracania przywraca wszystkie dane i właściwości ich indeksu do nowego konta. Proces przywracania gwarantuje, że wszystkie dane przywrócone do konta, bazy danych lub kontenera są spójne do określonego czasu przywracania. Czas trwania przywracania zależy od ilości danych, które należy przywrócić. Nowo przywrócone ustawienie spójności konta bazy danych jest takie samo jak ustawienia spójności źródłowego konta bazy danych.
Uwaga
W trybie ciągłej kopii zapasowej kopie zapasowe są wykonywane w każdym regionie, w którym jest dostępne konto usługi Azure Cosmos DB. Kopie zapasowe tworzone dla każdego konta regionu są domyślnie nadmiarowe lokalnie i strefowo nadmiarowe, jeśli konto ma włączoną funkcję strefy dostępności dla tego regionu. Akcja przywracania zawsze przywraca dane na nowe konto.
Co nie zostało przywrócone?
Następujące konfiguracje nie są przywracane po odzyskiwaniu do punktu w czasie:
- Nie można przywrócić podzbioru kontenerów w bazie danych z udostępnioną przepływnością. Całą bazę danych można przywrócić jako całość.
- Zapora, sieć wirtualna, kontrola dostępu oparta na rolach płaszczyzny danych lub ustawienia prywatnego punktu końcowego.
- Wszystkie regiony z konta źródłowego.
- Procedury składowane, wyzwalacze, funkcje zdefiniowane przez użytkownika.
- Przypisania kontroli dostępu opartej na rolach.
Te konfiguracje można dodać do przywróconego konta po zakończeniu przywracania.
Sygnatura czasowa z możliwością przywracania dla kont na żywo
Aby przywrócić konta na żywo usługi Azure Cosmos DB, które nie zostały usunięte, najlepszym rozwiązaniem jest zawsze identyfikowanie najnowszego znacznika czasu możliwego do przywrócenia dla kontenera. Następnie możesz użyć tego znacznika czasu, aby przywrócić konto do najnowszej wersji.
Scenariusze przywracania
Funkcja przywracania do punktu w czasie obsługuje następujące scenariusze. Scenariusze od 1 do 3 pokazują, jak wyzwolić przywracanie, jeśli znany jest wcześniej znacznik czasu przywracania. Mogą jednak wystąpić scenariusze, w których nie znasz dokładnego czasu przypadkowego usunięcia lub uszkodzenia. Scenariusze 4 i 5 przedstawiają sposób odkrywania znacznika czasu przywracania przy użyciu nowych interfejsów API strumieni zdarzeń na przywracalnej bazie danych lub kontenerach.
Scenariusz 1 — Przywracanie usuniętego konta: wszystkie usunięte konta, które można przywrócić, są widoczne w okienku Przywracanie . Jeśli na przykład konto A zostało usunięte w znaczniku czasu T3. W takim przypadku znacznik czasu tuż przed T3, lokalizacja, nazwa konta docelowego, grupa zasobów i nazwa konta docelowego wystarczy przywrócić z witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia.
Scenariusz 2 — przywracanie danych konta w określonym regionie: na przykład jeśli konto A istnieje w dwóch regionach Wschodnie stany USA i Zachodnie stany USA w czasie T3. Jeśli potrzebujesz kopii konta A w regionie Zachodnie stany USA, możesz wykonać przywracanie do punktu w czasie z witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia z regionem Zachodnie stany USA jako lokalizację docelową.
Scenariusz 3 — odzyskiwanie po przypadkowej operacji zapisu lub usuwania w kontenerze ze znanym znacznikiem czasu przywracania: na przykład jeśli wiesz, że zawartość kontenera 1 w bazie danych 1 została przypadkowo zmodyfikowana w znaczniku czasu T3. Aby odzyskać żądany stan kontenera, możesz wykonać przywracanie do punktu w czasie z portalu Azure, programu PowerShell lub interfejsu wiersza polecenia do innego konta przy użyciu znacznika czasu T3.
Scenariusz 4 — Przywracanie konta do poprzedniego punktu w czasie przed przypadkowym usunięciem bazy danych: w witrynie Azure Portal możesz użyć okienka zestawienia zdarzeń, aby określić, kiedy baza danych została usunięta i znaleźć czas przywracania. Podobnie za pomocą interfejsu wiersza polecenia platformy Azure i programu PowerShell można odnaleźć zdarzenie usuwania bazy danych, wyliczając źródło zdarzeń bazy danych, a następnie wyzwalając polecenie przywracania z wymaganymi parametrami.
Scenariusz 5 — przywracanie konta do poprzedniego punktu w czasie przed przypadkowym usunięciem lub modyfikacją właściwości kontenera: w witrynie Azure Portal możesz użyć okienka zestawienia zdarzeń, aby określić, kiedy kontener został utworzony, zmodyfikowany lub usunięty, aby znaleźć czas przywracania. Podobnie za pomocą interfejsu wiersza polecenia platformy Azure i programu PowerShell można odnaleźć wszystkie zdarzenia kontenera, wyliczając źródło zdarzeń kontenera, a następnie wyzwalając polecenie przywracania z wymaganymi parametrami.
Uprawnienia
Usługa Azure Cosmos DB umożliwia izolowanie i ograniczanie uprawnień przywracania dla konta ciągłej kopii zapasowej do określonej roli lub podmiotu zabezpieczeń. Aby dowiedzieć się więcej, zobacz Zarządzanie uprawnieniami do przywracania konta usługi Azure Cosmos DB.
Omówienie przywracania konta zapisu w wielu regionach
Operacje zapisu wykonywane w regionie centrum są natychmiast potwierdzane i kopie zapasowe są tworzone asynchronicznie w ciągu 100 sekund. W kontach z możliwością wielokrotnego zapisu, wszelkie zmiany przeprowadzane w regionie satelitarnym są wysyłane do regionu centralnego w celu potwierdzenia. Region centrum sprawdza, czy jest potrzebne jakiekolwiek rozwiązanie konfliktów , przypisuje znacznik czasu rozwiązywania konfliktów po rozwiązaniu konfliktów i wysyła dokument z powrotem do regionu satelitarnego. Region satelitarny wykonuje kopię zapasową dokumentów tylko po otrzymaniu potwierdzenia z koncentratora. Krótko mówiąc, proces przywracania przywraca tylko dokumenty potwierdzone przez region centrum przez punkt przywracania.
Co się stanie w przypadku przywracania dla konta z zapisem w wielu regionach?
- Mutacje, które nie zostały jeszcze potwierdzone przez znacznik czasu przywracania, nie zostaną przywrócone.
- Kolekcje z niestandardową zasadą rozwiązywania konfliktów są resetowane do zasady ostatniego, który zapisał, opartej na znaczniku czasu.
Uwaga
Przywracanie z regionu satelitarnego jest wolniejsze w porównaniu z przywracaniem w regionie koncentratora dla konta z wieloma regionami, aby rozpoznać lokalne wstępne zapisy jako potwierdzone lub podjąć działania w celu ich wycofania.
Aby dowiedzieć się więcej na temat znaczników czasowych na koncie z obsługą wielu zapisów, zobacz Zrozumienie znaczników czasowych.
Przykładowy scenariusz: Przy założeniu, że mamy konto z możliwością wielu zapisów w dwóch regionach: Wschodnie Stany USA i Zachodnie Stany USA, z których Wschodnie Stany USA są regionem głównym, należy wziąć pod uwagę następującą sekwencję zdarzeń:
T1: Klient zapisuje dokument Doc1 w regionie Wschodnia część USA (ponieważ Wschodnia część USA jest regionem centralnym, zapis jest natychmiast potwierdzony)
T2: Klient zapisuje dokument Doc2 do Zachodniego USA
T3: Zachodnie USA wysyła Doc2 do Wschodniego USA w celu potwierdzenia
T4: Wschodnie Stany Zjednoczone otrzymały Doc2, potwierdza dokument i wysyła Doc2 z powrotem do Zachodnich Stanów Zjednoczonych.
T5: Zachodnie stany USA otrzymały potwierdzony dokument Doc2
W tym scenariuszu, jeśli podany znacznik czasu przywracania to T3 dla regionu centrum jako źródło, przywracany jest tylko dokument Doc1. Dokument doc2 nie został potwierdzony przez centrum przez T3. Tylko wtedy, gdy sygnatura czasowa przywracania jest większa niż T4, dokument doc2 zostanie przywrócony, ponieważ przywracanie w czasie T4 w satelicie zawiera tylko dokument doc1, gdyż doc2 nie został jeszcze potwierdzony.
Cennik
Konto usługi Azure Cosmos DB z ciągłą 30-dniową kopią zapasową ma dodatkową miesięczną opłatę za przechowywanie kopii zapasowej. Zarówno 30-dniowa, jak i 7-dniowa warstwa ciągłego wycofywania powoduje naliczanie opłat w celu przywrócenia danych. Koszt przywracania jest dodawany za każdym razem, gdy operacja przywracania jest inicjowana. Jeśli skonfigurujesz konto z ciągłą kopią zapasową, ale nie przywracasz danych, w rachunku zostanie uwzględniony tylko koszt magazynu kopii zapasowych.
Poniższy przykład jest oparty na cenie konta usługi Azure Cosmos DB wdrożonego w regionie Zachodnie stany USA. Ceny i obliczenia mogą się różnić w zależności od używanego regionu, zobacz stronę cennika usługi Azure Cosmos DB, aby uzyskać najnowsze informacje o cenach.
Wszystkie konta włączone z zasadami ciągłej kopii zapasowej z 30-dniowymi opłatami są naliczane miesięczne opłaty za magazyn kopii zapasowych obliczany w następujący sposób:
$0.20/GB * Rozmiar danych w GB na koncie * Liczba regionów
Każde wywołanie interfejsu API przywracania powoduje naliczanie jednorazowej opłaty. Opłata jest funkcją ilości przywróconych danych:
$0.15/GB * Rozmiar danych w GB
Jeśli na przykład masz 1 TB danych w dwóch regionach:
Koszt magazynu kopii zapasowych jest obliczany jako 1000 * 0,20 * 2 = 400 USD miesięcznie
Koszt przywracania jest obliczany jako 1000 * 0,15 = 150 USD za przywrócenie
Napiwek
Aby uzyskać więcej informacji na temat mierzenia bieżącego użycia danych konta usługi Azure Cosmos DB, zobacz Eksplorowanie szczegółowych informacji usługi Azure Monitor w usłudze Azure Cosmos DB. Ciągły 7-dniowy poziom nie wiąże się z opłatami za tworzenie kopii zapasowych danych.
Ciągły poziom 30-dniowy vs 7-dniowy
- Okres przechowywania dla jednej warstwy wynosi 30 dni w porównaniu z 7-dniowym okresem dla innej warstwy.
- Opłata za 30-dniową warstwę przechowywania jest naliczana za magazyn kopii zapasowych. Opłata za warstwę przechowywania siedmiodniowego nie jest naliczana.
- Przywracanie jest zawsze naliczane w każdej warstwie
Time to live (Czas wygaśnięcia)
- Domyślny proces przywracania przywraca wszystkie właściwości kontenera, w tym konfigurację TTL. Bez wyłączenia TTL podczas przywracania może to spowodować usunięcie danych. Aby zapobiec usunięciu, przekaż parametr, aby wyłączyć TTL w PowerShell (-DisableTtl $true) lub CLI (--disable-ttl True) podczas przywracania.
Klucze zarządzane przez klienta
Zobacz Jak klucze zarządzane przez klienta wpływają na ciągłe kopie zapasowe , aby dowiedzieć się:
- Jak skonfigurować konto usługi Azure Cosmos DB podczas korzystania z kluczy zarządzanych przez klienta z ciągłymi kopiami zapasowymi.
- Jak klucze zarządzane przez klienta wpływają na przywracanie?
Bieżące ograniczenia
Obecnie funkcja przywracania do punktu w czasie ma następujące ograniczenia:
Interfejsy API usługi Azure Cosmos DB dla baz danych SQL, MongoDB, Gremlin i Table obsługiwane na potrzeby ciągłej kopii zapasowej. Interfejs API dla bazy danych Cassandra nie jest teraz obsługiwany.
Usługa Azure Synapse Link dla kont baz danych korzystających z trybu ciągłej kopii zapasowej jest ogólnie dostępna. Odwrotna sytuacja, czyli tryb ciągłego tworzenia kopii zapasowej dla kont z obsługą usługi Synapse Link, jest w publicznej wersji zapoznawczej. Obecnie klienci, którzy wyłączyli usługę Synapse Link z kontenerów, nie mogą migrować do ciągłej kopii zapasowej. Magazyn analityczny nie jest uwzględniany w kopiach zapasowych. Aby dowiedzieć się więcej, zobacz tworzenie kopii zapasowych magazynu analitycznego.
Przywracane konto jest tworzone w tym samym regionie, w którym znajduje się konto źródłowe. Nie można przywrócić konta do regionu, w którym konto źródłowe nie istnieje.
Okno przywracania wynosi tylko 30 dni dla warstwy ciągłej 30-dniowej i siedem dni dla warstwy ciągłej 7-dniowej. Te warstwy można przełączyć, ale nie można zmienić rzeczywistych ilości (
7lub30). Ponadto w przypadku przejścia z warstwy 30-dniowej na 7-dniową istnieje możliwość utraty danych w dniach poza siódmym.Kopie zapasowe nie są automatycznie odporne na awarie geograficzne. Należy jawnie dodać inny region w celu zapewnienia odporności konta i kopii zapasowej.
Gdy przywracanie jest w toku, nie modyfikuj ani nie usuwaj zasad zarządzania tożsamościami i dostępem (IAM). Te zasady przyznają uprawnienia dla konta na zmianę dowolnej sieci wirtualnej oraz konfiguracji zapory.
Konta usługi Azure Cosmos DB dla bazy danych MongoDB z ciągłą kopią zapasową nie obsługują tworzenia unikatowego indeksu dla istniejącej kolekcji. W przypadku takiego konta unikatowe indeksy muszą być utworzone wraz z tworzeniem kolekcji, co można wykonać wyłącznie przy użyciu poleceń rozszerzenia tworzenia kolekcji.
Po przywróceniu możliwe jest, że w przypadku niektórych kolekcji indeks spójny może zostać odbudowany. Stan operacji odbudowy można sprawdzić za pomocą właściwości IndexTransformationProgress .
Nie można dodawać, aktualizować ani odrzucać unikatowych indeksów w interfejsie API dla bazy danych MongoDB podczas tworzenia konta trybu ciągłej kopii zapasowej. Nie można ich również modyfikować podczas migrowania konta z trybu okresowego do trybu ciągłego.
Przywracanie w trybie ciągłym może nie przywracać ustawienia przepływności prawidłowego dla punktu przywracania.
Następne kroki
- Włączanie ciągłej kopii zapasowej przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia lub usługi Azure Resource Manager
- Przywróć konto kopii zapasowej ciągłej za pomocą witryny Azure Portal, PowerShell, CLI lub Azure Resource Manager
- Pobieranie najnowszej sygnatury czasowej możliwej do przywrócenia dla kont ciągłej kopii zapasowej
- Migrowanie konta z okresowej kopii zapasowej do ciągłej kopii zapasowej
- Zarządzanie uprawnieniami do przywracania konta usługi Azure Cosmos DB
- Model zasobów dla przywracania do punktu w czasie w usłudze Azure Cosmos DB
- Zrozumienie zapisów w wielu regionach w usłudze Azure Cosmos DB
- Opis sygnatur czasowych w usłudze Cosmos DB
- Globalna dystrybucja danych za pomocą usługi Azure Cosmos DB — pod maską