Migrowanie konta usługi Azure Cosmos DB z trybu okresowego do trybu ciągłej kopii zapasowej

2025-04-10

DOTYCZY: NoSQL MongoDB Gremlin Stół

Konta usługi Azure Cosmos DB z zasadami tworzenia kopii zapasowych w trybie okresowym można migrować do trybu ciągłego przy użyciu witryny Azure Portal, interfejsu wiersza polecenia, programu PowerShell lub szablonów usługi Resource Manager. Migracja z trybu okresowego do trybu ciągłego jest migracją jednokierunkową i jest nieodwracalna. Po migracji z trybu okresowego do trybu ciągłego można zastosować zalety trybu ciągłego.

Poniżej przedstawiono najważniejsze powody, aby przeprowadzić migrację do trybu ciągłego:

Możliwość przywracania samoobsługowego przy użyciu portalu Azure, interfejsu wiersza polecenia lub programu PowerShell.
Możliwość przywracania w czasie szczegółowości sekundy w ciągu ostatnich 30 dni lub 7 dni.
Możliwość upewnienia się, że kopia zapasowa jest spójna w obrębie fragmentów i obszarów kluczy partycji w danym okresie.
Możliwość przywracania kontenera, bazy danych lub pełnego konta po jego usunięciu lub zmodyfikowaniu.
Możliwość wyboru zdarzeń w kontenerze, bazie danych lub na koncie i podjęcia decyzji, kiedy przywracanie ma zostać zainicjowane.

Uwaga

Możliwość migracji jest tylko jednokierunkowa i jest nieodwracalną akcją. Oznacza to, że po przeprowadzeniu migracji z trybu okresowego do trybu ciągłego nie można przełączyć się z powrotem do trybu okresowego.

Konto można migrować do trybu ciągłej kopii zapasowej tylko wtedy, gdy spełnione są następujące warunki. Przed migracją konta zapoznaj się także z ograniczeniami przywracania do wcześniejszego punktu w czasie:

Jeśli konto jest typu API dla NoSQL, API dla tabel, Gremlin lub API dla MongoDB.

Jeśli konto nigdy nie miało wyłączonej usługi Synapse Link dla pojemnika.

Jeśli konto korzysta z kluczy zarządzanych przez klienta, tożsamość zarządzana (przypisana przez system lub przypisana przez użytkownika) musi być zadeklarowana w zasadach dostępu usługi Key Vault i musi być ustawiona jako tożsamość domyślna na koncie.

Uprawnienia

Aby przeprowadzić migrację, musisz mieć Microsoft.DocumentDB/databaseAccounts/write uprawnienia do migrowanego konta.

Cennik po migracji

Po przeprowadzeniu migracji konta do trybu ciągłej kopii zapasowej koszt może ulec zmianie w porównaniu z okresowym trybem tworzenia kopii zapasowej. Wybór między opcją trzydziestu dni a siedmiu dni również wpłynie na koszt tworzenia kopii zapasowej. Aby dowiedzieć się więcej, zobacz cennik trybu ciągłej kopii zapasowej.

Migrowanie przy użyciu portalu

Wykonaj następujące kroki, aby przeprowadzić migrację konta z okresowej kopii zapasowej do trybu ciągłej kopii zapasowej:

Zaloguj się w witrynie Azure Portal.
Przejdź do konta usługi Azure Cosmos DB i otwórz okienko Tworzenie kopii zapasowych i przywracanie . Wybierz kartę Zasady tworzenia kopii zapasowych i wybierz zmień. Po wybraniu docelowego trybu ciągłego wybierz pozycję Zapisz.
Gdy migracja jest w toku, zostanie wyświetlone okno dialogowe Aktualizowanie ustawień zasad kopii zapasowej. W przypadku wybrania tego powiadomienia może zostać wyświetlony komunikat Aktualizowanie na poziomie konta i Migrowanie polityki kopii zapasowej w przeglądzie konta. Po zakończeniu, polityka tworzenia kopii zapasowych zostałaby przełączona na wybrany poziom trybu ciągłego. Czas migracji zależy od rozmiaru danych na twoim koncie.

Migrowanie przy użyciu programu PowerShell

