Bagikan melalui

Apa itu grup ketersediaan AlwaysOn?

Berlaku untuk:SQL Server

Artikel ini memperkenalkan konsep grup ketersediaan AlwaysOn yang merupakan pusat untuk mengonfigurasi dan mengelola satu atau beberapa grup ketersediaan di SQL Server edisi Enterprise. Untuk edisi Standar, tinjau Grup ketersediaan AlwaysOn Dasar untuk satu database.

Fitur grup ketersediaan AlwaysOn adalah solusi ketersediaan tinggi dan pemulihan bencana yang menyediakan alternatif tingkat perusahaan untuk pencerminan database. Grup ketersediaan AlwaysOn memaksimalkan ketersediaan sekumpulan database pengguna untuk perusahaan. Grup ketersediaan mendukung lingkungan failover untuk sekumpulan database pengguna yang diskrit, yang disebut database ketersediaan, yang mengalami kegagalan bersamaan. Grup ketersediaan mendukung sekumpulan database utama baca-tulis dan satu hingga delapan set database sekunder yang sesuai. Secara opsional, database sekunder dapat disediakan untuk akses baca-saja dan/atau beberapa operasi pencadangan.

Dengan SQL Server yang diaktifkan oleh Azure Arc, Anda dapat melihat grup ketersediaan di portal Azure.

Gambaran Umum

Grup Ketersediaan mendukung lingkungan yang direplikasi untuk sekumpulan database pengguna yang terpisah, yang dikenal sebagai Database Ketersediaan. Anda dapat membuat grup ketersediaan untuk ketersediaan tinggi (HA) atau untuk skala baca. Grup ketersediaan tinggi adalah sekelompok database yang melakukan failover bersama. Grup ketersediaan skala baca adalah sekelompok database yang disalin ke instans SQL Server lain untuk beban kerja baca-saja. Grup ketersediaan mendukung satu set database utama dan satu hingga delapan set database sekunder yang sesuai. Database sekunder bukan cadangan. Tetaplah mencadangkan database Anda dan log transaksinya secara teratur.

Petunjuk

Anda dapat membuat semua jenis cadangan database utama. Atau, Anda dapat membuat cadangan log dan pencadangan penuh khusus salinan database sekunder. untuk informasi selengkapnya, lihat Mengalihkan cadangan yang didukung ke replika sekunder dari grup ketersediaan.

Setiap set database ketersediaan dihosting oleh replika ketersediaan. Ada dua jenis replika ketersediaan: satu replika utama, yang menghosting database utama, dan satu hingga delapan replika sekunder, yang masing-masing menghosting serangkaian database sekunder dan berfungsi sebagai target failover potensial untuk grup ketersediaan. Grup ketersediaan gagal pada tingkat replika ketersediaan. Replika ketersediaan hanya menyediakan redundansi di tingkat database untuk kumpulan database dalam satu grup ketersediaan. Failover tidak disebabkan oleh masalah database seperti database yang menjadi tidak dapat dipakai akibat hilangnya file data atau kerusakan log transaksi.

Replika utama membuat database utama tersedia untuk koneksi baca-tulis dari klien. Replika utama mengirim catatan log transaksi dari setiap database utama ke setiap database sekunder. Proses ini - dikenal sebagai sinkronisasi data - terjadi di tingkat database. Setiap replika sekunder menyimpan rekaman log transaksi (mengeraskan log) lalu menerapkannya ke database sekunder yang sesuai. Sinkronisasi data terjadi antara database utama dan setiap database sekunder yang tersambung, secara independen dari database lain. Oleh karena itu, database sekunder dapat ditangguhkan atau gagal tanpa memengaruhi database sekunder lainnya, dan database utama dapat ditangguhkan atau gagal tanpa memengaruhi database utama lainnya.

Secara opsional, Anda dapat mengonfigurasi satu atau beberapa replika sekunder untuk mendukung akses baca-saja ke database sekunder, dan Anda dapat mengonfigurasi replika sekunder apa pun untuk mengizinkan pencadangan pada database sekunder.

