Bagikan melalui

Dukungan SqlClient untuk ketersediaan tinggi dan pemulihan bencana

Artikel ini membahas dukungan SqlClient (ditambahkan dalam .NET Framework 4.5) untuk ketersediaan tinggi dan pemulihan bencana dengan fitur AlwaysOn: 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 mengabaikan 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+.

Menghubungkan dengan MultiSubnetFailover.

Selalu tentukan MultiSubnetFailover=True saat menyambungkan ke FCI atau pendengar AG. MultiSubnetFailovermemfasilitasi failover yang lebih cepat untuk semua AG dan/atau FCI di SQL Server 2012 atau versi yang lebih baru, serta secara signifikan mengurangi waktu failover untuk topologi Always On pada satu atau banyak subnet. Selama failover multi-subnet, klien mencoba koneksi secara paralel. Selama failover subnet, klien berupaya keras untuk mencoba ulang 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 melakukan upaya pengulangan koneksi TCP lebih cepat daripada interval retransmisi TCP default dari 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 listener 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.

Memperbarui untuk Menggunakan Kluster Multi-Subnet dari Pencerminan Basis Data

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 dari properti koneksi dan menggantinya dengan MultiSubnetFailover yang ditetapkan ke True, serta mengganti nama server dalam string koneksi dengan pendengar kelompok 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 mirroring database digunakan pada database utama di AG, dan jika MultiSubnetFailover=True digunakan dalam string koneksi yang tersambung ke database utama alih-alih ke listener grup ketersediaan.

Menentukan Niat Aplikasi

Saat ApplicationIntent=ReadOnly, klien meminta tugas pembacaan saat menyambungkan ke database yang diaktifkan dengan AlwaysOn. Server akan memberlakukan tujuan pada waktu koneksi dan selama pernyataan USE database tetapi hanya untuk database yang diaktifkan Always On.

Kata kunci ApplicationIntent tidak berfungsi dengan database lama yang hanya dapat dibaca.

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

Kata ApplicationIntent kunci digunakan untuk mengaktifkan routing baca-saja.

Perutean Baca-Saja

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

  • Anda harus tersambung ke listener grup ketersediaan Always On Availability Group.
  • Kata ApplicationIntent kunci string koneksi harus diatur ke ReadOnly.
  • Grup Ketersediaan perlu dikonfigurasi oleh administrator basis data untuk mengaktifkan pengarahan baca-saja.

Ada kemungkinan bahwa beberapa koneksi yang menggunakan perutean bacasaja tidak semuanya akan tersambung ke replika bacasaja 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 menghubungkan ke primer dan kemudian mencari sekunder yang dapat dibaca terbaik yang tersedia. Karena itu, Anda harus meningkatkan batas waktu masuk Anda.

Lihat juga

  • Last updated on