Prasyarat, Pembatasan, dan Rekomendasi untuk grup ketersediaan Always On

  • Artikel
  • 18 menit untuk membaca

Berlaku untuk:yes SQL Server (semua versi yang didukung)

Artikel ini menjelaskan pertimbangan untuk menyebarkan grup ketersediaan AlwaysOn, termasuk prasyarat, pembatasan, dan rekomendasi untuk komputer host, kluster failover Windows Server (WSFC), instans server, dan grup ketersediaan. Untuk setiap pertimbangan keamanan komponen ini dan izin yang diperlukan, jika ada, ditunjukkan.

Penting

Sebelum Anda menyebarkan grup ketersediaan AlwaysOn, kami sangat menyarankan Anda membaca setiap bagian dari topik ini.

Hotfix .NET yang Mendukung Grup Ketersediaan

Bergantung pada komponen dan fitur SQL Server yang akan Anda gunakan dengan grup ketersediaan AlwaysOn, Anda mungkin perlu menginstal perbaikan .NET tambahan yang diidentifikasi dalam tabel berikut. Perbaikan dapat diinstal dalam urutan apa pun.

Fitur Dependen Perbaikan terbaru Tautan
SQL Server Reporting Services Hotfix untuk .NET 3.5 SP1 menambahkan dukungan ke SQL Client untuk fitur Always On dari read-intent, readonly, dan multisubnetfailover. Perbaikan perlu diinstal pada setiap server laporan Reporting Services. KB 2654347: Hotfix untuk .NET 3.5 SP1 untuk menambahkan dukungan untuk fitur AlwaysOn

Daftar periksa: Persyaratan (Sistem Windows)

Untuk mendukung fitur grup ketersediaan AlwaysOn, pastikan bahwa setiap komputer yang akan berpartisipasi dalam satu atau beberapa grup ketersediaan memenuhi persyaratan mendasar berikut:

Persyaratan Tautan
Pastikan bahwa sistem bukan pengendali domain. Grup ketersediaan tidak didukung pada pengendali domain.
Pastikan bahwa setiap komputer menjalankan Windows Server 2012 atau versi yang lebih baru. Persyaratan Perangkat Keras dan Perangkat Lunak untuk Menginstal SQL Server 2016
Pastikan bahwa setiap komputer adalah simpul dalam WSFC. Windows Pengklusteran Failover Server (WSFC) dengan SQL Server
Pastikan WSFC berisi simpul yang memadai untuk mendukung konfigurasi grup ketersediaan Anda. Node kluster dapat menghosting satu replika untuk grup ketersediaan. Simpul yang sama tidak dapat menghosting dua replika dari grup ketersediaan yang sama. Node kluster dapat berpartisipasi dalam beberapa grup ketersediaan, dengan satu replika dari setiap grup.

Tanyakan kepada administrator database Anda berapa banyak node kluster yang diperlukan untuk mendukung replika ketersediaan grup ketersediaan yang direncanakan.

Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server).

Penting

Pastikan juga bahwa lingkungan Anda dikonfigurasi dengan benar untuk menyambungkan ke grup ketersediaan. Untuk informasi selengkapnya, lihat Always On Client Connectivity (SQL Server).

Rekomendasi untuk Komputer yang Menghosting Replika Ketersediaan (Sistem Windows)

  • Sistem yang sebanding: Untuk grup ketersediaan tertentu, semua replika ketersediaan harus berjalan pada sistem yang sebanding yang dapat menangani beban kerja yang identik.

  • Adaptor jaringan khusus: Untuk performa terbaik, gunakan adaptor jaringan khusus (kartu antarmuka jaringan) untuk grup ketersediaan AlwaysOn.

  • Ruang disk yang cukup: Setiap komputer tempat instans server menghosting replika ketersediaan harus memiliki ruang disk yang memadai untuk semua database dalam grup ketersediaan. Perlu diingat bahwa seiring pertumbuhan database utama, database sekunder yang sesuai tumbuh jumlah yang sama.

Izin (Sistem Windows)

Untuk mengelola WSFC, pengguna harus menjadi administrator sistem pada setiap node kluster.