SQL Server 2017 memperkenalkan dua arsitektur berbeda untuk grup ketersediaan. Grup Ketersediaan Always On menyediakan ketersediaan tinggi, pemulihan bencana, dan penyeimbangan beban baca. Grup ketersediaan ini memerlukan manajer kluster. Di Windows, fitur pengklusteran failover menyediakan manajer kluster. Di Linux, Anda dapat menggunakan Pacemaker. Arsitektur lainnya adalah grup ketersediaan yang dapat diskalakan untuk pembacaan. Grup ketersediaan skala baca menyediakan replika untuk beban kerja baca-saja tetapi tidak ketersediaan tinggi. Dalam grup ketersediaan skala baca, tidak ada manajer kluster, karena failover tidak dapat dilakukan secara otomatis.

Menyebarkan grup ketersediaan Always On untuk High Availability (HA) di Windows memerlukan Windows Server Failover Cluster (WSFC). Setiap replika dari sebuah grup ketersediaan harus berada di simpul (node) yang berbeda dalam WSFC yang sama. Satu-satunya pengecualian adalah bahwa saat dimigrasikan ke kluster WSFC lain, grup ketersediaan dapat menjembatani dua kluster untuk sementara waktu.

Catatan

Untuk informasi tentang grup ketersediaan di Linux, lihat Grup ketersediaan untuk SQL Server di Linux.

Dalam konfigurasi HA, peran kluster dibuat untuk setiap grup ketersediaan yang Anda buat. Kluster WSFC memantau peran ini untuk mengevaluasi kesehatan replika utama. Kuorum untuk grup ketersediaan Always On didasarkan pada semua simpul di kluster WSFC, terlepas dari apakah simpul kluster tersebut menghosting replika ketersediaan apa pun. Berbeda dengan pencerminan database, tidak ada peran saksi dalam grup ketersediaan AlwaysOn.

Catatan

Untuk informasi tentang hubungan komponen Always On SQL Server ke kluster WSFC, lihat Pengklusteran Failover Windows Server dengan SQL Server.

Ilustrasi berikut menunjukkan grup ketersediaan yang berisi satu replika utama dan empat replika sekunder. Hingga delapan replika sekunder didukung, termasuk satu replika utama dan empat replika sekunder komit sinkron.

Diagram grup ketersediaan dengan lima replika.

Syarat dan definisi

Istilah Deskripsi
grup ketersediaan Kontainer untuk sekumpulan database, database ketersediaan, yang mengalami failover bersama.
database ketersediaan Database yang termasuk dalam grup ketersediaan. Untuk setiap database ketersediaan, grup ketersediaan mempertahankan satu salinan baca-tulis ( database utama) dan satu hingga delapan salinan baca-saja (database sekunder).
database utama Salinan yang dapat dibaca dan ditulis dari database ketersediaan.
database sekunder Salinan hanya-baca dari database ketersediaan.
replika ketersediaan Instansiasi grup ketersediaan yang dihosting oleh instans SQL Server tertentu dan mempertahankan salinan lokal dari setiap database ketersediaan yang termasuk dalam grup ketersediaan. Ada dua jenis replika ketersediaan: satu replika utama dan satu hingga delapan replika sekunder.
replika utama Replika ketersediaan yang membuat database utama tersedia untuk koneksi baca-tulis dari klien dan, juga, mengirim catatan log transaksi untuk setiap database utama ke setiap replika sekunder.
replika sekunder Replika ketersediaan yang mempertahankan salinan sekunder dari setiap database ketersediaan, dan berfungsi sebagai target failover potensial untuk grup ketersediaan. Secara opsional, replika sekunder dapat mendukung akses baca-saja ke database sekunder dapat mendukung pembuatan cadangan pada database sekunder.
pendengar grup ketersediaan Nama server tempat klien dapat tersambung untuk mengakses database di replika utama atau sekunder dari grup ketersediaan. Pendengar grup ketersediaan mengarahkan sambungan masuk ke replika utama atau ke replika sekunder yang bersifat baca-saja.

