Bagikan melalui

Apa itu grup ketersediaan AlwaysOn?

  • Artikel

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 dikenal sebagai database ketersediaan, yang gagal bersama-sama. 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 diskrit, yang dikenal sebagai database ketersediaan. Anda dapat membuat grup ketersediaan untuk ketersediaan tinggi (HA) atau untuk skala baca. Grup ketersediaan KETERSEDIAAN TINGGI adalah sekelompok database yang gagal bersama-sama. 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. Lanjutkan untuk mencadangkan database Anda dan log transaksi mereka secara teratur.

Tip

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 Membongkar 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 tersangka karena 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 AlwaysOn menyediakan ketersediaan tinggi, pemulihan bencana, dan penyeimbangan skala 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 skala baca. 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 otomatis.

Menyebarkan grup ketersediaan AlwaysOn untuk KETERSEDIAAN TINGGI di Windows memerlukan Kluster Failover Windows Server (WSFC). Setiap replika ketersediaan grup ketersediaan tertentu harus berada di simpul yang berbeda dari WSFC yang sama. Satu-satunya pengecualian adalah bahwa saat dimigrasikan ke kluster WSFC lain, grup ketersediaan dapat mengangsur dua kluster untuk sementara.

Catatan

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

Dalam konfigurasi KETERSEDIAAN TINGGI, peran kluster dibuat untuk setiap grup ketersediaan yang Anda buat. Kluster WSFC memantau peran ini untuk mengevaluasi kesehatan replika utama. Kuorum untuk grup ketersediaan AlwaysOn didasarkan pada semua simpul di kluster WSFC terlepas dari apakah node kluster tertentu 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 penerapan sinkron.

Diagram grup ketersediaan dengan lima replika.

Syarat dan definisi

Persyaratan Deskripsi
grup ketersediaan Kontainer untuk sekumpulan database, database ketersediaan, yang gagal bersama-sama.
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 baca-tulis database ketersediaan.
database sekunder Salinan database ketersediaan baca-saja.
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 koneksi masuk ke replika utama atau ke replika sekunder baca-saja.

Database ketersediaan

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 terkadang disebut replika database dalam nama Transact-SQL, PowerShell, dan 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 dari grup ketersediaan. Setiap replika ketersediaan menghosting salinan database ketersediaan dalam grup 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.

Instans tertentu hanya dapat menghosting satu replika ketersediaan per grup ketersediaan. Namun, setiap 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 diatur ke PENYELESAIAN hingga peran replika ketersediaan telah diselesaikan. Jika replika ketersediaan diselesaikan ke peran utama, databasenya menjadi database utama. Jika replika ketersediaan diselesaikan ke peran sekunder, databasenya menjadi database sekunder.

Mode ketersediaan

Mode ketersediaan adalah 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 AlwaysOn mendukung dua mode ketersediaan: mode penerapan asinkron dan mode penerapan sinkron.

  • Mode penerapan asinkron

    Replika ketersediaan yang menggunakan mode ketersediaan ini dikenal sebagai replika penerapan 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 penerapan 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 penerapan sinkron memastikan bahwa setelah database sekunder tertentu disinkronkan dengan database utama, transaksi yang diterapkan sepenuhnya dilindungi. Perlindungan ini dikenakan biaya peningkatan latensi transaksi. Secara opsional, SQL Server 2017 memperkenalkan fitur sekunder yang disinkronkan yang diperlukan untuk lebih meningkatkan keamanan dengan biaya latensi jika diinginkan. Fitur REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT dapat diaktifkan untuk mewajibkan sejumlah replika sinkron tertentu untuk melakukan transaksi sebelum replika utama diizinkan untuk diterapkan.

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

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 membawa databasenya online karena database utama, dan aplikasi klien dapat terhubung ke database tersebut. Ketika replika utama sebelumnya tersedia, 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 database yang menjadi tersangka karena hilangnya file data, penghapusan database, atau kerusakan log transaksi.

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

  • Mode penerapan sinkron mendukung dua bentuk failover manual yang direncanakan failover dan failover otomatis, jika replika sekunder target saat ini disinkronkan dengan replika utama. Dukungan untuk bentuk 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 yang 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 berjalan dalam mode penerapan 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 tersebut beralih ke peran sekunder. Failover otomatis mengharuskan replika utama dan replika sekunder target berjalan di bawah mode penerapan 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.

  • Di bawah mode penerapan asinkron, satu-satunya bentuk failover adalah failover manual paksa (dengan kemungkinan kehilangan data), 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 instans grup ketersediaan yang dihosting oleh instans SQL Server tertentu dan mempertahankan salinan lokal dari setiap database ketersediaan yang termasuk dalam grup ketersediaan. 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 penerapan 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 AlwaysOn.

  • Mendukung beberapa bentuk failover grup ketersediaan: failover otomatis, failover manual yang direncanakan (umumnya disebut sebagai "failover manual"), dan failover manual paksa (umumnya disebut sebagai "failover 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:

    • Akses koneksi baca-saja yang memungkinkan koneksi baca-saja ke replika untuk mengakses dan membaca databasenya saat berjalan sebagai replika sekunder. Untuk informasi selengkapnya, lihat Membongkar beban kerja baca-saja ke replika sekunder grup ketersediaan AlwaysOn.

    • Melakukan operasi pencadangan pada databasenya saat berjalan sebagai replika sekunder. Untuk informasi selengkapnya, lihat Membongkar cadangan yang didukung ke replika sekunder dari grup ketersediaan.

      Menggunakan kemampuan sekunder aktif meningkatkan efisiensi TI Anda dan mengurangi biaya melalui pemanfaatan sumber daya perangkat keras sekunder yang lebih baik. Selain itu, membongkar aplikasi niat baca dan pekerjaan pencadangan ke replika sekunder membantu meningkatkan performa pada replika utama.

  • Mendukung listener grup ketersediaan untuk setiap grup ketersediaan. Pendengar grup ketersediaan adalah nama server yang dapat disambungkan klien, untuk mengakses database di replika utama atau sekunder dari grup ketersediaan AlwaysOn. Pendengar grup ketersediaan mengarahkan koneksi masuk ke replika utama atau ke replika sekunder baca-saja. Pendengar menyediakan failover aplikasi cepat setelah grup ketersediaan gagal. Untuk informasi selengkapnya, lihat Menyambungkan ke listener grup ketersediaan AlwaysOn.

  • 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 dilampirkan ke 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 AlwaysOn.

Tip

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 harus membuat pendengar grup ketersediaan untuk grup ketersediaan dan memperbarui aplikasi Anda untuk menggunakan nama jaringan pendengar.

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 Membongkar 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 Membongkar beban kerja baca-saja ke replika sekunder grup ketersediaan AlwaysOn.

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

Periode batas waktu 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 waktu habis sesi, waktu replika habis. Koneksinya ditutup, dan replika waktu habis memasuki status TERPUTUS. Bahkan jika replika yang terputus dikonfigurasi untuk mode penerapan sinkron, transaksi tidak menunggu replika tersebut terhubung kembali dan disinkronkan ulang.

Periode 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 periode waktu habis pada 10 detik atau lebih besar. Mengatur nilai menjadi kurang dari 10 detik menciptakan kemungkinan sistem yang sangat dimuat yang menyatakan kegagalan palsu.

Catatan

Dalam peran penyelesaian, periode batas waktu sesi tidak berlaku karena ping tidak terjadi.

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