Bagikan melalui

Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)

Topik ini memperkenalkan konsep Grup Ketersediaan AlwaysOn yang merupakan pusat untuk mengonfigurasi dan mengelola satu atau beberapa grup ketersediaan di SQL Server 2014. Untuk ringkasan manfaat yang ditawarkan oleh grup ketersediaan dan gambaran umum terminologi Grup Ketersediaan AlwaysOn, lihat Grup Ketersediaan AlwaysOn (SQL Server).

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 dan satu hingga delapan set database sekunder yang sesuai. Database sekunder bukan cadangan. Lanjutkan mencadangkan database Anda dan log transaksinya secara teratur.

Petunjuk / Saran

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 Sekunder Aktif: Pencadangan pada Replika Sekunder (Grup Ketersediaan AlwaysOn).

Setiap set dari database ketersediaan di-host oleh sebuah replika ketersediaan. Ada dua jenis replika ketersediaan: satu replika utama. yang menghosting database utama, dan satu hingga delapan replika sekunder, yang masing-masing menghosting satu set database sekunder dan berfungsi sebagai target failover potensial untuk grup ketersediaan. Grup ketersediaan mengalami kegagalan di 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 dicurigai karena kehilangan file data atau kerusakan log transaksi.

Replika utama membuat database utama tersedia untuk koneksi baca-tulis dari klien. Juga, dalam proses yang dikenal sebagai sinkronisasi data, yang terjadi di tingkat database. Replika utama mengirim catatan log transaksi dari setiap database utama ke setiap database sekunder. 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.

Menyebarkan Grup Ketersediaan AlwaysOn memerlukan kluster Windows Server Failover Clustering (WSFC). Setiap replika ketersediaan dari grup ketersediaan yang diberikan harus berada pada node yang berbeda pada kluster WSFC yang sama. Satu-satunya pengecualian adalah bahwa saat dimigrasikan ke kluster WSFC lain, grup ketersediaan dapat menjembatani dua kluster untuk sementara waktu.

Grup sumber daya WSFC dibuat untuk setiap grup ketersediaan yang Anda buat. Kluster WSFC memantau grup sumber daya 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. Berbeda dengan pencerminan database, tidak ada peran saksi dalam Grup Ketersediaan AlwaysOn.

Nota

Untuk informasi tentang hubungan komponen AlwaysOn SQL Server ke kluster WSFC, lihat Pengklusteran Failover Windows Server (WSFC) 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 dua replika sekunder komit sinkron.

Grup ketersediaan dengan lima replika

Basis Data 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 proses pemulihan hingga bergabung ke grup ketersediaan. Untuk informasi selengkapnya, lihat Memulai Pergerakan Data pada Database Sekunder AlwaysOn (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 AlwaysOn 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 AlwaysOn.

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.

Nota

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 hingga replika sekunder tertentu telah menulis catatan log transaksi ke disk (memperkuat log). Grup Ketersediaan Always On mendukung dua mode ketersediaan: mode komit asinkron dan mode komit sinkron.

  • Mode penerapan asinkron

    Replika ketersediaan yang menggunakan mode ketersediaan ini dikenal sebagai replika commit asinkron. Dalam mode penerapan asinkron, replika utama melakukan transaksi tanpa menunggu pengakuan bahwa replika sekunder penerapan asinkron telah mengeraskan log. 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.

Untuk informasi selengkapnya, lihat Mode Ketersediaan (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 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.

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 sinkron-komit mendukung dua bentuk failover manual yang direncanakan dan failover otomatis, jika replika sekunder target sedang disinkronkan dengan avt1. 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 sedang berjalan dalam mode komit sinkron dengan mode failover diatur ke "Otomatis". Selain itu, replika sekunder harus sudah disinkronkan, memiliki kuorum WSFC, dan memenuhi kondisi yang ditentukan oleh kebijakan failover fleksibeldari grup ketersediaan.

      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.

    Nota

    Perhatikan bahwa jika Anda mengeluarkan perintah failover paksa pada replika sekunder yang disinkronkan, replika sekunder berprilaku sama seperti untuk failover manual yang direncanakan.

  • 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 Failover dan Mode Failover (Grup Ketersediaan AlwaysOn).

Koneksi 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 Listener Grup Ketersediaan, Konektivitas Klien, dan Failover Aplikasi (SQL Server).

Petunjuk / Saran

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 string koneksi pencerminan database. 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 dan memperbarui aplikasi Anda untuk menggunakan nama jaringan pendengar 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 berdampak pada cadangan ad-hoc. Interpretasi preferensi ini tergantung pada logika, jika ada, yang Anda tuliskan dalam tugas belakang Anda untuk setiap database dalam grup yang tersedia. 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 Sekunder Aktif: Pencadangan pada Replika Sekunder (Grup Ketersediaan AlwaysOn).

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

    Replika ketersediaan apa pun dapat dikonfigurasi untuk memungkinkan akses baca-saja ke database lokalnya saat melakukan peran sekunder, meskipun beberapa operasi tidak didukung sepenuhnya. Selain itu, jika Anda ingin mencegah beban kerja baca-saja berjalan pada replika utama, Anda dapat mengonfigurasi replika untuk hanya mengizinkan akses baca-tulis saat berjalan di bawah peran utama. Untuk informasi selengkapnya, lihat Sekunder Aktif: Replika Sekunder yang Dapat Dibaca (Grup Ketersediaan AlwaysOn).

    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 Listener Grup Ketersediaan, Konektivitas Klien, dan Failover Aplikasi (SQL Server).

Periode Session-Timeout

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 akan menunggu replika tersebut terhubung kembali dan melakukan sinkronisasi ulang.

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.

Nota

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 (Untuk Grup Ketersediaan dan Pencerminan Database).

Tugas Terkait

Isi Terkait

Lihat Juga

Mode Ketersediaan (Grup Ketersediaan AlwaysOn)Failover dan Mode Failover (Grup Ketersediaan AlwaysOn)Gambaran Umum Pernyataan Transact-SQL untuk Grup Ketersediaan AlwaysOn (SQL Server)Gambaran Umum Cmdlet PowerShell untuk Grup Ketersediaan AlwaysOn (SQL Server)Dukungan Ketersediaan Tinggi untuk database OLTP In-MemoryPrasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server)Pembuatan dan Konfigurasi Grup Ketersediaan (SQL Server)Sekunder Aktif: Replika Sekunder yang Dapat Dibaca (Grup Ketersediaan AlwaysOn)Sekunder Aktif: Pencadangan pada Replika Sekunder (Grup Ketersediaan AlwaysOn)Listener Grup Ketersediaan, Konektivitas Klien, dan Failover Aplikasi (SQL Server)

  • Last updated on