Ketersediaan basis data

Untuk menambahkan database ke grup ketersediaan, database harus online, database baca-tulis yang ada di instans server yang menghosting replika utama. Saat Anda menambahkan database, database bergabung dengan grup ketersediaan sebagai database utama, sementara tetap tersedia untuk klien. Tidak ada database sekunder yang sesuai sampai cadangan database utama baru dipulihkan ke instans server yang menghosting replika sekunder (menggunakan RESTORE WITH NORECOVERY). Database sekunder baru berada dalam status PEMULIHAN hingga digabungkan ke grup ketersediaan. Untuk informasi selengkapnya, lihat Memulai Pergerakan Data pada Database Sekunder Always On (SQL Server).

Bergabung menempatkan database sekunder ke dalam status ONLINE dan memulai sinkronisasi data dengan database utama yang sesuai. Sinkronisasi data adalah proses di mana perubahan pada database utama direproduseri pada database sekunder. Sinkronisasi data melibatkan database utama yang mengirim rekaman log transaksi ke database sekunder.

Penting

Database ketersediaan kadang-kadang disebut replika database dalam Transact-SQL, PowerShell, dan nama-nama SQL Server Management Objects (SMO). Misalnya, istilah "replika database" digunakan dalam nama tampilan manajemen dinamis Always On yang mengembalikan informasi tentang database ketersediaan: sys.dm_hadr_database_replica_states dan sys.dm_hadr_database_replica_cluster_states. Namun, dalam SQL Server Books Online, istilah "replika" biasanya mengacu pada replika ketersediaan. Misalnya, "replika utama" dan "replika sekunder" selalu merujuk ke replika ketersediaan.

Replika ketersediaan

Setiap grup ketersediaan mendefinisikan satu set dua mitra failover atau lebih yang dikenal sebagai replika ketersediaan. Replika ketersediaan adalah komponen dalam grup ketersediaan. Setiap replika ketersediaan menghosting salinan database ketersediaan dalam kelompok ketersediaan. Untuk grup ketersediaan tertentu, replika ketersediaan harus dihosting oleh instans terpisah SQL Server yang berada di node yang berbeda dari kluster WSFC. Masing-masing instans server ini harus diaktifkan untuk Always On.

SQL Server 2019 (15.x) meningkatkan jumlah maksimum replika sinkron menjadi 5, naik dari 3 di SQL Server 2017 (14.x). Anda dapat mengonfigurasi grup lima replika ini untuk memiliki failover otomatis dalam grup. Ada satu replika utama, ditambah empat replika sekunder sinkron.

Suatu instans tertentu hanya dapat meng-host satu replika ketersediaan dalam setiap grup ketersediaan. Namun, tiap instans dapat digunakan untuk banyak grup ketersediaan. Instans tertentu dapat berupa instans mandiri atau instans kluster failover SQL Server (FCI). Jika Anda memerlukan redundansi tingkat server, gunakan Instans Kluster Failover.

Setiap replika ketersediaan diberi peran awal baik peran utama atau peran sekunder, yang diwarisi oleh database ketersediaan replika tersebut. Peran replika tertentu menentukan apakah replika tersebut menghosting database baca-tulis atau database baca-saja. Satu replika, yang dikenal sebagai replika utama, diberi peran utama dan menghosting database baca-tulis, yang dikenal sebagai database utama. Setidaknya satu replika lain, yang dikenal sebagai replika sekunder, diberi peran sekunder. Replika sekunder menghosting database baca-saja, yang dikenal sebagai database sekunder.

Catatan

Ketika peran replika ketersediaan tidak ditentukan, seperti selama failover, databasenya sementara dalam status TIDAK DISINKRONKAN. Peran mereka diset ke RESOLVING hingga peran replika ketersediaan telah ditentukan. Jika replika ketersediaan ditetapkan sebagai peran utama, databasenya menjadi basis data utama. Jika replika ketersediaan berubah menjadi peran sekunder, basis datanya menjadi basis data sekunder.