Untuk informasi selengkapnya tentang akun untuk mengelola kluster, lihat Lampiran A: Persyaratan Kluster Failover.

Tugas Terkait (Sistem Windows)

Tugas Tautan
Atur nilai HostRecordTTL. Mengubah HostRecordTTL (Menggunakan Windows PowerShell)

Mengubah HostRecordTTL (Menggunakan Windows PowerShell)

  1. Buka jendela PowerShell melalui Jalankan sebagai Administrator.

  2. Impor modul FailoverClusters.

  3. Gunakan cmdlet Get-ClusterResource untuk menemukan sumber daya Nama Jaringan, lalu gunakan cmdlet Set-ClusterParameter untuk mengatur nilai HostRecordTTL , sebagai berikut:

    Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    Contoh PowerShell berikut mengatur HostRecordTTL menjadi 300 detik untuk sumber daya Nama Jaringan bernama SQL Network Name (SQL35).

    Import-Module FailoverClusters  

$nameResource = "SQL Network Name (SQL35)"  
Get-ClusterResource $nameResource | Set-ClusterParameter ClusterParameter HostRecordTTL 300

    Tip

    Setiap kali Anda membuka jendela PowerShell baru, Anda perlu mengimpor modul FailoverClusters .

Konten Terkait (PowerShell)

Isi Terkait (Sistem Windows)

Prasyarat dan Pembatasan Instans SQL Server

Setiap grup ketersediaan memerlukan sekumpulan mitra failover, yang dikenal sebagai replika ketersediaan, yang dihosting oleh instans SQL Server. Instans server tertentu dapat berupa instans yang berdiri sendiri atau instans kluster SQL Server failover (FCI).

Di bagian ini:

Daftar periksa: Prasyarat (Instans Server)

Prasyarat Tautan
Komputer host harus merupakan simpul WSFC. Instans SQL Server bahwa replika ketersediaan host untuk grup ketersediaan tertentu berada pada simpul terpisah dari kluster. Grup ketersediaan untuk sementara dapat mengalihkan dua kluster saat dimigrasikan ke kluster yang berbeda. SQL Server 2016 memperkenalkan grup ketersediaan terdistribusi. Dalam grup ketersediaan terdistribusi, dua grup ketersediaan berada di kluster yang berbeda. Windows Pengklusteran Failover Server (WSFC) dengan SQL Server

Pengklusteran Failover dan Grup Ketersediaan AlwaysOn (SQL Server)

Grup Ketersediaan Terdistribusi (Grup Ketersediaan AlwaysOn)
Jika Anda ingin grup ketersediaan berfungsi dengan Kerberos:

Semua instans server yang menghosting replika ketersediaan untuk grup ketersediaan harus menggunakan akun layanan SQL Server yang sama.

Administrator domain perlu mendaftarkan Nama Prinsipal Layanan (SPN) secara manual dengan Direktori Aktif pada akun layanan SQL Server untuk nama jaringan virtual (VNN) pendengar grup ketersediaan. Jika SPN terdaftar di akun selain akun layanan SQL Server, autentikasi akan gagal.



** Penting ** Jika Anda mengubah akun layanan SQL Server, administrator domain harus mendaftarkan ulang SPN secara manual.		 Mendaftarkan Nama Perwakilan Layanan untuk Koneksi Kerberos

Penjelasan singkat:

Kerberos dan SPN memberlakukan autentikasi bersama. SPN memetakan ke akun Windows yang memulai layanan SQL Server. Jika SPN tidak terdaftar dengan benar atau jika gagal, lapisan keamanan Windows tidak dapat menentukan akun yang terkait dengan SPN, dan autentikasi Kerberos tidak dapat digunakan.



