Dukungan SqlClient untuk High Availability, Pemulihan Bencana

  • Artikel

Artikel ini membahas dukungan SqlClient (ditambahkan dalam .NET Framework 4.5) untuk ketersediaan tinggi, pemulihan bencana dengan fitur Always On -- Grup ketersediaan AlwaysOn (AG) dan instans kluster failover AlwaysOn (FCI) dengan SQL Server 2012 atau yang lebih baru.

Sekarang Anda dapat menentukan pendengar grup ketersediaan atau nama FCI di properti koneksi. Jika aplikasi SqlClient tersambung ke database yang gagal, koneksi asli rusak dan aplikasi harus membuka koneksi baru untuk melanjutkan pekerjaan setelah failover.

Jika Anda tidak terhubung ke AG atau FCI, dan jika beberapa alamat IP dikaitkan dengan nama host, SqlClient akan melakukan iterasi secara berurutan melalui semua alamat IP yang terkait dengan entri DNS. Ini bisa memakan waktu jika alamat IP pertama yang dikembalikan oleh server DNS tidak terikat ke kartu antarmuka jaringan (NIC). Saat menyambungkan FCI, atau ke pendengar grup ketersediaan, SqlClient mencoba membuat koneksi ke semua alamat IP secara paralel. Jika upaya koneksi berhasil, driver akan membuang upaya koneksi yang tertunda.

Catatan

Meningkatkan batas waktu koneksi dan menerapkan logika coba lagi koneksi akan meningkatkan probabilitas bahwa aplikasi akan terhubung ke grup ketersediaan. Selain itu, karena koneksi dapat gagal karena failover, Anda harus menerapkan logika coba lagi koneksi, mencoba kembali koneksi yang gagal sampai koneksi tersambung kembali.

Properti koneksi berikut ditambahkan ke SqlClient di .NET Framework 4.5:

  • ApplicationIntent

  • MultiSubnetFailover

Anda dapat memodifikasi kata kunci string koneksi ini secara terprogram dengan:

Catatan

Pengaturan MultiSubnetFailover ke true tidak diperlukan dengan .NET Framework versi 4.6.1 dan yang lebih baru. Diperlukan dalam .NET Core dan .NET 5+.

Menyambungkan dengan MultiSubnetFailover.

Selalu tentukan MultiSubnetFailover=True saat menyambungkan ke FCI atau pendengar AG. MultiSubnetFailovermemungkinkan failover yang lebih cepat untuk semua AG dan atau FCI di SQL Server 2012 atau yang lebih baru dan secara signifikan mengurangi waktu failover untuk topologi Always On tunggal dan multi-subnet. Selama failover multi-subnet, klien mencoba koneksi secara paralel. Selama failover subnet, klien secara agresif mencoba kembali koneksi TCP.

Properti MultiSubnetFailover koneksi menunjukkan bahwa aplikasi menggunakan AG atau FCI dan bahwa SqlClient akan mencoba menyambungkan ke database pada instans SQL Server utama dengan mencoba menyambungkan ke semua alamat IP. Saat MultiSubnetFailover=True ditentukan untuk koneksi, klien mencoba kembali koneksi TCP mencoba lebih cepat daripada interval transmisi ulang TCP default sistem operasi. Ini memungkinkan koneksi ulang yang lebih cepat setelah failover AG atau FCI, dan berlaku untuk AG dan FCI tunggal dan multi-subnet.

Untuk informasi selengkapnya tentang kata kunci string koneksi di SqlClient, lihat ConnectionString.

Menentukan MultiSubnetFailover=True kapan menyambungkan ke sesuatu selain AG atau FCI dapat mengakibatkan dampak performa negatif, dan tidak didukung.

Gunakan panduan berikut untuk menyambungkan ke server menggunakan salah satu fitur Always On:

  • Gunakan properti koneksi MultiSubnetFailover saat menyambungkan ke satu subnet atau multi-subnet; ini akan meningkatkan performa untuk keduanya.

  • Untuk menyambungkan ke AG, tentukan pendengar grup ketersediaan sebagai server dalam string koneksi Anda.

  • Menyambungkan ke instans SQL Server yang dikonfigurasi dengan lebih dari 64 alamat IP akan menyebabkan kegagalan koneksi.

  • Perilaku aplikasi yang menggunakan MultiSubnetFailover properti koneksi tidak terpengaruh berdasarkan jenis autentikasi: Autentikasi SQL Server, Autentikasi Kerberos, atau Autentikasi Windows.

  • Tingkatkan nilai Connect Timeout untuk mengakomodasi waktu failover dan mengurangi upaya coba lagi koneksi aplikasi.

  • Transaksi terdistribusi tidak didukung.