Mode ketersediaan

Mode ketersediaan adalah sebuah properti dari setiap replika ketersediaan. Mode ketersediaan menentukan apakah replika utama menunggu untuk melakukan transaksi pada database, sampai replika sekunder tertentu telah menulis catatan log transaksi ke disk (mengeraskan log). Grup Ketersediaan Always On mendukung dua mode ketersediaan: mode komitmen asinkron dan mode komitmen sinkron.

  • Mode penerapan asinkron

    Replika ketersediaan yang menggunakan mode ketersediaan ini dikenal sebagai replika komitmen asinkron. Dalam mode penerapan asinkron, replika utama melakukan transaksi tanpa menunggu pengakuan dari replika sekunder penerapan asinkron untuk memperkuat log transaksi mereka. Mode penerapan asinkron meminimalkan latensi transaksi pada database sekunder tetapi memungkinkan mereka untuk tertinggal di belakang database utama, sehingga beberapa data dapat hilang.

  • Mode penerapan sinkron

    Replika ketersediaan yang menggunakan mode ketersediaan ini dikenal sebagai replika komit sinkron. Dalam mode penerapan sinkron, sebelum melakukan transaksi, replika utama penerapan sinkron menunggu replika sekunder penerapan sinkron untuk mengakui bahwa replika tersebut telah selesai mengeraskan log. Mode komit sinkron memastikan bahwa setelah database sekunder tertentu disinkronkan dengan database utama, transaksi yang telah dikomitkan sepenuhnya dilindungi. Perlindungan ini dikenakan biaya peningkatan latensi transaksi. Secara opsional, SQL Server 2017 memperkenalkan fitur sekunder tersinkronisasi yang diwajibkan untuk lebih meningkatkan keamanan dengan pengorbanan pada latensi jika diinginkan. Fitur REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT dapat diaktifkan untuk mewajibkan sejumlah replika sinkron tertentu mengonfirmasi transaksi sebelum replika utama diizinkan untuk mengonfirmasinya.

Untuk informasi selengkapnya, lihat Perbedaan antara mode ketersediaan untuk grup ketersediaan Always On.

Jenis failover

Dalam konteks sesi antara replika utama dan replika sekunder, peran utama dan sekunder berpotensi dapat dipertukarkan dalam proses yang dikenal sebagai failover. Selama failover, replika sekunder target beralih ke peran utama, menjadi replika utama baru. Replika utama baru mengaktifkan databasenya sebagai database utama, dan aplikasi klien dapat menghubungkannya. Ketika replika utama sebelumnya tersedia kembali, replika tersebut beralih ke peran sekunder, menjadi replika sekunder. Database utama sebelumnya menjadi database sekunder dan sinkronisasi data dilanjutkan.

Grup ketersediaan gagal pada tingkat replika ketersediaan. Failover tidak disebabkan oleh masalah database seperti ketika database menjadi dicurigai akibat hilangnya file data, penghapusan database, atau kerusakan log transaksi.