Catatan: NTLM tidak memiliki persyaratan ini.
Jika Anda berencana menggunakan SQL Server instans kluster failover (FCI) untuk menghosting replika ketersediaan, pastikan Anda memahami pembatasan FCI dan bahwa persyaratan FCI terpenuhi. Prasyarat dan Persyaratan tentang Menggunakan Instans Kluster Failover (FCI) SQL Server untuk Menghosting Replika Ketersediaan (nanti di artikel ini)
Setiap instans server harus menjalankan versi SQL Server yang sama untuk berpartisipasi dalam Grup Ketersediaan AlwaysOn. Edisi dan fitur yang didukung untuk SQL 2014, SQL 2016, SQL 2017.
Semua instans server yang menghosting replika ketersediaan untuk grup ketersediaan harus menggunakan kolase SQL Server yang sama. Mengatur atau Mengubah Kolase Server
Aktifkan fitur grup ketersediaan AlwaysOn pada setiap instans server yang akan menghosting replika ketersediaan untuk grup ketersediaan apa pun. Di komputer tertentu, Anda dapat mengaktifkan instans server sebanyak mungkin untuk grup ketersediaan AlwaysOn seperti yang didukung penginstalan SQL Server Anda. Mengaktifkan dan Menonaktifkan Grup Ketersediaan AlwaysOn (SQL Server)



** Penting ** Jika Anda menghancurkan dan membuat ulang WSFC, Anda harus menonaktifkan dan mengaktifkan kembali fitur grup ketersediaan AlwaysOn pada setiap instans server yang diaktifkan untuk grup ketersediaan AlwaysOn pada kluster asli.
Setiap instans server memerlukan titik akhir pencerminan database. Perhatikan bahwa titik akhir ini dibagikan oleh semua replika ketersediaan dan mitra pencerminan database dan saksi pada instans server.

Jika instans server yang Anda pilih untuk menghosting replika ketersediaan berjalan di bawah akun pengguna domain dan belum memiliki titik akhir pencerminan database, Wizard Grup Ketersediaan Baru (atau Tambahkan Replika ke Wizard Grup Ketersediaan) dapat membuat titik akhir dan memberikan izin CONNECT ke akun layanan instans server. Namun, jika layanan SQL Server berjalan sebagai akun bawaan, seperti Sistem Lokal, Layanan Lokal, atau Layanan Jaringan, atau akun nondomain, Anda harus menggunakan sertifikat untuk autentikasi titik akhir, dan wizard tidak akan dapat membuat titik akhir pencerminan database pada instans server. Dalam hal ini, kami sarankan Anda membuat titik akhir pencerminan database secara manual sebelum Anda meluncurkan wizard.



** Catatan Keamanan ** Keamanan transportasi untuk grup ketersediaan AlwaysOn sama dengan pencerminan database.		 Titik Akhir Pencerminan Database (SQL Server)

Keamanan Transportasi untuk Pencerminan Database dan Grup Ketersediaan AlwaysOn (SQL Server)
Jika ada database yang menggunakan FILESTREAM akan ditambahkan ke grup ketersediaan, pastikan bahwa FILESTREAM diaktifkan pada setiap instans server yang akan menghosting replika ketersediaan untuk grup ketersediaan. Mengaktifkan dan Mengonfigurasi FILESTREAM
Jika ada database mandiri yang akan ditambahkan ke grup ketersediaan, pastikan bahwa opsi server autentikasi database mandiri diatur ke 1 pada setiap instans server yang akan menghosting replika ketersediaan untuk grup ketersediaan. Opsi Konfigurasi Server autentikasi database yang terkandung

Opsi Konfigurasi Server (SQL Server)

Penggunaan Utas menurut Grup Ketersediaan