Zainstaluj najnowszą wersję programu Azure PowerShell lub dowolną wersję wyższą niż 6.2.0.
Następnie uruchom następujące kroki:
1. Połącz się z kontem platformy Azure:
```
Connect-AzAccount
```
2. Przeprowadź migrację konta z trybu okresowego do trybu ciągłego tworzenia kopii zapasowych przy użyciu poziomu continuous30days lub continuous7days dni. Jeśli wartość warstwy nie jest podana, przyjmuje się, że jest to continuous30days:
```
Update-AzCosmosDBAccount ` 
   -ResourceGroupName "myrg" ` 
   -Name "myAccount" `
   -BackupPolicyType "Continuous"
```
```
   Update-AzCosmosDBAccount ` 
   -ResourceGroupName "myrg" ` 
   -Name "myAccount" `
   -BackupPolicyType "Continuous" `
   -ContinuousTier "Continuous7Days"
```

Migrowanie przy użyciu interfejsu wiersza polecenia

Zainstaluj najnowszą wersję interfejsu wiersza polecenia platformy Azure:

Jeśli nie masz jeszcze zainstalowanego interfejsu wiersza polecenia platformy Azure, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure. Alternatywnie możesz również użyć usługi Azure Cloud Shell w witrynie Azure Portal.

Zaloguj się do konta platformy Azure i uruchom następujące polecenie, aby przeprowadzić migrację konta do trybu ciągłego:
```
az login
```

Zmigruj konto do warstwy continuous30days lub continuous7days. Jeśli wartość warstwy nie jest podana, przyjmuje się, że jest to continuous30days:

az cosmosdb update -n <myaccount> -g <myresourcegroup> --backup-policy-type continuous

az cosmosdb update -g "my-rg" -n "my-continuous-backup-account" --backup-policy-type "Continuous" --continuous-tier "Continuous7Days"

Po pomyślnym zakończeniu migracji dane wyjściowe pokazują obiekt backupPolicy, który zawiera właściwość type z wartością Continuous.

 {
   "apiProperties": null,
   "backupPolicy": {
        "continuousModeProperties": {
                "tier": "Continuous7Days"
        },
        "migrationState": null,
        "type": "Continuous"
   },
      …
 }

Sprawdzanie stanu migracji

Uruchom następujące polecenie i sprawdź stan i właściwości targetType obiektu backupPolicy. Stan jest wyświetlany w toku po rozpoczęciu migracji:

az cosmosdb show -n "myAccount" -g "myrg"

Po zakończeniu migracji typ kopii zapasowej zmienia się na Ciągły i pokazuje wybraną warstwę. Jeśli poziom nie został podany, poziom zostałby ustawiony na Continuous30Days. Uruchom ponownie to samo polecenie, aby sprawdzić stan:

az cosmosdb show -n "myAccount" -g "myrg"

Migrowanie z trybu okresowego do trybu ciągłego przy użyciu szablonu usługi Resource Manager

Aby przeprowadzić migrację do trybu ciągłej kopii zapasowej przy użyciu szablonu usługi ARM, znajdź sekcję backupPolicy szablonu i zaktualizuj type właściwość. Jeśli na przykład istniejący szablon ma zasady tworzenia kopii zapasowych, takie jak następujący obiekt JSON:

"backupPolicy": {
   "type": "Periodic",
   "periodicModeProperties": {
   "backupIntervalInMinutes": 240,
   "backupRetentionIntervalInHours": 8
   }
}

Zastąp go następującym obiektem JSON:

"backupPolicy": { 
   "type": "Continuous", 
   "continuousModeProperties": { 
      "tier": "Continuous7Days" 
    } 
}

Następnie wdróż szablon przy użyciu programu Azure PowerShell lub interfejsu wiersza polecenia. W poniższym przykładzie pokaże, jak wdrożyć szablon za pomocą polecenia CLI:

az deployment group create -g <ResourceGroup> --template-file <ProvisionTemplateFilePath>

Zmienianie poziomów trybu ciągłego

Możesz przełączać się między Continuous30Days a Continous7Days za pomocą Azure PowerShell, Azure CLI lub portalu Azure.

W portalu dla danego konta usługi Azure Cosmos DB wybierz panel Przywracanie do Punktu w Czasie, kliknij link zmiany obok pozycji Tryb zasad kopii zapasowej, aby wyświetlić opcje Ciągłe (30 dni) lub Ciągłe (7 dni). Wybierz wymagany element docelowy i wybierz pozycję Zapisz.

Następujące polecenie Azure CLI ilustruje, jak przełączyć istniejące konto na Continous7Days:

az cosmosdb update \ 
    --resource-group "my-rg" \ 
    --name "my-continuous-backup-account" \ 
    --backup-policy-type "Continuous" \ 
    --continuous-tier "Continuous7Days"

Następujące polecenie programu Azure PowerShell ilustruje przełączenie istniejącego konta na Continous7Days:

Update-AzCosmosDBAccount ` 
    -ResourceGroupName "myrg" ` 
    -Name "myAccount" `
    -BackupPolicyType Continuous `
    -ContinuousTier Continuous7Days

Szablon ARM można również używać w sposób podobny do Azure CLI i Azure PowerShell.

Uwaga

W przypadku zmiany warstwy z 30 na 7 dni, możliwość przywrócenia więcej niż 7 dni historii jest natychmiast niedostępna. Przy zmianie z poziomu 7 dni na 30 dni, nie będzie można natychmiast przywrócić danych z więcej niż 7 dni. Najwcześniejszy czas przywracania można wyodrębnić z metadanych konta dostępnych za pośrednictwem programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure. Wpływ cenowy przełączania między poziomami 7 i 30 dni będzie natychmiast widoczny.

Czego można oczekiwać podczas migracji i po migracji?

Podczas migracji z trybu okresowego do trybu ciągłego nie można uruchamiać żadnych operacji płaszczyzny sterowania, które wykonują aktualizacje lub usuwanie na poziomie konta. Na przykład operacje takie jak dodawanie lub usuwanie regionów, przełączenie awaryjne konta, aktualizowanie zasad kopii zapasowej itp. nie mogą być uruchamiane, gdy migracja jest w toku. Czas migracji zależy od rozmiaru danych i liczby regionów na twoim koncie. Akcja przywracania na zmigrowanych kontach powiedzie się dopiero po pomyślnym zakończeniu migracji.

Konto można przywrócić po zakończeniu migracji. Jeśli migracja zakończy się o godzinie 13:00 czasu PST, możesz rozpocząć przywracanie danych do stanu z określonego momentu, począwszy od godziny 13:00 czasu PST.

Często zadawane pytania

Czy migracja ma miejsce tylko na poziomie konta?

Tak.

Które konta mogą być wytypowane do migracji w ramach ciągłego tworzenia kopii zapasowej?

Obecnie obsługiwane są interfejsy API dla baz danych NoSQL, interfejsy API dla tabel, interfejsy API języka Gremlin oraz interfejsy API dla kont MongoDB, które mają udostępnioną, aprowizowaną lub automatycznie aprowizowaną przepustowość wspierającą migrację.

Konta z włączoną usługą Synapse Link lub z wyłączoną usługą Synapse Link dla co najmniej jednej kolekcji nie mogą migrować do ciągłej kopii zapasowej.

Czy migracja zajmuje trochę czasu? Jaki jest typowy czas?

Migracja zajmuje różny czas, który w dużej mierze zależy od rozmiaru danych i liczby regionów na twoim koncie. Stan migracji można uzyskać przy użyciu interfejsu wiersza polecenia platformy Azure lub poleceń programu PowerShell. W przypadku dużych kont z dziesiątkami terabajtów danych migracja może potrwać do kilku dni.

Czy migracja konta zapisu w wielu regionach z okresową kopią zapasową do zapisu w wielu regionach z ciągłym tworzeniem kopii zapasowej zajmuje trochę czasu?

Tak, ta migracja wymaga czasu, który w dużej mierze zależy od konieczności poczekania, aż wszystkie stare tymczasowe zapisy zostaną usunięte podczas ciągłej migracji kopii zapasowej. Stan migracji można uzyskać przy użyciu interfejsu wiersza polecenia platformy Azure lub poleceń programu PowerShell. W przypadku dużych kont z dziesiątkami terabajtów danych migracja może potrwać do kilku dni.

Czy migracja powoduje jakikolwiek wpływ na dostępność/przestój?

Nie, operacja migracji odbywa się w tle. W związku z tym żądania klientów nie mają wpływu. Jednak musimy wykonać pewne operacje zaplecza podczas migracji i może upłynąć dodatkowy czas, jeśli konto jest obciążone dużym obciążeniem.

Co się stanie, jeśli migracja zakończy się niepowodzeniem? Czy nadal będę otrzymywać okresowe kopie zapasowe lub pobierać ciągłe kopie zapasowe?

Po uruchomieniu procesu migracji konto zostanie włączone w trybie ciągłym. Jeśli migracja zakończy się niepowodzeniem, należy ponownie zainicjować migrację, dopóki nie zakończy się pomyślnie.

Jak mogę przywrócić system do stanu z określonym znacznikiem czasu przed, w trakcie lub po migracji?

Załóżmy, że rozpoczęto migrację o godzinie t1 i zakończono o t5, nie można użyć znacznika czasu przywracania między t1 i t5.

Załóżmy również, że Twoje konto jest teraz w trybie ciągłym. Aby przywrócić do czasu po t5, wykonaj przywracanie przy użyciu portalu Azure, CLI lub PowerShell tak, jak zwykle z kontem ciągłym. Żądanie samoobsługowego przywracania można wykonać tylko po zakończeniu migracji.

Aby przywrócić stan sprzed t1, możesz otworzyć zgłoszenie do pomocy technicznej, tak jak zwykle, korzystając z konta do kopii zapasowej zgodnie z harmonogramem. Po migracji masz do 30 dni na wykonanie okresowego przywracania. W ciągu tych 30 dni można przywrócić dane na podstawie okresu przechowywania/interwału kopii zapasowych konta przed migracją. Jeśli na przykład kopia zapasowa została skonfigurowana do przechowywania 24 kopii w 1 godzinach, można przywrócić je w dowolnym czasie między (t1 – 24 hours) i t1.

Które operacje płaszczyzny kontroli na poziomie konta są blokowane podczas migracji?

Operacje, takie jak dodawanie/usuwanie regionu, tryb failover, zmiana zasad tworzenia kopii zapasowych i wszelkie zmiany przepływności powodujące przenoszenie danych są blokowane podczas migracji.

Jeśli migracja zakończy się niepowodzeniem z powodu podstawowego problemu, czy nadal będzie blokować działanie płaszczyzny sterowania, dopóki nie zostanie ponowiona i zakończona pomyślnie?

Migracja, która nie powiodła się, nie spowoduje zablokowania żadnych operacji płaszczyzny sterowania. Jeśli migracja zakończy się niepowodzeniem, zaleca się ponowienie próby, dopóki nie powiedzie się przed wykonaniem innych operacji płaszczyzny sterowania.

Czy można anulować migrację?

Nie można anulować migracji, ponieważ migracje nie są operacją odwracalną. Zespół wsparcia technicznego może tymczasowo anulować operacje, aby umożliwić kontynuację działań w trybie offline. Nie można jednak wrócić do okresowego stanu kopii zapasowej.

Czy istnieje narzędzie, które może pomóc oszacować czas migracji na podstawie użycia danych i liczby regionów?

Nie ma narzędzia do szacowania czasu. Nasze testy i próby skalowania wskazują, że przetwarzanie konta z 1 TB danych zajmuje około 90 minut.

W przypadku kont z wieloma regionami oblicz łączny rozmiar danych jako Number_of_regions * Data_in_single_region.

Zaleca się przetestowanie funkcji trybu ciągłej kopii zapasowej, aby zobaczyć, że działa zgodnie z oczekiwaniami przed migracją kont produkcyjnych. Migracja jest operacją jednokierunkową i nie jest odwracalna.

Następne kroki

Aby dowiedzieć się więcej na temat trybu ciągłej kopii zapasowej, zobacz następujące artykuły:

Wprowadzenie do trybu ciągłej kopii zapasowej z przywracaniem do wybranego momentu w czasie.
Model zasobów trybu ciągłej kopii zapasowej.
Przywróć konto przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia lub usługi Azure Resource Manager.