Tiga bentuk failover ada secara otomatis, manual, dan dipaksa (dengan kemungkinan kehilangan data). Bentuk atau bentuk-bentuk failover yang didukung oleh replika sekunder tertentu tergantung pada mode ketersediaannya, dan, untuk mode komit sinkron, pada mode failover pada replika utama dan mode failover pada replika sekunder target, sebagai berikut.

  • Mode komit sinkron mendukung dua bentuk failover: failover manual yang direncanakan dan failover otomatis, jika replika sekunder target saat ini disinkronkan dengan replika utama. Dukungan untuk jenis failover ini tergantung pada pengaturan properti mode failover pada mitra failover. Jika mode failover diatur ke "manual" pada replika primer atau sekunder, hanya failover manual yang didukung untuk replika sekunder tersebut. Jika mode failover diatur ke "otomatis" pada replika primer dan sekunder, failover otomatis dan manual didukung pada replika sekunder tersebut.

    • Failover manual direncanakan (tanpa kehilangan data)

      Failover manual terjadi setelah administrator database mengeluarkan perintah failover dan menyebabkan replika sekunder yang disinkronkan beralih ke peran utama (dengan perlindungan data yang dijamin) dan replika utama untuk beralih ke peran sekunder. Failover manual mengharuskan replika utama dan replika sekunder target beroperasi dalam mode komit sinkron, dan replika sekunder harus sudah disinkronkan.

    • Failover otomatis (tanpa kehilangan data)

      Failover otomatis terjadi sebagai respons terhadap kegagalan yang menyebabkan replika sekunder yang disinkronkan beralih ke peran utama (dengan perlindungan data yang dijamin). Ketika replika utama sebelumnya tersedia, replika ini beralih ke peran sekunder. Failover otomatis mengharuskan replika utama dan replika sekunder target berjalan dalam mode komit sinkron dengan mode failover yang diatur ke Otomatis. Selain itu, replika sekunder harus sudah disinkronkan, memiliki kuorum WSFC, dan memenuhi kondisi yang ditentukan oleh kebijakan failover fleksibel dari grup ketersediaan.

  • Dalam mode komit asinkron, satu-satunya bentuk failover adalah failover manual paksa (dengan kemungkinan kehilangan data), yang biasanya disebut failover paksa. Failover paksa dianggap sebagai bentuk failover manual karena hanya dapat dimulai secara manual. Failover paksa adalah opsi pemulihan bencana. Ini adalah satu-satunya bentuk failover yang dimungkinkan ketika replika sekunder target tidak disinkronkan dengan replika utama.

Untuk informasi selengkapnya, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

Penting

  • SQL Server Failover Cluster Instances (FCI) tidak mendukung failover otomatis oleh grup ketersediaan, sehingga replika ketersediaan apa pun yang dihosting oleh FCI hanya dapat dikonfigurasi untuk failover manual.
  • Jika Anda mengeluarkan perintah failover paksa pada replika sekunder yang disinkronkan, replika sekunder berulah sama seperti untuk failover manual yang direncanakan.

Keuntungan

Grup ketersediaan Always On menyediakan serangkaian opsi yang kaya yang meningkatkan ketersediaan database dan penggunaan sumber daya. Komponen utamanya adalah sebagai berikut:

  • Mendukung hingga sembilan replika ketersediaan. Replika ketersediaan adalah penciptaan grup ketersediaan yang dihosting oleh instans SQL Server tertentu dan menyimpan salinan lokal dari database ketersediaan yang termasuk dalam grup ketersediaan tersebut. Setiap grup ketersediaan mendukung satu replika utama dan hingga delapan replika sekunder. Untuk informasi selengkapnya, lihat Apa itu grup ketersediaan AlwaysOn?

    Penting

    Setiap replika ketersediaan harus berada pada node yang berbeda dari satu kluster Windows Server Failover Clustering (WSFC). Untuk informasi selengkapnya tentang prasyarat, pembatasan, dan rekomendasi untuk grup ketersediaan, lihat Prasyarat, pembatasan, dan rekomendasi untuk grup ketersediaan AlwaysOn.

  • Mendukung mode ketersediaan alternatif, sebagai berikut:

    • Mode komit asinkron. Mode ketersediaan ini adalah solusi pemulihan bencana yang berfungsi dengan baik ketika replika ketersediaan didistribusikan melalui jarak yang cukup jauh.

    • Mode penerapan sinkron. Mode ketersediaan ini menekankan ketersediaan tinggi dan perlindungan data atas performa, dengan biaya peningkatan latensi transaksi. Grup ketersediaan tertentu dapat mendukung hingga lima replika ketersediaan penerapan sinkron, termasuk replika utama saat ini.

      Untuk informasi selengkapnya, lihat Perbedaan antara mode ketersediaan untuk grup ketersediaan Always On.

  • Mendukung beberapa bentuk alih fungsi kelompok ketersediaan: alih fungsi otomatis, alih fungsi manual yang direncanakan (umumnya disebut sebagai "alih fungsi manual"), dan alih fungsi manual paksa (umumnya disebut sebagai "alih fungsi paksa"). Untuk informasi selengkapnya, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

  • Memungkinkan Anda mengonfigurasi replika ketersediaan tertentu untuk mendukung salah satu atau kedua kemampuan sekunder aktif berikut:

  • Mendukung pendengar grup ketersediaan untuk setiap grup ketersediaan. Pendengar grup ketersediaan Always On adalah nama server yang dapat dihubungkan oleh klien untuk mengakses database di replika utama atau sekunder dari grup ketersediaan Always On. Pendengar grup ketersediaan mengarahkan sambungan masuk ke replika utama atau ke replika sekunder yang bersifat baca-saja. Layanan pendengar menyediakan failover cepat untuk aplikasi setelah kegagalan pada kelompok ketersediaan. Untuk informasi selengkapnya, lihat Menyambungkan ke listener grup ketersediaan Always On.

  • Mendukung kebijakan failover yang fleksibel untuk kontrol yang lebih besar atas failover grup ketersediaan. Untuk informasi selengkapnya, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

  • Mendukung perbaikan halaman otomatis untuk perlindungan terhadap kerusakan halaman. Untuk informasi selengkapnya, lihat Perbaikan Halaman Otomatis (Grup Ketersediaan: Pencerminan Database).

  • Mendukung enkripsi dan kompresi, yang menyediakan transportasi yang aman dan berkinerja tinggi.

  • Menyediakan serangkaian alat terintegrasi untuk menyederhanakan penyebaran dan manajemen grup ketersediaan, termasuk:

