Artikel ini mengajarkan anda cara melakukan failover atas database yang ditautkan antara SQL Server dan Azure SQL Managed Instance dengan menggunakan SQL Server Management Studio (SSMS) atau PowerShell untuk tujuan pemulihan bencana atau migrasi.
Prasyarat
Untuk mengalihkan database ke replika sekunder Anda melalui tautan, Anda memerlukan prasyarat berikut:
Langganan Azure aktif. Jika Anda tidak memilikinya, buat akun gratis.
Versi SQL Server yang didukung dengan pembaruan layanan yang diperlukan terinstal.
Tautan dikonfigurasi antara replika utama dan sekunder Anda.
Jika Anda siap untuk melakukan failover database ke replika sekunder, pertama-tama hentikan beban kerja aplikasi apa pun pada replika utama selama jam pemeliharaan Anda. Ini memungkinkan replikasi database mengejar ketinggalan pada sekunder sehingga Anda dapat melakukan failover ke sekunder tanpa kehilangan data. Pastikan aplikasi Anda tidak melakukan transaksi ke primer sebelum failover.
Mengalihkan database
Anda dapat melakukan failover pada database tertaut dengan menggunakan Transact-SQL (T-SQL), SQL Server Management Studio, atau PowerShell.
Untuk melakukan failover terencana untuk tautan, gunakan perintah T-SQL berikut pada replika utama:
ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER
Untuk melakukan failover paksa, gunakan perintah T-SQL berikut pada replika sekunder:
ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS
Gunakan Failover antara SQL Server dan wizard Instans Terkelola di SSMS untuk mengalihkan database Anda dari replika utama ke sekunder Anda.
Anda dapat melakukan failover yang direncanakan dari replika utama atau sekunder. Untuk melakukan failover paksa, sambungkan ke replika sekunder.
Perhatian
Sebelum failover, hentikan beban kerja pada database sumber untuk memungkinkan database yang direplikasi benar-benar mengejar dan melakukan failover tanpa kehilangan data. Jika Anda melakukan failover paksa, Anda dapat kehilangan data.
Failover database di SQL Server 2019 dan versi yang lebih lama putus dan menghapus tautan antara dua replika. Anda tidak dapat melakukan failback ke primer awal.
Untuk melakukan failover pada database Anda, ikuti langkah-langkah berikut:
Buka SSMS dan sambungkan ke salah satu replika.
Di Object Explorer, klik kanan database Anda yang direplikasi, arahkan mouse ke tautan Azure SQL Managed Instance, dan pilih Failover... untuk membuka Failover antara SQL Server dan wizard Instans Terkelola. Jika Anda memiliki beberapa tautan dari database yang sama, perluas Grup Ketersediaan di bawah grup ketersediaan AlwaysOn di Object Explorer dan klik kanan grup ketersediaan terdistribusi untuk tautan yang ingin Anda failover. Pilih Failover... untuk membuka Failover antara SQL Server dan wizard Instans Terkelola untuk tautan tertentu tersebut.
Di halaman Pengenalan, pilih Berikutnya.
Halaman Pilih jenis failover memperlihatkan kepada Anda detail tentang setiap replika, peran database yang Anda pilih, dan jenis failover yang didukung. Anda dapat memulai failover dari replika apa pun. Jika Anda memilih failover paksa, Anda harus mencentang kotak untuk menunjukkan bahwa Anda memahami mungkin ada potensi kehilangan data. Pilih Selanjutnya.
Catatan
Jika Anda bermigrasi ke Azure SQL Managed Instance, pilih Failover terencana.
Pada halaman Masuk ke Azure dan Instans Jarak Jauh:
Pilih Masuk untuk memberikan kredensial Anda dan masuk ke akun Azure Anda.
Berdasarkan jenis Failover yang dipilih pada halaman sebelumnya, opsi Masuk berfungsi secara berbeda. Untuk failover yang direncanakan, masuk ke instans jarak jauh (baik SQL Server atau SQL Managed Instance) adalah wajib. Untuk failover paksa, penandatanganan bersifat opsional karena dua skenario berikut didukung:
Pemulihan bencana yang sebenarnya: Karena instans utama biasanya tidak tersedia selama bencana sejati, masuk tidak dimungkinkan, dan pengguna harus segera melakukan failover ke instans sekunder, menjadikannya instans utama baru. Setelah pemadaman diselesaikan, tautan dalam keadaan tidak konsisten karena kedua replika sekarang berada dalam peran utama (skenario split-brain).
Latihan pemulihan bencana: Melakukan latihan pemulihan bencana dengan failover paksa tidak disarankan karena mungkin ada potensi kehilangan data. Namun, selama latihan, karena instans utama tersedia, masuk didukung, dan Anda diberi opsi untuk membalikkan peran untuk kedua replika untuk menghindari skenario split-brain.
Pada halaman Operasi Pasca-Failover, opsi berbeda antara SQL Server 2022 dan versi yang lebih lama, dan apakah Anda dapat tersambung ke instans utama atau tidak.
Untuk SQL Server 2022, Anda dapat memilih untuk menghentikan replikasi antara replika, yang menghilangkan tautan dan grup ketersediaan terdistribusi setelah failover selesai. Jika Anda ingin mempertahankan tautan dan melanjutkan replikasi data antar replika, biarkan kotak tidak dicentang. Jika Anda memilih untuk menjatuhkan tautan, Anda juga dapat mencentang kotak untuk menghilangkan grup ketersediaan jika Anda membuatnya hanya untuk tujuan mereplikasi database Anda ke Azure dan Anda tidak lagi membutuhkannya. Centang kotak yang sesuai dengan skenario Anda, lalu pilih Berikutnya.
Untuk SQL Server 2019 dan versi yang lebih lama, opsi untuk Menghapus tautan dicentang secara default, dan Anda tidak dapat menghapus centang karena failover ke SQL Managed Instance menghentikan replikasi, memutus tautan, dan menghilangkan grup ketersediaan terdistribusi. Centang kotak untuk menunjukkan bahwa Anda memahami tautan akan dihilangkan, lalu pilih Berikutnya.
(Opsional) Jika Anda dapat masuk ke instans SQL Server di halaman sebelumnya, Anda juga memiliki opsi untuk menghapus grup ketersediaan pada instans SQL Server setelah failover paksa dengan mencentang kotak di bagian Pembersihan .
Pada halaman Ringkasan , tinjau tindakan. Secara opsional, pilih Skrip untuk menghasilkan skrip sehingga Anda dapat dengan mudah melakukan failover pada database menggunakan tautan yang sama di masa mendatang. Pilih Selesai saat Anda siap untuk melakukan failover pada database.
Setelah seluruh langkah selesai, halaman Hasil menampilkan tanda centang di samping tindakan yang berhasil diselesaikan. Kini Anda dapat menutup jendela.
Jika Anda memilih untuk mempertahankan tautan untuk SQL Server 2022, sekunder menjadi primer baru, tautan masih aktif dan Anda dapat gagal kembali ke sekunder.
Jika Anda menggunakan SQL Server 2019 dan versi yang lebih lama, atau jika Anda memilih untuk menghapus tautan untuk SQL Server 2022, tautan dihilangkan dan tidak ada lagi setelah failover selesai. Database sumber dan database target pada setiap replika dapat menjalankan beban kerja baca/tulis. Database SQL Server sumber dan database SQL Managed Instance benar-benar independen.
Penting
Setelah berhasil melakukan failover ke SQL Managed Instance, arahkan ulang aplikasi Anda secara manual string koneksi ke FQDN instans terkelola SQL untuk menyelesaikan proses migrasi atau failover dan terus berjalan di Azure.
Untuk melakukan failover, Pertama-tama Anda harus mengalihkan mode replikasi instans SQL Server dengan menggunakan Transact-SQL (T-SQL).
Kemudian, Anda dapat melakukan failover dan beralih peran dengan menggunakan PowerShell.
Beralih mode replikasi (Failover ke SQL MI)
Replikasi antara SQL Server dan SQL Managed Instance tidak sinkron secara default. Jika Anda melakukan failover dari SQL Server ke Azure SQL Managed Instance, sebelum Anda melakukan failover pada database, alihkan tautan ke mode sinkron di SQL Server dengan menggunakan Transact-SQL (T-SQL).
Catatan
Lewati langkah ini jika Anda melakukan failover dari SQL Managed Instance ke SQL Server 2022.
Replikasi sinkron di seluruh jarak jaringan yang besar mungkin memperlambat transaksi pada replika utama.
Jalankan skrip T-SQL berikut di SQL Server untuk mengubah mode replikasi grup ketersediaan terdistribusi dari asinkron ke sinkronisasi. Mengganti:
<DAGName> dengan nama grup ketersediaan terdistribusi (digunakan untuk membuat tautan).
<AGName> dengan nama grup ketersediaan yang dibuat di SQL Server (digunakan untuk membuat tautan).
<ManagedInstanceName> dengan nama instans terkelola Anda.
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>]
MODIFY
AVAILABILITY GROUP ON
'<AGName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
'<ManagedInstanceName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
Untuk mengonfirmasi bahwa Anda telah berhasil mengubah mode replikasi link, gunakan tampilan manajemen dinamis berikut. Hasil menunjukkan status SYNCHRONOUS_COMMIT.
-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
ag.name, ag.is_distributed, ar.replica_server_name,
ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
ars.operational_state_desc, ars.synchronization_health_desc
FROM
sys.availability_groups ag
join sys.availability_replicas ar
on ag.group_id=ar.group_id
left join sys.dm_hadr_availability_replica_states ars
on ars.replica_id=ar.replica_id
WHERE
ag.is_distributed=1
Sekarang setelah Anda mengalihkan SQL Server ke mode penerapan sinkron, replikasi antara dua instans sinkron. Jika Anda perlu membalikkan status ini, ikuti langkah yang sama dan atur ke AVAILABILITY_MODEASYNCHRONOUS_COMMIT.
Periksa nilai LSN pada SQL Server dan SQL Managed Instance
Untuk menyelesaikan failover atau migrasi, konfirmasikan bahwa replikasi ke sekunder telah selesai. Untuk ini, pastikan nomor urutan log (LSN) dalam catatan log untuk SQL Server dan SQL Managed Instance sama.
Awalnya, diharapkan bahwa LSN pada primer lebih tinggi daripada LSN pada sekunder. Latensi jaringan dapat menyebabkan replikasi tertinggal agak di belakang primer. Karena beban kerja telah dihentikan pada primer, LSN akan cocok dan berhenti berubah setelah beberapa waktu.
Gunakan kueri T-SQL berikut di SQL Server untuk membaca LSN dari log transaksi terakhir yang direkam. Ganti:
<DatabaseName> dengan nama database Anda dan cari nomor LSN terakhir yang diperkeras.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
ag.name AS [Replication group],
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
ag.is_distributed = 1 and db.name = '<DatabaseName>'
Gunakan kueri T-SQL berikut pada SQL Managed Instance untuk membaca LSN terakhir yang diperketat untuk database Anda. Ganti <DatabaseName> dengan nama database Anda.
Kueri ini berfungsi pada General Purpose SQL Managed Instance. Untuk Business Critical SQL Managed Instance, hapus komentar and drs.is_primary_replica = 1 di akhir skrip. Pada tingkat layanan Business Critical, filter ini memastikan bahwa detail hanya dibaca dari replika utama.
-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
WHERE
db.name = '<DatabaseName>'
-- for Business Critical, add the following as well
-- AND drs.is_primary_replica = 1
Atau, Anda juga dapat menggunakan perintah Get-AzSqlInstanceLink PowerShell atau az sql mi link show Azure CLI untuk mengambil LastHardenedLsn properti untuk tautan Anda di SQL Managed Instance untuk memberikan informasi yang sama dengan kueri T-SQL sebelumnya.
Penting
Verifikasi sekali lagi bahwa beban kerja Anda dihentikan pada primer. Periksa apakah LSN pada SQL Server dan SQL Managed Instance cocok, dan bahwa LSN tetap cocok dan tidak berubah selama beberapa waktu. LSN stabil pada kedua instans menunjukkan log ekor telah direplikasi ke sekunder dan beban kerja secara efektif dihentikan.
Mengalihkan database
Jika Anda ingin menggunakan PowerShell untuk melakukan failover database antara SQL Server 2022 dan SQL Managed Instance saat masih mempertahankan tautan, atau untuk melakukan failover dengan kehilangan data untuk versi SQL Server apa pun, gunakan Wizard Failover antara SQL Server dan Managed Instance di SSMS untuk menghasilkan skrip untuk lingkungan Anda. Anda dapat melakukan failover yang direncanakan dari replika utama atau sekunder. Untuk melakukan failover paksa, sambungkan ke replika sekunder.
Untuk memutuskan tautan dan menghentikan replikasi saat Anda melakukan failover atau memigrasikan database Anda terlepas dari versi SQL Server, gunakan perintah Hapus-AzSqlInstanceLink PowerShell atau tautan az sql mi hapus Azure CLI.
Perhatian
Sebelum failover, hentikan beban kerja pada database sumber untuk memungkinkan database yang direplikasi benar-benar mengejar dan failover tanpa kehilangan data. Jika Anda melakukan failover paksa, atau jika Anda memutuskan tautan sebelum LSN cocok, Anda mungkin kehilangan data.
Failover database di SQL Server 2019 dan versi yang lebih lama putus dan menghapus tautan antara dua replika. Anda tidak dapat melakukan failback ke primer awal.
Contoh skrip berikut memutus tautan dan mengakhiri replikasi antara replika Anda, membuat database dibaca/ditulis pada kedua instans. Ganti:
<ManagedInstanceName> dengan nama instans terkelola Anda.
<DAGName> dengan nama tautan yang Anda failover (output properti Name dari Get-AzSqlInstanceLink perintah yang dijalankan sebelumnya di atas).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====
# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"
# ==== Do not customize the following cmdlet ====
# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force
Ketika failover berhasil, tautan dihilangkan dan tidak ada lagi. Database SQL Server dan database SQL Managed Instance dapat menjalankan beban kerja baca/tulis karena sekarang sepenuhnya independen.
Penting
Setelah berhasil melakukan failover ke SQL Managed Instance, arahkan ulang aplikasi Anda secara manual string koneksi ke FQDN instans terkelola SQL untuk menyelesaikan proses migrasi atau failover dan terus berjalan di Azure.
Setelah tautan dihilangkan, Anda dapat menyimpan grup ketersediaan di SQL Server, tetapi Anda harus menghilangkan grup ketersediaan terdistribusi untuk menghapus metadata tautan dari SQL Server. Langkah tambahan ini hanya diperlukan saat melakukan failover dengan menggunakan PowerShell karena SSMS melakukan tindakan ini untuk Anda.
Untuk menghilangkan grup ketersediaan terdistribusi Anda, ganti nilai berikut lalu jalankan sampel kode T-SQL:
<DAGName> dengan nama grup ketersediaan terdistribusi di SQL Server (digunakan untuk membuat tautan).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Menampilkan database setelah failover
Untuk SQL Server 2022, jika Anda memilih untuk mempertahankan tautan, Anda dapat memeriksa apakah grup ketersediaan terdistribusi ada di bawah Grup Ketersediaan di Object Explorer di SQL Server Management Studio.
Jika Anda menjatuhkan tautan selama failover, Anda dapat menggunakan Object Explorer untuk mengonfirmasi grup ketersediaan terdistribusi tidak ada lagi. Jika Anda memilih untuk menyimpan grup ketersediaan, database akan tetap Disinkronkan.
Bersihkan setelah failover
Kecuali hapus tautan setelah failover berhasil dipilih, failover dengan SQL Server 2022 tidak merusak tautan. Anda dapat mempertahankan tautan setelah failover, yang membuat grup ketersediaan, dan grup ketersediaan terdistribusi aktif. Tidak ada tindakan lebih lanjut yang diperlukan.
Menghilangkan tautan hanya menghilangkan grup ketersediaan terdistribusi, dan membiarkan grup ketersediaan aktif. Anda dapat memutuskan untuk menyimpan grup ketersediaan, atau menghilangkannya.
Jika Anda memutuskan untuk menghilangkan grup ketersediaan Anda, ganti nilai berikut lalu jalankan sampel kode T-SQL:
<AGName> dengan nama grup ketersediaan di SQL Server (digunakan untuk membuat tautan).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName>
GO
Status tidak konsisten setelah failover paksa
Setelah failover paksa, Anda mungkin mengalami skenario split-brain di mana kedua replika berada dalam peran utama, meninggalkan tautan dalam keadaan tidak konsisten. Ini dapat terjadi jika Anda melakukan failover ke replika sekunder selama bencana, dan kemudian replika utama kembali online.
Pertama, konfirmasikan bahwa Anda berada dalam skenario split-brain. Anda dapat melakukannya dengan menggunakan SQL Server Management Studio (SSMS) atau Transact-SQL (T-SQL).
Sambungkan ke SQL Server dan instans terkelola SQL di SSMS, lalu di Object Explorer, perluas replika Ketersediaan di bawah node Grup ketersediaan di Ketersediaan Tinggi AlwaysOn. Jika dua replika yang berbeda tercantum sebagai (Primer), Anda berada dalam skenario split-brain.
Atau, Anda dapat menjalankan skrip T-SQL berikut di SQL Server dan SQL Managed Instance untuk memeriksa peran replika:
-- Execute on SQL Server and SQL Managed Instance
declare @link_name varchar(max) = '<DAGName>'
USE MASTER
GO
SELECT
ag.name [Link name],
rs.role_desc [Link role]
FROM
sys.availability_groups ag
join sys.dm_hadr_availability_replica_states rs
on ag.group_id = rs.group_id
WHERE
rs.is_local = 1 and ag.name = @link_name
GO
Jika kedua instans mencantumkan Primer yang berbeda di kolom Peran tautan, Anda berada dalam skenario split-brain.
Untuk mengatasi keadaan otak terpisah, pertama-tama ambil cadangan pada replika mana pun yang merupakan primer asli. Jika primer asli adalah SQL Server, maka ambil cadangan log ekor. Jika primer aslinya adalah SQL Managed Instance, maka ambil cadangan penuh khusus salinan. Setelah pencadangan selesai, atur grup ketersediaan terdistribusi ke peran sekunder untuk replika yang dulunya merupakan primer asli tetapi sekarang akan menjadi sekunder baru.
Misalnya, jika terjadi bencana sejati, dengan asumsi Anda telah memaksa failover beban kerja SQL Server Anda ke Azure SQL Managed Instance, dan Anda berniat untuk terus menjalankan beban kerja Anda di SQL Managed Instance, mengambil cadangan log ekor di SQL Server, lalu mengatur grup ketersediaan terdistribusi ke peran sekunder di SQL Server seperti contoh berikut:
--Execute on SQL Server
USE MASTER
ALTER availability group [<DAGName>]
SET (role = secondary)
GO
Selanjutnya, jalankan failover manual yang direncanakan dari SQL Managed Instance ke SQL Server dengan menggunakan tautan, seperti contoh berikut:
--Execute on SQL Managed Instance
USE MASTER
ALTER availability group [<DAGName>] FAILOVER
GO
Azure SQL Managed Instance