Grup ketersediaan AlwaysOn memiliki persyaratan berikut untuk utas pekerja:

  • Pada instans SQL Server yang menganggur, grup ketersediaan AlwaysOn menggunakan 0 utas.

  • Jumlah maksimum utas yang digunakan oleh grup ketersediaan adalah pengaturan yang dikonfigurasi untuk jumlah maksimum utas server ('utas pekerja maks') dikurangi 40.

  • Replika ketersediaan yang dihosting pada instans server tertentu berbagi satu kumpulan utas.

    Utas dibagikan berdasarkan permintaan, sebagai berikut:

    • Biasanya, ada 3-10 utas bersama, tetapi jumlah ini dapat meningkat tergantung pada beban kerja replika utama.

    • Jika utas tertentu diam untuk sementara waktu, utas tersebut dilepaskan kembali ke kumpulan utas SQL Server umum. Biasanya, utas tidak aktif dirilis setelah ~ 15 detik tidak aktif. Namun, tergantung pada aktivitas terakhir, utas diam mungkin dipertahankan lebih lama.

    • Instans SQL Server menggunakan hingga 100 utas untuk pengulangan paralel untuk replika sekunder. Setiap database menggunakan hingga satu setengah dari jumlah total inti CPU, tetapi tidak lebih dari 16 utas per database. Jika jumlah total utas yang diperlukan untuk satu instans melebihi 100, SQL Server menggunakan satu utas pengulangan untuk setiap database yang tersisa. Utas Pengulangan Serial dirilis setelah ~15 detik tidak aktif.

  • Selain itu, grup ketersediaan menggunakan utas yang tidak dibagikan, sebagai berikut:

    • Setiap replika utama menggunakan 1 utas Pengambilan Log untuk setiap database utama. Selain itu, ia menggunakan 1 utas Kirim Log untuk setiap database sekunder. Alur pengiriman log dirilis setelah ~15 detik tidak aktif.

    • Cadangan pada replika sekunder menyimpan utas pada replika utama selama operasi pencadangan.

  • SQL Server 2019 memperkenalkan pengulangan paralel untuk database grup ketersediaan yang dioptimalkan memori. Pada SQL Server 2016 dan 2017, tabel berbasis disk tidak menggunakan pengulangan paralel jika database dalam grup ketersediaan juga dioptimalkan memori.

Untuk informasi selengkapnya, lihat Always On - HADRON Pembelajaran Series: Penggunaan Kumpulan Pekerja untuk Database yang Diaktifkan HADRON (Blog Teknisi SQL Server CSS).

Izin (Instans Server)

Tugas Izin yang Diperlukan
Membuat titik akhir pencerminan database Memerlukan izin CREATE ENDPOINT, atau keanggotaan dalam peran server tetap sysadmin . Juga memerlukan izin CONTROL ON ENDPOINT. Untuk informasi selengkapnya, lihat GRANT Endpoint Permissions (Transact-SQL).
Mengaktifkan grup ketersediaan AlwaysOn Memerlukan keanggotaan dalam grup Administrator di komputer lokal dan kontrol penuh pada WSFC.

Tugas Terkait (Instans Server)

Tugas Artikel
Menentukan apakah titik akhir pencerminan database ada sys.database_mirroring_endpoints (SQL Bertransaksi)
Membuat titik akhir pencerminan database (jika belum ada) Membuat Titik Akhir Pencerminan Database untuk Autentikasi Windows (Transact-SQL)

Menggunakan Sertifikat untuk Titik Akhir Database Mirroring (Transact-SQL)

Membuat Titik Akhir Pencerminan Database untuk Grup Ketersediaan AlwaysOn (SQL Server PowerShell)
Mengaktifkan Grup Ketersediaan Mengaktifkan dan Menonaktifkan Grup Ketersediaan AlwaysOn (SQL Server)

Konten Terkait (Instans Server)

Rekomendasi Konektivitas Jaringan

Kami sangat menyarankan Anda menggunakan tautan jaringan yang sama untuk komunikasi antara simpul WSFC dan komunikasi antara replika ketersediaan. Menggunakan tautan jaringan terpisah dapat menyebabkan perilaku tak terduga jika beberapa tautan gagal (bahkan secara terputus-putus).

Misalnya, agar grup ketersediaan mendukung failover otomatis, replika sekunder yang merupakan mitra failover otomatis harus dalam status DISINKRONKAN. Jika tautan jaringan ke replika sekunder ini gagal (bahkan terputus-putus), replika memasuki status UNSYNCHRONIZED dan tidak dapat mulai menyinkronkan ulang sampai tautan dipulihkan. Jika WSFC meminta failover otomatis saat replika sekunder tidak disinkronkan, failover otomatis tidak akan terjadi.

Dukungan Konektivitas Klien

