Tautan failover - Azure SQL Managed Instance

Aplikasi ke:Azure SQL Managed Instance

Artikel ini mengajarkan cara melakukan failover pada database linked 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 telah terinstal.
• Tautan dikonfigurasi antara replika utama dan sekunder Anda.
• Anda dapat melakukan failover pada tautan dengan menggunakan Transact-SQL yang dimulai dengan SQL Server 2022 CU13 (KB5036432).

Hentikan beban kerja

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 sinkronisasi replikasi database pada server sekunder, sehingga Anda dapat beralih ke server sekunder tanpa kehilangan data. Pastikan aplikasi Anda tidak melakukan transaksi ke primer sebelum failover.

Periksa jeda replikasi

Penting bahwa replika sekunder mengejar replika utama sebelum melakukan failover yang direncanakan. Failover yang direncanakan dapat kehabisan waktu dan gagal jika replika sekunder tertinggal jauh di belakang replika utama.

Gunakan kueri T-SQL berikut pada SQL Server dan SQL Managed Instance untuk memantau jeda replikasi antara replika:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Jika lag replikasi tinggi, tunggu hingga replika sekunder mengejar ketinggalan dengan replika utama. Anda mungkin perlu melakukan langkah-langkah pemecahan masalah tambahan jika lag berlanjut, seperti meningkatkan throughput jaringan tautan antara dua instans, atau meningkatkan kapasitas sumber daya pada replika sekunder.

Mengalihkan database

Anda dapat melakukan failover pada database tertaut dengan menggunakan Transact-SQL (T-SQL), SQL Server Management Studio, atau PowerShell.

Transact-SQL

Anda dapat melakukan failover pada tautan dengan menggunakan Transact-SQL yang dimulai dengan SQL Server 2022 CU13 (KB5036432).

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

SQL Server Management Studio (SSMS)

Gunakan wizard Failover antara SQL Server dan Managed Instance di SSMS untuk mengalihkan database dari replika utama ke sekunder.

Anda dapat melakukan failover yang direncanakan dari replika utama atau dari replika 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 pada database dalam SQL Server 2019 dan versi sebelumnya memutuskan dan menghapus koneksi antara dua replika. Anda tidak dapat melakukan failback ke primer awal.

Untuk melakukan failover pada database Anda, ikuti langkah-langkah berikut:

1. Buka SSMS dan sambungkan ke salah satu replika.

2. Di Object Explorer, klik kanan database yang direplikasi, arahkan mouse ke tautan Azure SQL Managed Instance, dan pilih Failover... untuk membuka wizard Failover antara SQL Server dan Managed Instance. Jika Anda memiliki beberapa tautan dari database yang sama, perluas Kelompok Ketersediaan di bawah Always On grup ketersediaan di Object Explorer dan klik kanan grup ketersediaan terdistribusi untuk tautan yang ingin Anda menggagalkan. Pilih Failover... untuk membuka wizard Failover antara SQL Server dan Managed Instance untuk tautan tertentu tersebut.

   

3. Di halaman Pengenalan, pilih Berikutnya.

4. 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 Planned failover.

5. Pada halaman Masuk ke Azure dan Instans Jarak Jauh:

   1. Pilih Sign-in untuk memberikan kredensial Anda dan masuk ke akun Azure Anda.
   2. Berdasarkan jenis Failover yang dipilih pada halaman sebelumnya, opsi Masuk berfungsi secara berbeda. Untuk failover terencana, masuk ke instans jarak jauh (baik ke SQL Server atau SQL Managed Instance) adalah wajib. Untuk failover yang dipaksakan, penandatanganan bersifat opsional karena kedua skenario berikut ini didukung:
      • Pemulihan bencana sesungguhnya: Karena instans utama biasanya tidak tersedia selama bencana sesungguhnya, masuk tidak dimungkinkan, dan pengguna harus segera melakukan alih fungsi ke instans sekunder, menjadikannya instans utama baru. Setelah pemadaman teratasi, tautan berada 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, proses masuk tetap tersedia, dan Anda diberi opsi untuk membalikkan peran antara kedua replika untuk menghindari skenario split-brain.

6. Pada halaman Operasi Pasca-Ketidakaktifan, opsi berbeda di antara SQL Server 2022 dan versi-versi sebelumnya, serta apakah Anda dapat tersambung atau tidak ke instans utama.

   • Untuk SQL Server 2022, Anda dapat memilih untuk menghentikan replikasi antar 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 bisa 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 Lepas tautan dipilih sebagai default, dan Anda tidak dapat menghapusnya, karena saat failover ke SQL Managed Instance akan menghentikan replikasi, memutus tautan, dan menghapus 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 Clean-up.

7. 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.

8. 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, server sekunder menjadi primer baru, tautan tetap aktif, dan Anda dapat kembali melakukan failover 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 akan dihilangkan dan tidak ada lagi setelah failover selesai. Database sumber dan database target pada setiap replika dapat menjalankan beban kerja baca/tulis. Mereka benar-benar independen.

Penting

Setelah SQL Managed Instance berhasil failover, arahkan secara manual connection string aplikasi Anda ke SQL Managed Instance FQDN untuk menyelesaikan proses migrasi atau failover dan beroperasi di Azure.

PowerShell

Untuk melakukan failover, pertama-tama Anda harus mengalihkan mode replikasi pada instance 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 asinkron 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 pada 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 pada SQL Server untuk mengubah mode replikasi grup ketersediaan terdistribusi dari asinkron ke sinkronisasi. Menggantikan:

