Prasyarat, batasan, dan rekomendasi untuk grup ketersediaan AlwaysOn

  • Artikel

Berlaku untuk:SQL Server

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 topik ini.

Perbaikan .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
Layanan Pelaporan Hotfix untuk .NET 3.5 SP1 menambahkan dukungan ke Klien SQL untuk fitur AlwaysOn dari read-intent, readonly, dan multisubnetfailover. Perbaikan perlu diinstal pada setiap server laporan Reporting Services. KB 2654347: Perbaikan 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 2019 atau versi yang lebih baru. SQL Server 2022: Persyaratan perangkat keras dan perangkat lunak
Pastikan bahwa setiap komputer adalah simpul dalam WSFC. Pengklusteran Failover Windows Server 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.

Apa itu grup ketersediaan AlwaysOn?.

Penting

Pastikan juga bahwa lingkungan Anda dikonfigurasi dengan benar untuk menyambungkan ke grup ketersediaan. Untuk informasi selengkapnya, lihat Dukungan konektivitas driver dan klien untuk grup ketersediaan.

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 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 HostRecordTTL 300

    Tip

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

Konten terkait (PowerShell)

Konten 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 mandiri atau instans kluster failover SQL Server (FCI).

Di bagian ini:

Daftar periksa: Prasyarat (instans server)

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

Pengklusteran Failover dan Grup Ketersediaan AlwaysOn (SQL Server)

Grup ketersediaan terdistribusi
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 di akun layanan SQL Server untuk nama jaringan virtual (VNN) pendengar grup ketersediaan. Jika SPN terdaftar di akun selain akun layanan SQL Server, autentikasi gagal.

Untuk menggunakan autentikasi Kerberos untuk komunikasi antara titik akhir grup ketersediaan (AG), daftarkan SPN secara manual untuk titik akhir pencerminan database yang digunakan oleh AG.

Penting: Jika Anda mengubah akun layanan SQL Server, administrator domain perlu mendaftarkan ulang SPN secara manual.		 Mendaftarkan Nama Perwakilan Layanan untuk koneksi Kerberos

Catatan:

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 instans kluster failover SQL Server (FCI) untuk menghosting replika ketersediaan, pastikan Anda memahami pembatasan FCI dan bahwa persyaratan FCI terpenuhi. Prasyarat dan Persyaratan tentang Menggunakan Instans Kluster Failover SQL Server (FCI) untuk Menghosting Replika Ketersediaan (nanti di artikel ini)
Setiap instans server harus menjalankan versi SQL Server yang sama untuk berpartisipasi dalam grup ketersediaan. Untuk informasi selengkapnya, lihat daftar edisi dan fitur yang didukung di akhir bagian ini.
Semua instans server yang menghosting replika ketersediaan untuk grup ketersediaan harus menggunakan pemeriksaan 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. Pada komputer tertentu, Anda dapat mengaktifkan instans server sebanyak mungkin untuk grup ketersediaan AlwaysOn seperti yang didukung penginstalan SQL Server Anda. Mengaktifkan atau menonaktifkan fitur grup ketersediaan AlwaysOn

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. 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, Gunakan Wizard Grup Ketersediaan (SQL Server Management Studio) (atau Tambahkan replika ke grup Ketersediaan AlwaysOn Anda menggunakan Wizard Grup Ketersediaan di SQL Server Management) 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 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 untuk pencerminan database.		 Titik Akhir Pencerminan Database (SQL Server)

Keamanan Transportasi - Pencerminan Database - Ketersediaan AlwaysOn
Jika ada database yang menggunakan FILESTREAM 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 ditambahkan ke grup ketersediaan, pastikan bahwa autentikasi database yang terkandung (opsi konfigurasi server) diatur ke 1 pada setiap instans server yang menghosting replika ketersediaan untuk grup ketersediaan. Opsi Konfigurasi Server autentikasi database yang terkandung

Opsi konfigurasi server (SQL Server)