Untuk informasi tentang dukungan grup ketersediaan AlwaysOn untuk konektivitas klien, lihat Konektivitas Klien AlwaysOn (SQL Server).

Prasyarat dan Pembatasan untuk Menggunakan Instans Kluster Failover SQL Server (FCI) untuk Menghosting Replika Ketersediaan

Di bagian ini:

Pembatasan (FCI)

Catatan

Instans Kluster Failover mendukung Volume Bersama Terkluster (CSV). Untuk informasi selengkapnya tentang CSV, lihat Memahami Volume Bersama Kluster dalam Kluster Failover.

  • Node kluster FCI hanya dapat menghosting satu replika untuk grup ketersediaan tertentu: Jika Anda menambahkan replika ketersediaan pada FCI, simpul WSFC yang mungkin merupakan pemilik FCI tidak dapat menghosting replika lain untuk grup ketersediaan yang sama. Untuk menghindari kemungkinan konflik, disarankan untuk mengonfigurasi kemungkinan pemilik untuk instans kluster failover. Ini akan mencegah berpotensi menyebabkan satu WSFC mencoba menghosting dua replika ketersediaan untuk grup ketersediaan yang sama.

    Selain itu, setiap replika lainnya harus dihosting oleh instans SQL Server 2016 yang berada pada node kluster yang berbeda di kluster failover Windows Server yang sama. Satu-satunya pengecualian adalah bahwa saat dimigrasikan ke kluster lain, grup ketersediaan dapat mengangsur dua kluster untuk sementara.

Peringatan

Menggunakan Manajer Kluster Failover untuk memindahkan instans kluster failover yang menghosting grup ketersediaan ke node yang sudah menghosting replika grup ketersediaan yang sama dapat mengakibatkan hilangnya replika grup ketersediaan, mencegahnya dibawa online pada simpul target. Satu simpul kluster failover tidak dapat menghosting lebih dari satu replika untuk grup ketersediaan yang sama. Untuk informasi selengkapnya tentang bagaimana hal ini terjadi, dan cara memulihkannya, lihat blog Replika yang tiba-tiba dihilangkan dalam grup ketersediaan.

  • FCI tidak mendukung failover otomatis menurut grup ketersediaan: FCI tidak mendukung failover otomatis oleh grup ketersediaan, sehingga replika ketersediaan apa pun yang dihosting oleh FCI hanya dapat dikonfigurasi untuk failover manual.

  • Mengubah nama jaringan FCI: Jika Anda perlu mengubah nama jaringan FCI yang menghosting replika ketersediaan, Anda harus menghapus replika dari grup ketersediaannya lalu menambahkan replika kembali ke grup ketersediaan. Anda tidak dapat menghapus replika utama, jadi jika Anda mengganti nama FCI yang menghosting replika utama, Anda harus melakukan failover ke replika sekunder lalu menghapus replika utama sebelumnya dan menambahkannya kembali. Perhatikan bahwa mengganti nama FCI mungkin mengubah URL titik akhir pencerminan databasenya. Saat Anda menambahkan replika, pastikan Anda menentukan URL titik akhir saat ini.

Daftar periksa: Prasyarat (FCI)

Prasyarat Tautan
Pastikan bahwa setiap SQL Server instans kluster failover (FCI) memiliki penyimpanan bersama yang diperlukan sesuai penginstalan instans kluster failover SQL Server standar.

Tugas Terkait (FCI)

Tugas Artikel
Menginstal Kluster Failover SQL Server Membuat Kluster Failover SQL Server Baru (Penyiapan)
Peningkatan di tempat kluster failover SQL Server yang ada Meningkatkan Instans Kluster Failover SQL Server (Penyiapan)
Mempertahankan Kluster Failover SQL Server yang ada Menambahkan atau Menghapus Simpul dalam Kluster Failover SQL Server (Penyiapan)

Konten Terkait (FCI)

Prasyarat dan Pembatasan Grup Ketersediaan

Di bagian ini:

