Migrowanie przy użyciu usługi ponownego odtwarzania dziennika (LRS)
Usługa ponownego odtwarzania dzienników (LRS) to narzędzie, które umożliwia niestandardowe migracje baz danych z lokalnych serwerów SQL do usługi SQL Managed Instance w chmurze. Korzysta ona z technologii wysyłania dzienników i jest przydatna w przypadkach, gdy potrzebna jest większa kontrola, gdy występuje niewielka tolerancja przestoju lub gdy usługa Azure Data Migration Service nie może być używana.
Magazyn LRS może być używany bezpośrednio z programem PowerShell, poleceniami cmdlet interfejsu wiersza polecenia lub interfejsem API w celu ręcznego kompilowania i organizowania migracji baz danych do usługi SQL Managed Instance. Oto niektóre z powodów, dla których warto rozważyć użycie magazynu LRS:
- Większa kontrola nad projektem migracji bazy danych
- Niewielka tolerancja przestojów w przypadku migracji jednorazowej
- Brak możliwości zainstalowania pliku wykonywalnego DMS w środowisku
- Brak dostępu do plików do kopii zapasowych bazy danych
- Brak możliwości otwierania portów sieciowych ze środowiska do platformy Azure
Omówienie typów migracji
Istnieją dwa tryby migracji dostępne dla magazynu LRS.
| Tryb | opis | Zalecane dla | Dostępność łańcucha kopii zapasowych |
|---|---|---|---|
| Autouzupełnianie | Automatycznie kończy migrację po przywróceniu ostatniego pliku kopii zapasowej | Obciążenia pasywne | Cały łańcuch kopii zapasowych musi być dostępny z wyprzedzeniem |
| Ciągłe | Stale skanuje pod kątem nowych plików kopii zapasowych i przywraca je, co pozwala na nadrobienie zaległości danych | Aktywne obciążenia | Łańcuch kopii zapasowych można dodać podczas migracji |
Niezależnie od trybu zaplanuj ukończenie migracji w ciągu 30 dni, ponieważ zadanie LRS zostanie automatycznie anulowane po tym czasie.
Zabezpieczanie procesu migracji
Aby uruchomić magazyn LRS, musisz mieć jedną z następujących ról roli kontroli dostępu na podstawie ról (RBAC): Właściciel subskrypcji, Współautor wystąpienia zarządzanego SQL lub rola niestandardowa z uprawnieniem Microsoft.Sql/managedInstances/databases/*.
Wymagane jest konto usługi Azure Blob Storage i działa jako pośredni magazyn plików kopii zapasowych między wystąpieniem programu SQL Server i wystąpieniem zarządzanym SQL. Aby korzystać z usługi Azure Blob Storage z zaporą, wymagana jest inna konfiguracja. Należy dodać podsieć wystąpienia zarządzanego SQL do reguł zapory sieci wirtualnej konta magazynu przy użyciu delegowania podsieci MI i punktu końcowego usługi Storage. Ponadto możesz użyć tokenu SAS lub tożsamości zarządzanej, aby uzyskać dostęp do konta usługi Azure Blob Storage, ale nie obu tych elementów.
Zwiększanie wydajności tworzenia kopii zapasowych i przywracania
Możesz podzielić pełne i różnicowe kopie zapasowe na wiele plików, zamiast używać jednego pliku, aby zwiększyć wydajność tworzenia kopii zapasowych i przywracania. Dzieje się tak, ponieważ wiele plików można odczytywać lub zapisywać równolegle, skracając czas potrzebny na ukończenie operacji tworzenia kopii zapasowej lub przywracania.
Ponadto włączenie kompresji kopii zapasowej może pomóc zwiększyć szybkość transferu sieciowego. Skompresowane kopie zapasowe mają mniejszy rozmiar, co oznacza, że transfer przez sieć zajmuje mniej czasu. Może to być szczególnie przydatne podczas przenoszenia dużych kopii zapasowych do lub z platformy Azure.
Zdecydowanie zalecamy włączenie CHECKSUM kopii zapasowych, nawet jeśli nie jest to wymagane. Usługa SQL Managed Instance przeprowadza sprawdzanie integralności kopii zapasowych bez CHECKSUMelementu , co może zwiększyć czas potrzebny na przywrócenie bazy danych. Włączając funkcję CHECKSUM, można przyspieszyć operacje przywracania.