Sambungan klien

Anda dapat menyediakan konektivitas klien ke replika utama grup ketersediaan tertentu dengan membuat pendengar grup ketersediaan. Pendengar grup ketersediaan menyediakan sekumpulan sumber daya yang terhubung dengan grup ketersediaan tertentu untuk mengarahkan koneksi klien ke replika ketersediaan yang sesuai.

Pendengar grup ketersediaan dikaitkan dengan nama DNS unik yang berfungsi sebagai nama jaringan virtual (VNN), satu atau beberapa alamat IP virtual (VIP), dan nomor port TCP. Untuk informasi selengkapnya, lihat Menyambungkan ke listener grup ketersediaan Always On.

Petunjuk

Jika grup ketersediaan hanya memiliki dua replika ketersediaan dan tidak dikonfigurasi untuk mengizinkan akses baca ke replika sekunder, klien dapat terhubung ke replika utama dengan menggunakan pencerminan database string koneksi. Pendekatan ini dapat berguna sementara setelah Anda memigrasikan database dari pencerminan database ke grup ketersediaan AlwaysOn. Sebelum menambahkan replika sekunder tambahan, Anda perlu membuat listener untuk grup ketersediaan dan memperbarui aplikasi Anda untuk menggunakan nama jaringan dari listener tersebut.

Replika sekunder aktif