Jika perutean baca-saja tidak berlaku, menyambungkan ke lokasi replika sekunder akan gagal dalam situasi berikut:

  • Jika lokasi replika sekunder tidak dikonfigurasi untuk menerima koneksi.

  • Jika aplikasi menggunakan ApplicationIntent=ReadWrite (dibahas di bawah) dan lokasi replika sekunder dikonfigurasi untuk akses baca-saja.

SqlDependency tidak didukung pada replika sekunder baca-saja.

Koneksi akan gagal jika replika utama dikonfigurasi untuk menolak beban kerja baca-saja dan string koneksi berisi ApplicationIntent=ReadOnly.

Memutakhirkan untuk Menggunakan Kluster Multi-Subnet dari Pencerminan Database

Kesalahan koneksi (ArgumentException) akan terjadi jika MultiSubnetFailover kata kunci koneksi dan Failover Partner ada dalam string koneksi, atau jika MultiSubnetFailover=True dan protokol selain TCP digunakan. Kesalahan (SqlException) juga akan terjadi jika MultiSubnetFailover digunakan dan SQL Server mengembalikan respons mitra failover yang menunjukkan bahwa itu adalah bagian dari pasangan pencerminan database.

Jika Anda meningkatkan aplikasi SqlClient yang saat ini menggunakan pencerminan database ke skenario multi-subnet, Anda harus menghapus Failover Partner properti koneksi dan menggantinya dengan MultiSubnetFailover diatur ke True dan mengganti nama server dalam string koneksi dengan pendengar grup ketersediaan. Jika string koneksi menggunakan Failover Partner dan MultiSubnetFailover=True, driver akan menghasilkan kesalahan. Namun, jika string koneksi menggunakan Failover Partner dan MultiSubnetFailover=False (atau ApplicationIntent=ReadWrite), aplikasi akan menggunakan pencerminan database.

Driver akan mengembalikan kesalahan jika pencerminan database digunakan pada database utama di AG, dan jika MultiSubnetFailover=True digunakan dalam string koneksi yang tersambung ke database utama alih-alih ke pendengar grup ketersediaan.

Menentukan Niat Aplikasi

Saat ApplicationIntent=ReadOnly, klien meminta beban kerja baca saat menyambungkan ke database yang diaktifkan AlwaysOn. Server akan memberlakukan niat pada waktu koneksi dan selama pernyataan database USE tetapi hanya ke database yang diaktifkan AlwaysOn.

Kata ApplicationIntent kunci tidak berfungsi dengan database lama dan baca-saja.

Database dapat mengizinkan atau melarang beban kerja baca pada database AlwaysOn yang ditargetkan. (Ini dilakukan dengan ALLOW_CONNECTIONS klausul pernyataan PRIMARY_ROLE dan SECONDARY_ROLETransact-SQL.)

Kata ApplicationIntent kunci digunakan untuk mengaktifkan perutean baca-saja.

Perutean Baca-Saja

Perutean baca-saja adalah fitur yang dapat memastikan ketersediaan replika database baca-saja. Untuk mengaktifkan perutean baca-saja:

  1. Anda harus tersambung ke pendengar grup ketersediaan Grup Ketersediaan AlwaysOn.

  2. Kata ApplicationIntent kunci string koneksi harus diatur ke ReadOnly.

  3. Grup Ketersediaan harus dikonfigurasi oleh administrator database untuk mengaktifkan perutean baca-saja.

Ada kemungkinan bahwa beberapa koneksi yang menggunakan perutean baca-saja tidak semuanya akan tersambung ke replika baca-saja yang sama. Perubahan sinkronisasi database atau perubahan konfigurasi perutean server dapat mengakibatkan koneksi klien ke replika baca-saja yang berbeda. Untuk memastikan bahwa semua permintaan baca-saja tersambung ke replika baca-saja yang sama, jangan teruskan pendengar grup ketersediaan ke Data Source kata kunci string koneksi. Sebagai gantinya, tentukan nama instans baca-saja.

Perutean baca-saja mungkin memakan waktu lebih lama daripada menyambungkan ke primer karena perutean baca saja terlebih dahulu tersambung ke primer dan kemudian mencari sekunder yang dapat dibaca terbaik yang tersedia. Karena itu, Anda harus meningkatkan batas waktu masuk Anda.

Lihat juga