Bagikan melalui

Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)

  • Artikel

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 diskrit, yang dikenal sebagai database ketersediaan, yang gagal bersama-sama. 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.

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

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 satu set 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. 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 terhubung, 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 tertentu harus berada di simpul yang berbeda dari kluster WSFC yang sama. Satu-satunya pengecualian adalah bahwa saat dimigrasikan ke kluster WSFC lain, grup ketersediaan dapat mengalihkan dua kluster untuk sementara.

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 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 SQL Server AlwaysOn 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 penerapan sinkron.

Grup ketersediaan dengan lima grup Ketersediaan replika

Database Ketersediaan

Untuk menambahkan database ke grup ketersediaan, database harus berupa database baca-tulis online 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 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 direproses 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 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 atau beberapa mitra failover 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 dari SQL Server berada di simpul yang berbeda dari kluster WSFC. Masing-masing instans server ini harus diaktifkan untuk AlwaysOn.

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 yang berdiri sendiri atau instans kluster failover (FCI) SQL Server. 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 RESOLVING sampai 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 hingga 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 sebagaireplika penerapan 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 memungkinkannya untuk tertinggal dari 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 datang dengan 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 primer 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 sebagai 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.

Tiga bentuk failover ada otomatis, manual, dan dipaksakan (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 synchronous-commit mendukung dua bentuk failover manual yang direncanakan failover dan failover otomatis, jika replika sekunder target saat ini disinkronkan dengan avt1. 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 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 dalam mode penerapan 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 Instans Kluster Failover (FCI) tidak mendukung failover otomatis oleh grup ketersediaan, sehingga replika ketersediaan apa pun yang dihosting oleh FCI hanya dapat dikonfigurasi untuk failover manual.

    Catatan

    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 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).

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

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 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 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 dari 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 pencadangan ad-hoc. Interpretasi preferensi ini tergantung pada logika, jika ada, yang Anda skrip ke dalam pekerjaan belakang 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 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 sepenuhnya didukung. 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 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 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 waktu habis 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 batas waktu 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, waktu replika habis. Koneksinya ditutup, dan replika waktu habis memasuki status TERPUTUS. Bahkan jika replika yang terputus dikonfigurasi untuk mode penerapan sinkron, transaksi tidak akan menunggu replika tersebut terhubung kembali dan menyinkronkan 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 membaca 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 yang pertama merespons. 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

Konten terkait

Lihat juga

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