Menentukan kemungkinan alasan kegagalan konektivitas antara replika ketersediaan

Berlaku untuk:SQL Server

Masalah fisik, sistem operasi, atau SQL Server dapat menyebabkan kegagalan dalam sesi antara dua replika ketersediaan. Replika ketersediaan tidak secara teratur memeriksa komponen yang sqlservr.exe bergantung pada verifikasi apakah replika tersebut berfungsi dengan benar atau gagal. Namun, untuk beberapa jenis kegagalan, komponen yang terpengaruh melaporkan kesalahan ke sqlservr.exe. Kesalahan yang dilaporkan oleh komponen lain disebut kesalahan keras.

Untuk mendeteksi kegagalan lain yang tidak diperhatikan, grup ketersediaan AlwaysOn menerapkan mekanisme batas waktu sesi mereka sendiri. Periode batas waktu sesi ditentukan dalam detik. Periode waktu habis ini adalah waktu maksimum instans server menunggu untuk menerima pesan PING dari instans lain sebelum mempertimbangkan bahwa instans lain terputus. Ketika batas waktu sesi terjadi antara dua replika ketersediaan, replika ketersediaan mengasumsikan bahwa kegagalan telah terjadi dan menyatakan kesalahan lunak.

Penting

Kegagalan dalam database selain database utama tidak dapat dideteksi. Selain itu, kegagalan disk data tidak mungkin terdeteksi kecuali database dimulai ulang karena kegagalan disk data.

Kecepatan deteksi kesalahan dan, oleh karena itu, waktu reaksi terhadap kegagalan, tergantung pada apakah kesalahannya keras atau lunak. Beberapa kesalahan keras, seperti kegagalan jaringan segera dilaporkan. Namun, dalam beberapa kasus, periode waktu habis khusus komponen dapat menunda pelaporan beberapa kesalahan keras. Untuk kesalahan sementara, lamanya periode batas waktu sesi menentukan kecepatan deteksi kesalahan. Secara default, periode ini adalah 10 detik. Ini adalah nilai minimum yang direkomendasikan.

Kegagalan karena kesalahan keras

Kemungkinan penyebab kesalahan keras termasuk (tetapi tidak terbatas pada) kondisi berikut:

  • Koneksi atau kawat yang rusak
  • Kartu jaringan yang buruk
  • Perubahan perute
  • Perubahan pada firewall
  • Konfigurasi ulang titik akhir
  • Kehilangan drive tempat log transaksi berada
  • Sistem operasi atau kegagalan proses

Misalnya, ketika drive log pada database utama menjadi tidak responsif dan gagal, sistem operasi menginformasikan sqlservr.exe bahwa telah terjadi kesalahan serius.

Beberapa komponen, seperti komponen jaringan dan beberapa subsistem I/O, memiliki batas waktunya sendiri untuk menentukan kegagalan. Batas waktu tersebut tidak bergantung pada grup ketersediaan AlwaysOn, yang tidak memiliki pengetahuan tentang mereka dan tidak menyadari perilaku mereka. Dalam kasus ini, penundaan waktu habis meningkatkan waktu antara kegagalan dan ketika replika ketersediaan menerima kesalahan keras yang dihasilkan.

Catatan

Satu-satunya pemeriksaan kesalahan aktif yang dilakukan untuk replika ketersediaan terjadi untuk kasus kesalahan lunak. Untuk informasi selengkapnya, lihat "Kegagalan Karena Kesalahan Lunak," nanti dalam topik ini.

Untuk membantu Anda menginterpretasikan kondisi kesalahan yang terjadi pada jaringan, tanyakan kepada teknisi jaringan pesan kesalahan apa yang dikirim ke port ketika peristiwa berikut terjadi pada koneksi TCP:

  • DNS tidak berfungsi.
  • Kabel dilepas.
  • Microsoft Windows memiliki firewall yang memblokir port tertentu.
  • Aplikasi yang memantau port gagal.
  • Server berbasis Windows diganti namanya.
  • Server berbasis Windows dimulai ulang.

Catatan

Grup ketersediaan AlwaysOn tidak melindungi dari masalah khusus untuk klien yang mengakses server. Misalnya, pertimbangkan kasus di mana adaptor jaringan publik menangani koneksi klien ke replika utama, sementara kartu antarmuka jaringan privat menangani lalu lintas di antara instans server yang menghosting replika grup ketersediaan. Dalam hal ini, kegagalan adaptor jaringan publik akan mencegah klien mengakses database.

Kegagalan karena kesalahan lunak

Kondisi yang mungkin menyebabkan batas waktu sesi termasuk (tetapi tidak terbatas pada) hal berikut:

  • Kesalahan jaringan seperti waktu habis tautan TCP, paket yang dihilangkan atau rusak, atau paket yang berada dalam urutan yang salah.

  • Sistem operasi, server, atau database yang tidak merespons.

  • Waktu server Windows habis.

  • Sumber daya komputasi yang tidak memadai, seperti kelebihan beban CPU atau disk, pengisian log transaksi, atau sistem kehabisan memori atau utas. Dalam kasus ini, Anda harus meningkatkan periode waktu habis, mengurangi beban kerja, atau mengubah perangkat keras untuk menangani beban kerja.

Mekanisme waktu habis sesi

Karena kesalahan lunak tidak dapat dideteksi langsung oleh instans server, kesalahan lunak berpotensi menyebabkan replika ketersediaan menunggu tanpa batas waktu untuk respons dari replika ketersediaan lainnya dalam sesi. Untuk mencegah hal ini, grup ketersediaan AlwaysOn menerapkan mekanisme waktu habis sesi, berdasarkan replika ketersediaan terhubung yang mengirimkan ping pada setiap koneksi terbuka pada interval tetap. Menerima ping selama periode waktu habis menunjukkan bahwa koneksi masih terbuka dan bahwa instans server berkomunikasi di atasnya. Saat menerima ping, replika mengatur ulang penghitung waktu habis pada koneksi tersebut. Untuk informasi tentang hubungan mode ketersediaan dan batas waktu sesi, lihat Mode Ketersediaan (Grup Ketersediaan AlwaysOn).

Replika primer dan sekunder saling ping untuk memberi sinyal bahwa mereka masih aktif, dan batas waktu habis sesi mencegah replika menunggu tanpa batas waktu untuk menerima ping dari replika lain. Batas waktu habis sesi adalah properti replika yang dapat dikonfigurasi pengguna dengan nilai default 10 detik. Menerima ping selama periode waktu habis menunjukkan bahwa koneksi masih terbuka dan bahwa instans server berkomunikasi di atasnya. Saat menerima ping, replika ketersediaan mengatur ulang penghitung waktu habis pada koneksi tersebut.

Jika tidak ada ping yang diterima dari replika lain dalam periode waktu habis sesi, waktu koneksi habis. Koneksi ditutup, dan replika kehabisan waktu memasuki status TERPUTUS. Bahkan jika replika yang terputus dikonfigurasi untuk mode penerapan sinkron, transaksi tidak akan menunggu replika tersebut tersambung kembali dan menyinkronkan ulang.

Menanggapi kesalahan

Terlepas dari jenis kesalahan, instans server yang mendeteksi kesalahan merespons dengan tepat berdasarkan peran instans, mode ketersediaan sesi, dan status koneksi lain dalam sesi. Untuk informasi tentang apa yang terjadi pada hilangnya mitra, lihat Mode Ketersediaan (Grup Ketersediaan AlwaysOn).

Lihat juga

Langkah berikutnya

  • Last updated on