• <DAGName> dengan nama grup ketersediaan terdistribusi (digunakan untuk membuat tautan).
• <AGName> dengan nama grup ketersediaan yang dibuat pada 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 beralih SQL Server ke mode komit sinkron, replikasi antara dua instans menjadi 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 rekaman 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 pada SQL Server untuk membaca LSN log transaksi terakhir yang dicatat. 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 diperkeras untuk database Anda. Ganti <DatabaseName> dengan nama database Anda.

Kueri ini berfungsi pada SQL Managed Instance Tujuan Umum. Untuk SQL Managed Instance Kritis Bisnis, 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 PowerShell Get-AzSqlInstanceLink atau perintah Azure CLI az sql mi link show untuk mengambil properti LastHardenedLsn dari tautan Anda di SQL Managed Instance, yang memberikan informasi yang sama dengan kueri T-SQL sebelumnya.

Penting

Pastikan sekali lagi bahwa beban kerja Anda dihentikan pada server utama. Periksa apakah LSN pada SQL Server dan SQL Managed Instance saling cocok, dan tetap cocok serta tidak berubah selama beberapa waktu. LSN yang stabil pada kedua instance menunjukkan log ekor telah direplikasi ke sekunder dan beban kerja telah dihentikan secara efektif.

Mengalihkan database

Jika Anda ingin menggunakan PowerShell untuk melakukan failover pada database antara SQL Server 2022 dan SQL Managed Instance saat masih mempertahankan tautan, atau melakukan failover dengan kehilangan data untuk versi SQL Server apa pun, gunakan Failover antara SQL Server dan Managed Instancewizard di SSMS untuk menghasilkan skrip untuk lingkungan Anda. Anda dapat melakukan failover yang direncanakan dari replika utama atau dari replika 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 Remove-AzSqlInstanceLink PowerShell atau az sql mi link delete Azure CLI perintah.

Perhatian

• Sebelum failover, hentikan beban kerja pada database sumber untuk memungkinkan database yang direplikasi benar-benar mengejar dan failover tanpa kehilangan data. Jika terjadi failover paksa, atau jika tautan terputus sebelum LSN cocok, data mungkin hilang.
• Failover pada database dalam SQL Server 2019 dan versi sebelumnya memutuskan dan menghapus koneksi antara dua replika. Anda tidak dapat melakukan failback ke primer awal.

Contoh skrip berikut memutus tautan dan mengakhiri replikasi antara replika Anda, sehingga database bisa dibaca dan ditulis di kedua instans. Ganti:

• <ManagedInstanceName> dengan nama instans terkelola Anda.
• <DAGName> dengan nama tautan yang Anda failover (output dari properti Name dari perintah Get-AzSqlInstanceLink yang dijalankan sebelumnya).

# 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 benar-benar independen.

Penting

Setelah SQL Managed Instance berhasil failover, arahkan secara manual connection string aplikasi Anda ke SQL Managed Instance FQDN untuk menyelesaikan proses migrasi atau failover dan beroperasi di Azure.

Setelah tautan dihilangkan, Anda dapat menyimpan grup ketersediaan di SQL Server, tetapi Anda harus menghilangkan distribusi grup ketersediaan 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 pada SQL Server (digunakan untuk membuat tautan).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

Penting

Setelah menjalankan failover yang direncanakan, mode replikasi diatur ke asinkron.

Proses failover beberapa database

Jika Anda berencana untuk melakukan failover pada beberapa database dari instans di server yang sama, untuk kinerja dan keterandalan yang optimal, lakukan failover 8 database per instans pada satu waktu. Misalnya, jika Anda memiliki 10 instans dengan masing-masing 32 database tertaut, gagalkan lebih dari 8 database sekaligus dari setiap instans, dan ulangi proses hingga semua database gagal.

Melihat database setelah failover

Untuk SQL Server 2022, jika Anda memilih untuk mempertahankan tautan, Anda dapat memeriksa apakah grup ketersediaan terdistribusi ada di bawah Kelompok Ketersediaan di Object Explorer di SQL Server Management Studio.

Jika Anda memutus tautan selama failover, Anda dapat menggunakan Object Explorer untuk mengonfirmasi bahwa 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, melakukan failover dengan SQL Server 2022 tidak akan memutus tautan tersebut. Anda dapat mempertahankan tautan setelah failover, yang tetap membuat grup ketersediaan dan grup ketersediaan terdistribusi tetap 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.

Untuk mengatasi masalah ini, lihat Memperbaiki skenario split-brain.

Konten terkait

Untuk menggunakan tautan:

• Siapkan lingkungan untuk tautan Managed Instance
• Konfigurasi tautan antara SQL Server dan SQL Managed instance dengan SSMS
• Konfigurasi tautan antara SQL Server dan instans Terkelola SQL dengan skrip
• Bermigrasi dengan tautan
• Praktik terbaik untuk mempertahankan tautan
• Mengatasi masalah pada tautan

Untuk mempelajari selengkapnya tentang tautan:

• Gambaran umum tautan Managed Instance
• Pemulihan bencana dengan tautan Managed Instance

Untuk skenario replikasi dan migrasi lainnya, pertimbangkan:

• replikasi transaksi dengan SQL Managed Instance
• Layanan Pemutaran Ulang Log (LRS)