Grup ketersediaan AlwaysOn mendukung replika sekunder aktif. Kemampuan sekunder aktif mencakup dukungan untuk:

  • Melakukan operasi pencadangan pada replika sekunder

    Replika sekunder mendukung pencadangan log dan pencadangan khusus salinan database lengkap, file, atau grup file. Anda dapat mengonfigurasi grup ketersediaan untuk menentukan preferensi tempat pencadangan harus dilakukan. Penting untuk dipahami bahwa preferensi tidak diberlakukan oleh SQL Server, sehingga tidak berpengaruh pada cadangan ad hoc. Interpretasi preferensi ini tergantung pada logika, jika ada, yang Anda skrip ke dalam pekerjaan cadangan Anda untuk setiap database dalam grup ketersediaan tertentu. Untuk replika ketersediaan individual, Anda dapat menentukan prioritas Anda untuk melakukan pencadangan pada replika ini relatif terhadap replika lain dalam grup ketersediaan yang sama. untuk informasi selengkapnya, lihat Mengalihkan cadangan yang didukung ke replika sekunder dari grup ketersediaan.

  • Akses baca-saja ke satu atau beberapa replika sekunder (replika sekunder yang dapat dibaca)

    Replika ketersediaan sekunder apa pun dapat dikonfigurasi untuk memungkinkan hanya akses baca-saja ke database lokalnya, meskipun beberapa operasi tidak sepenuhnya didukung. Ini mencegah upaya koneksi baca-tulis ke replika sekunder. Dimungkinkan juga untuk mencegah beban kerja baca-saja pada replika utama hanya dengan mengizinkan akses baca-tulis. Ini mencegah koneksi baca-saja dibuat ke replika utama. Untuk informasi selengkapnya, lihat Mengalihkan beban kerja hanya-baca ke replika sekunder Grup Ketersediaan Always On.

    Jika grup ketersediaan saat ini memiliki listener dan satu atau beberapa replika sekunder yang dapat dibaca, SQL Server dapat merutekan permintaan koneksi berniat membaca ke salah satunya (perutean baca-saja). Untuk informasi selengkapnya, lihat Menyambungkan ke listener grup ketersediaan Always On.

Periode waktu habis sesi

Periode batas waktu sesi adalah properti replika ketersediaan yang menentukan berapa lama koneksi dengan replika ketersediaan lain dapat tetap tidak aktif sebelum koneksi ditutup. Replika primer dan sekunder saling ping untuk memberi sinyal bahwa mereka masih aktif. Menerima ping dari replika lain selama periode batas waktu menunjukkan bahwa koneksi masih terbuka, dan bahwa instans server berkomunikasi. Saat menerima ping, replika ketersediaan mengatur ulang penghitung batas waktu sesinya pada koneksi tersebut.

Periode waktu habis sesi mencegah replika menunggu tanpa batas waktu untuk menerima ping dari replika lain. Jika tidak ada ping yang diterima dari replika lain dalam periode batas waktu sesi, replika akan habis waktu. Koneksi akan ditutup, dan replika yang habis waktu akan memasuki status TERPUTUS. Bahkan jika replika yang terputus dikonfigurasi untuk mode komit sinkron, transaksi tidak menunggu replika tersebut terhubung kembali dan sinkron kembali.

Batas waktu sesi default untuk setiap replika ketersediaan adalah 10 detik. Nilai ini dapat dikonfigurasi pengguna, dengan minimal 5 detik. Umumnya, kami sarankan Anda menjaga waktu tunggu pada 10 detik atau lebih. Mengatur nilai menjadi kurang dari 10 detik dapat menyebabkan kemungkinan sistem yang terbebani berat menyatakan kegagalan palsu.

Catatan

Dalam mode penyelesaian, periode batas waktu sesi tidak berlaku karena tidak ada ping.

Perbaikan halaman otomatis

Setiap replika ketersediaan mencoba memulihkan secara otomatis dari halaman yang rusak pada database lokal dengan menyelesaikan jenis kesalahan tertentu yang mencegah pembacaan halaman data. Jika replika sekunder tidak dapat membaca halaman, replika meminta salinan halaman baru dari replika utama. Jika replika utama tidak dapat membaca halaman, replika menyiarkan permintaan salinan baru ke semua replika sekunder dan mendapatkan halaman dari respon pertama. Jika permintaan ini berhasil, halaman yang tidak dapat dibaca digantikan oleh salinan, yang biasanya menyelesaikan kesalahan.

Untuk informasi selengkapnya, lihat Perbaikan Halaman Otomatis (Grup Ketersediaan: Pencerminan Database).

Interoperabilitas dan koeksistensi dengan fitur Mesin Database lainnya

Grup ketersediaan AlwaysOn dapat digunakan dengan fitur atau komponen SQL Server berikut:

Langkah selanjutnya

Mulai menggunakan grup ketersediaan AlwaysOn