Pembatasan (Grup Ketersediaan)

  • Replika ketersediaan harus dihosting oleh simpul yang berbeda dari satu WSFC: Untuk grup ketersediaan tertentu, replika ketersediaan harus dihosting oleh instans server yang berjalan pada simpul yang berbeda dari WSFC yang sama. Satu-satunya pengecualian adalah bahwa saat dimigrasikan ke kluster lain, grup ketersediaan dapat mengalihkan dua kluster untuk sementara.

    Catatan

    Komputer virtual pada komputer fisik yang sama masing-masing dapat menghosting replika ketersediaan untuk grup ketersediaan yang sama karena setiap komputer virtual bertindak sebagai komputer terpisah.

  • Nama grup ketersediaan unik: Setiap nama grup ketersediaan harus unik di WSFC. Panjang maksimum untuk nama grup ketersediaan adalah 128 karakter.

  • Replika ketersediaan: Setiap grup ketersediaan mendukung satu replika utama dan hingga delapan replika sekunder. Semua replika dapat berjalan di bawah mode penerapan asinkron, atau hingga lima replika dapat berjalan di bawah mode penerapan sinkron (satu replika utama dengan dua replika sekunder sinkron). Setiap replika harus memiliki nama server yang unik di Windows dan SQL Server. Nama server antara Windows dan SQL Server harus cocok.

  • Jumlah maksimum grup ketersediaan dan database ketersediaan per komputer: Jumlah database dan grup ketersediaan aktual yang dapat Anda letakkan di komputer (VM atau fisik) tergantung pada perangkat keras dan beban kerja, tetapi tidak ada batas yang diberlakukan. Microsoft telah menguji hingga 10 AG dan 100 DB per komputer fisik, namun ini bukan batas pengikatan. Bergantung pada spesifikasi perangkat keras di server dan beban kerja, Anda dapat menempatkan jumlah database dan grup ketersediaan yang lebih tinggi pada instans SQL Server. Tanda-tanda sistem yang kelebihan beban dapat mencakup, tetapi tidak terbatas pada, kelelahan utas pekerja, waktu respons lambat untuk tampilan sistem grup ketersediaan dan DMV, dan/atau cadangan sistem dispatcher yang terhenti. Pastikan untuk menguji lingkungan Anda secara menyeluruh dengan beban kerja seperti produksi untuk memastikannya dapat menangani kapasitas beban kerja puncak dalam SLA aplikasi Anda. Saat mempertimbangkan SLA, pastikan untuk mempertimbangkan beban dalam kondisi kegagalan serta waktu respons yang diharapkan.

  • Jangan gunakan Manajer Kluster Failover untuk memanipulasi grup ketersediaan. Status SQL Server Failover Cluster Instance (FCI) dibagikan antara SQL Server dan Windows Failover Cluster (WSFC), dengan SQL Server menyimpan informasi status yang lebih rinci tentang instans daripada yang dipedulikan kluster. Model manajemen adalah bahwa SQL Server harus mendorong transaksi, dan bertanggung jawab untuk menjaga tampilan kluster tetap sinkron dengan tampilan status SQL Server. Jika status kluster diubah di luar SQL Server dimungkinkan bagi status untuk tidak sinkron antara WSFC dan SQL Server, yang dapat menyebabkan perilaku yang tidak dapat diprediksi.

    Contohnya:

    • Jangan ubah properti grup ketersediaan apa pun, seperti kemungkinan pemilik.

    • Jangan gunakan Manajer Kluster Failover untuk mengalihkan grup ketersediaan. Anda harus menggunakan transact-SQL atau SQL Server Management Studio.

Prasyarat (Grup Ketersediaan)

Saat membuat atau mengonfigurasi ulang konfigurasi grup ketersediaan, pastikan Anda mematuhi persyaratan berikut.

Prasyarat Deskripsi
Jika Anda berencana menggunakan SQL Server instans kluster failover (FCI) untuk menghosting replika ketersediaan, pastikan Anda memahami pembatasan FCI dan bahwa persyaratan FCI terpenuhi. Prasyarat dan Pembatasan untuk Menggunakan SQL Server Instans Kluster Failover (FCI) untuk Menghosting Replika Ketersediaan (sebelumnya dalam artikel ini)

Keamanan (Grup Ketersediaan)

  • Keamanan diwariskan dari WSFC. Windows Pengklusteran failover Server menyediakan dua tingkat keamanan pengguna pada granularitas seluruh kluster:

    • Akses baca-saja

    • Kontrol penuh

      Grup ketersediaan AlwaysOn memerlukan kontrol penuh, dan mengaktifkan grup ketersediaan AlwaysOn pada instans SQL Server memberinya kontrol penuh atas kluster (melalui SID Layanan).

      Anda tidak dapat langsung menambahkan atau menghapus keamanan untuk instans server di Manajer Kluster. Untuk mengelola sesi keamanan kluster, gunakan Pengelola Konfigurasi SQL Server atau WMI yang setara dari SQL Server.

  • Setiap instans SQL Server harus memiliki izin untuk mengakses registri, kluster, dan sebagainya.

  • Kami menyarankan agar Anda menggunakan enkripsi untuk koneksi antara instans server yang menghosting replika ketersediaan grup ketersediaan AlwaysOn.

Izin (Grup Ketersediaan)

Tugas Izin yang Diperlukan
Membuat grup ketersediaan Memerlukan keanggotaan dalam peran server tetap sysadmin dan izin membuat server GRUP KETERSEDIAAN, MENGUBAH izin GRUP KETERSEDIAAN APA PUN, atau izin SERVER KONTROL.
Mengubah grup ketersediaan Memerlukan izin UBAH GRUP KETERSEDIAAN pada grup ketersediaan, izin GRUP KETERSEDIAAN KONTROL, izin UBAH GRUP KETERSEDIAAN APA PUN, atau izin SERVER KONTROL.

Selain itu, bergabung dengan database ke grup ketersediaan memerlukan keanggotaan dalam peran database tetap db_owner .
Menghilangkan/menghapus grup ketersediaan Memerlukan izin UBAH GRUP KETERSEDIAAN pada grup ketersediaan, izin GRUP KETERSEDIAAN KONTROL, izin UBAH GRUP KETERSEDIAAN APA PUN, atau izin SERVER KONTROL. Untuk menghilangkan grup ketersediaan yang tidak dihosting di lokasi replika lokal, Anda memerlukan izin CONTROL SERVER atau izin CONTROL pada Grup Ketersediaan tersebut.

Tugas Terkait (Grup Ketersediaan)

Tugas Artikel
Membuat grup ketersediaan Menggunakan Grup Ketersediaan (Wizard Grup Ketersediaan Baru)

Membuat Grup Ketersediaan (SQL Bertransaksi)

Membuat Grup Ketersediaan (SQL Server PowerShell)

Tentukan URL Titik Akhir Saat Menambahkan atau Memodifikasi Replika Ketersediaan (SQL Server)
Mengubah jumlah replika ketersediaan Menambahkan Replika Sekunder ke Grup Ketersediaan (SQL Server)

Menggabungkan Replika Sekunder ke Grup Ketersediaan (SQL Server)

Menghapus Replika Sekunder dari Grup Ketersediaan (SQL Server)
Membuat listener grup ketersediaan Membuat atau Mengonfigurasi Listener Grup Ketersediaan (SQL Server)
Menghilangkan grup ketersediaan Menghapus Grup Ketersediaan (SQL Server)

Prasyarat dan Pembatasan Database Ketersediaan

Agar memenuhi syarat untuk ditambahkan ke grup ketersediaan, database harus memenuhi prasyarat dan batasan berikut.

Di bagian ini:

Daftar periksa: Persyaratan (Database Ketersediaan)

Agar memenuhi syarat untuk ditambahkan ke grup ketersediaan, database harus:

Persyaratan Tautan
Jadilah database pengguna. Database sistem tidak dapat termasuk dalam grup ketersediaan.
Berada di instans SQL Server tempat Anda membuat grup ketersediaan dan dapat diakses oleh instans server.
Jadilah database baca-tulis. Database baca-saja tidak dapat ditambahkan ke grup ketersediaan. sys.databases (is_read_only = 0)
Jadilah database multi-pengguna. sys.databases (user_access = 0)
Tidak menggunakan AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Gunakan model pemulihan penuh (juga dikenal sebagai, mode pemulihan penuh). sys.databases (recovery_model = 1)
Memiliki setidaknya satu cadangan database lengkap.

Catatan: Setelah mengatur database ke mode pemulihan penuh, pencadangan penuh diperlukan untuk memulai rantai log pemulihan penuh.		 Membuat Pencadangan Database Lengkap (SQL Server)
Bukan milik grup ketersediaan yang ada. sys.databases (group_database_id = NULL)
Tidak dikonfigurasi untuk pencerminan database. sys.database_mirroring (Jika database tidak berpartisipasi dalam pencerminan, semua kolom yang diawali dengan "mirroring_" adalah NULL.)
Sebelum menambahkan database yang menggunakan FILESTREAM ke grup ketersediaan, pastikan bahwa FILESTREAM diaktifkan pada setiap instans server yang menghosting atau akan menghosting replika ketersediaan untuk grup ketersediaan. Mengaktifkan dan Mengonfigurasi FILESTREAM
Sebelum menambahkan database mandiri ke grup ketersediaan, pastikan bahwa opsi server autentikasi database mandiri diatur ke 1 pada setiap instans server yang menghosting atau akan menghosting replika ketersediaan untuk grup ketersediaan. Opsi Konfigurasi Server autentikasi database yang terkandung

Opsi Konfigurasi Server (SQL Server)

Catatan

Grup ketersediaan AlwaysOn berfungsi dengan tingkat kompatibilitas database yang didukung.

Pembatasan (Database Ketersediaan)

  • Jika jalur file (termasuk huruf kandar) database sekunder berbeda dari jalur database utama yang sesuai, pembatasan berikut berlaku:

    • Wizard Grup Ketersediaan Baru/Tambahkan Database ke Wizard Grup Ketersediaan: Opsi Penuh tidak didukung (pada halamanPilih Halaman Sinkronisasi Data Awal ),

    • PULIHKAN DENGAN PEMINDAHAN: Untuk membuat database sekunder, file database harus DIPULIHKAN DENGAN MOVE pada setiap instans SQL Server yang menghosting replika sekunder.

    • Dampak pada operasi add-file: Operasi add-file yang lebih baru pada replika utama mungkin gagal pada database sekunder. Kegagalan ini dapat menyebabkan database sekunder ditangguhkan. Ini, pada gilirannya, menyebabkan replika sekunder memasuki status NOT SYNCHRONIZING.

      Catatan

      Untuk informasi tentang merespons operasi file iklan yang gagal, lihat Memecahkan Masalah Operasi Add-File yang Gagal (Grup Ketersediaan AlwaysOn).

  • Anda tidak dapat menjatuhkan database yang saat ini termasuk dalam grup ketersediaan.

Tindak Lanjut untuk Database yang Dilindungi TDE

Jika Anda menggunakan enkripsi data transparan (TDE), sertifikat atau kunci asimetris untuk membuat dan mendekripsi kunci lain harus sama pada setiap instans server yang menghosting replika ketersediaan untuk grup ketersediaan. Untuk informasi selengkapnya, lihat Memindahkan Database yang Dilindungi TDE ke SQL Server Lain.

Izin (Database Ketersediaan)

Memerlukan izin UBAH pada database.

Tugas Terkait (Database Ketersediaan)

Tugas Artikel
Menyiapkan database sekunder (secara manual) Menyiapkan Database Sekunder secara Manual untuk Grup Ketersediaan (SQL Server)
Menggabungkan database sekunder ke grup ketersediaan (secara manual) Menggabungkan Database Sekunder ke Grup Ketersediaan (SQL Server)
Memodifikasi jumlah database ketersediaan Menambahkan Database ke Grup Ketersediaan (SQL Server)

Menghapus Database Sekunder dari Grup Ketersediaan (SQL Server)

Menghapus Database Utama dari Grup Ketersediaan (SQL Server)

Isi Terkait

Lihat juga

Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Pengklusteran Failover dan Grup Ketersediaan AlwaysOn (SQL Server)
Konektivitas Klien AlwaysOn (SQL Server)