Untuk daftar fitur yang didukung oleh edisi SQL Server di Windows, lihat:

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') minus 40.

  • Replika ketersediaan yang dihosting pada instans server tertentu berbagi kumpulan utas tunggal di SQL Server 2019 (15.x) dan versi sebelumnya.

    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 menganggur untuk sementara waktu, utas tersebut dirilis 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 sekitar 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 durasi operasi pencadangan.

  • SQL Server 2022 (16.x) memperkenalkan kumpulan utas pengulangan paralel, yang merupakan kumpulan utas tingkat instans yang dibagikan dengan semua database yang memiliki pekerjaan pengulangan. Dengan kumpulan ini, kumpulan utas yang sama dapat memproses rekaman log untuk database yang berbeda secara bersamaan (secara paralel). Di SQL Server 2019 (15.x) dan versi sebelumnya, jumlah utas yang tersedia untuk pengulangan dibatasi hingga 100.

  • SQL Server 2019 (15.x) memperkenalkan pengulangan paralel untuk database grup ketersediaan memori yang dioptimalkan. Di SQL Server 2016 (13.x) dan SQL Server 2017 (14.x), 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 IZIN GRANT Endpoint (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 (T-SQL)
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 menggunakan PowerShell
Mengaktifkan grup ketersediaan Mengaktifkan atau menonaktifkan fitur grup ketersediaan AlwaysOn

Konten terkait (instans server)

Rekomendasi konektivitas jaringan

Kami sangat menyarankan Agar Anda menggunakan tautan jaringan yang sama untuk komunikasi antara node WSFC dan komunikasi antara replika ketersediaan. Menggunakan tautan jaringan terpisah dapat menyebabkan perilaku tak terduga jika beberapa tautan gagal (bahkan 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 hingga tautan dipulihkan. Jika WSFC meminta failover otomatis saat replika sekunder tidak disinkronkan, failover otomatis tidak terjadi.

Dukungan konektivitas klien

Untuk informasi tentang dukungan grup ketersediaan AlwaysOn untuk konektivitas klien, lihat Dukungan konektivitas driver dan klien untuk grup ketersediaan.

Prasyarat dan pembatasan untuk menggunakan instans kluster failover SQL Server (FCI) untuk menghosting replika ketersediaan

Di bagian ini:

Pembatasan (FCI)

Catatan

Instans kluster failover (FCI) mendukung volume bersama (CSV) terkluster. 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, node WSFC yang mungkin 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 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 yang berada di 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 FCI yang menghosting grup ketersediaan ke simpul yang sudah menghosting replika grup ketersediaan yang sama dapat mengakibatkan hilangnya replika grup ketersediaan, mencegahnya dibawa secara 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 oleh 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. 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 instans kluster failover SQL Server (FCI) memiliki penyimpanan bersama yang diperlukan sesuai penginstalan instans kluster failover SQL Server standar.

Tugas terkait (FCI)

Tugas Artikel
Menginstal SQL Server FCI Membuat Instans Kluster Failover AlwaysOn Baru (Penyiapan)
Peningkatan di tempat SQL Server FCI Anda yang sudah ada Meningkatkan instans kluster failover
Mempertahankan SQL Server FCI anda yang sudah ada Menambahkan atau menghapus simpul dalam instans kluster failover (Penyiapan)

Konten terkait (FCI)

Prasyarat dan pembatasan grup ketersediaan

Di bagian ini:

Pembatasan (grup ketersediaan)

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

    Catatan

    Komputer virtual pada komputer fisik yang sama dapat masing-masing 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 pada 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 macet. 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 FCI dibagikan antara SQL Server dan Windows Server Failover Cluster (WSFC), dengan SQL Server menyimpan informasi status yang lebih rinci tentang instans daripada kluster yang peduli. Model manajemen adalah bahwa SQL Server harus mendorong transaksi, dan bertanggung jawab untuk menjaga tampilan kluster status tetap sinkron dengan tampilan status SQL Server. Jika status kluster diubah di luar SQL Server, status mungkin tidak sinkron antara WSFC dan SQL Server, yang mungkin menyebabkan perilaku yang tidak dapat diprediksi.

    Contohnya:

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

    • Jangan gunakan Manajer Kluster Failover untuk melakukan failover pada grup ketersediaan. Anda harus menggunakan Transact-SQL atau SQL Server Management Studio.

  • Jangan tambahkan sumber daya atau ubah dependensi yang terkait dengan peran grup ketersediaan. Kami tidak menyarankan menempatkan sumber daya tambahan apa pun (termasuk pengguna atau pihak ketiga) ke dalam peran grup ketersediaan atau mengubah dependensi peran karena perubahan ini dapat berdampak negatif pada performa failover.

Prasyarat (grup ketersediaan)

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

Prasyarat Deskripsi
Jika Anda berencana menggunakan instans kluster failover SQL Server (FCI) untuk menghosting replika ketersediaan, pastikan Anda memahami pembatasan FCI dan bahwa persyaratan FCI terpenuhi. Prasyarat dan pembatasan untuk menggunakan instans kluster failover SQL Server (FCI) untuk menghosting replika ketersediaan (sebelumnya dalam artikel ini)

Keamanan (grup ketersediaan)

  • Keamanan diwariskan dari WSFC. Pengklusteran failover Windows 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 Service SID).

      Anda tidak dapat langsung menambahkan atau menghapus keamanan untuk instans server di Cluster Manager. 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 BUAT server GRUP KETERSEDIAAN, UBAH 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 Wizard Grup Ketersediaan (SQL Server Management Studio)

Membuat grup ketersediaan AlwaysOn menggunakan Transact-SQL (T-SQL)

Membuat grup ketersediaan AlwaysOn menggunakan PowerShell

Tentukan URL Titik Akhir - Menambahkan atau Memodifikasi Replika Ketersediaan
Memodifikasi jumlah replika ketersediaan Menambahkan replika sekunder ke Grup Ketersediaan AlwaysOn

Menggabungkan replika sekunder pada grup ketersediaan AlwaysOn

Menghapus Replika Sekunder dari Grup Ketersediaan (SQL Server)
Membuat pendengar grup ketersediaan Mengonfigurasi listener bagi grup ketersediaan Always On
Menjatuhkan 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. sys.databases (recovery_model = 1)
Memiliki setidaknya satu cadangan database lengkap.

Catatan: Setelah mengatur database ke model pemulihan penuh, pencadangan penuh diperlukan untuk memulai rantai log pemulihan penuh.		 Membuat Pencadangan Database Lengkap
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 yang terkandung 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 Lengkap tidak didukung (pada halaman Pilih Sinkronisasi Data Awal (Panduan Grup Ketersediaan Selalu Aktif) ),

    • RESTORE WITH MOVE: 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 menghilangkan database yang saat ini termasuk dalam grup ketersediaan.

Menindaklanjuti 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 Server SQL Lain.

Izin (database ketersediaan)

Memerlukan izin UBAH pada database.

Tugas terkait (database ketersediaan)

Tugas Artikel
Menyiapkan database sekunder (secara manual) Menyiapkan database sekunder untuk grup ketersediaan AlwaysOn
Menggabungkan database sekunder ke grup ketersediaan (secara manual) Menggabungkan database sekunder ke grup ketersediaan AlwaysOn
Mengubah jumlah database ketersediaan Tambahkan Database ke Grup Ketersediaan Always On

Menghapus Database Sekunder dari Grup Ketersediaan (SQL Server)

Menghapus database utama dari grup ketersediaan AlwaysOn

Konten terkait