Migrowanie konta usługi Azure Cosmos DB z trybu okresowego do trybu ciągłej kopii zapasowej
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 witryny Azure Portal, 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 ekstentów i zakresó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 wyewidencjonuj również ograniczenia przywracania do punktu w czasie:
- Jeśli konto jest typem interfejsu API dla noSQL, interfejsu API dla tabel, języka Gremlin lub interfejsu API dla bazy danych MongoDB.
- Jeśli konto ma jeden region zapisu.
- Jeśli konto nigdy nie miało wyłączonego usługi Synapse Link dla kontenera.
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 warstwy 30 dni w porównaniu z siedmioma dniami będzie również mieć wpływ 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 pozycję Po zmianie. Po wybraniu docelowego trybu ciągłego wybierz pozycję Zapisz.
Gdy migracja jest w toku, zostanie wyświetlone okno podręczne Aktualizowanie ustawień zasad kopii zapasowej. W przypadku wybrania tego powiadomienia może zostać wyświetlony komunikat Aktualizowanie na poziomie konta i Migrowanie zasad kopii zapasowych w przeglądzie konta. Po zakończeniu zasady tworzenia kopii zapasowych zostałyby przełączone do wybranej warstwy 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.
Aby użyć
Continous7Days
trybu aprowizacji lub migracji, musisz użyć podgląducosmosdb
rozszerzenia. Korzystanie z poleceniaInstall-Module -Name Az.CosmosDB -AllowPrerelease
Następnie uruchom następujące kroki:
Połącz się z kontem platformy Azure:
Connect-AzAccount
Przeprowadź migrację konta z trybu okresowego do trybu ciągłej kopii zapasowej z warstwą
continuous30days
lubcontinuous7days
dniami. Jeśli wartość warstwy nie jest podana, przyjmuje się, że jest tocontinuous30days
: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
Migrowanie konta do
continuous30days
warstwy lubcontinuous7days
. Jeśli wartość warstwy nie jest podana, przyjmuje się, że jest tocontinuous30days
: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 zawierają
backupPolicy
obiekt, który zawieratype
właściwość 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 warstwa nie została podana, warstwa zostanie ustawiona na Continuous30Days
wartość . 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 pokazano, jak wdrożyć szablon za pomocą polecenia interfejsu wiersza polecenia:
az deployment group create -g <ResourceGroup> --template-file <ProvisionTemplateFilePath>
Zmienianie warstw trybu ciągłego
Możesz przełączać się między Continuous30Days
programem Azure Continous7Days
PowerShell, interfejsem wiersza polecenia platformy Azure lub witryną Azure Portal.
W portalu dla danego konta usługi Azure Cosmos DB wybierz okienko Przywracanie do punktu w czasie, wybierz link zmiany obok pozycji Tryb zasad kopii zapasowej, aby wyświetlić opcję Ciągłe (30 dni) lub Ciągłe (7 dni). Wybierz wymagany element docelowy i wybierz pozycję Zapisz.
Następujące polecenie interfejsu wiersza polecenia platformy Azure ilustruje przełączenie istniejącego konta 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 usługi ARM można również użyć w metodzie podobnej do interfejsu wiersza polecenia platformy Azure i programu Azure PowerShell.
Uwaga
W przypadku zmiany warstwy z 30 do 7 dni możliwość przywrócenia więcej niż 7 dni w historii jest natychmiast nie do zaaavaiailable. W przypadku zmiany warstwy z 7 na 30 dni nie będzie można natychmiast przywrócić 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 cen przełączania między warstwami 7 i 30 dni będzie również 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, tryb failover 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 kończy się powodzeniem tylko od momentu pomyślnego zakończenia migracji.
Konto można przywrócić po zakończeniu migracji. Jeśli migracja zakończy się o godzinie 13:00 PST, możesz wykonać przywracanie do punktu w czasie, począwszy od godziny 13:00 PST.
Często zadawane pytania
Czy migracja ma miejsce tylko na poziomie konta?
Tak.
Które konta mogą być przeznaczone do migracji kopii zapasowych?
Obecnie interfejs API dla noSQL, interfejs API dla tabel, interfejs API języka Gremlin i interfejs API dla kont bazy danych MongoDB z pojedynczym regionem zapisu, w którym udostępniono, aprowizowaną lub automatycznie aprowizowaną przepływność.
Konta włączone w wielu regionach zapisu nie są obsługiwane w przypadku migracji.
Obecnie konta z włączoną usługą Synapse Link, które miały 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 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ę wykonać przywracanie do znacznika czasu przed/podczas/po migracji?
Załóżmy, że rozpoczęto migrację o godzinie t1
i zakończono od 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 witryny Azure Portal, interfejsu wiersza polecenia lub programu PowerShell, tak jak zwykle przy użyciu konta ciągłego. To żądanie samoobsługowego przywracania można wykonać tylko po zakończeniu migracji.
Aby przywrócić do czasu przed t1
godziną , możesz otworzyć bilet pomocy technicznej, tak jak zwykle, przy użyciu okresowego konta kopii zapasowej. Po migracji trzeba wykonać okresowe przywracanie do 30 dni. 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 w przypadku problemu bazowego, nadal będzie blokować operację płaszczyzny sterowania, dopóki nie zostanie ponowiona i zakończona pomyślnie?
Migracja 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ą.
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 przebiegi skalowania wskazują, że jedno konto regionu z 1 TB danych trwa około 90 minut.
W przypadku kont z wieloma regionami oblicz łączny rozmiar danych jako Number_of_regions * Data_in_single_region
.
Ponieważ tryb ciągłej kopii zapasowej jest teraz ogólnie dostępny, czy nadal zaleca się przywrócenie kopii konta? Czy zaleca się wypróbowanie migracji na kopię przed podjęciem decyzji o migracji konta produkcyjnego?
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: