UBAH GRUP KETERSEDIAAN (Transact-SQL)

Artikel
04/13/2023

Berlaku untuk: SQL Server

Mengubah grup ketersediaan AlwaysOn yang ada di SQL Server. Sebagian besar argumen ALTER AVAILABILITY GROUP hanya didukung replika utama saat ini. Namun argumen JOIN, FAILOVER, dan FORCE_FAILOVER_ALLOW_DATA_LOSS hanya didukung pada replika sekunder.

Konvensi sintaks transact-SQL

Sintaks

  
ALTER AVAILABILITY GROUP group_name   
  {  
     SET ( <set_option_spec> )   
   | ADD DATABASE database_name   
   | REMOVE DATABASE database_name  
   | ADD REPLICA ON <add_replica_spec>   
   | MODIFY REPLICA ON <modify_replica_spec>  
   | REMOVE REPLICA ON <server_instance>  
   | JOIN  
   | JOIN AVAILABILITY GROUP ON <add_availability_group_spec> [ ,...2 ]  
   | MODIFY AVAILABILITY GROUP ON <modify_availability_group_spec> [ ,...2 ]  
   | GRANT CREATE ANY DATABASE  
   | DENY CREATE ANY DATABASE  
   | FAILOVER  
   | FORCE_FAILOVER_ALLOW_DATA_LOSS   
   | ADD LISTENER 'dns_name' ( <add_listener_option> )  
   | MODIFY LISTENER 'dns_name' ( <modify_listener_option> )  
   | RESTART LISTENER 'dns_name'  
   | REMOVE LISTENER 'dns_name'  
   | OFFLINE  
  }  
[ ; ]  
  
<set_option_spec> ::=   
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }  
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 }   
  | HEALTH_CHECK_TIMEOUT = milliseconds  
  | DB_FAILOVER  = { ON | OFF }   
  | DTC_SUPPORT  = { PER_DB | NONE }  
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | ROLE = SECONDARY
  
<server_instance> ::=   
 { 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }  
  
<add_replica_spec>::=  
  <server_instance> WITH  
    (  
       ENDPOINT_URL = 'TCP://system-address:port',  
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY },  
       FAILOVER_MODE = { AUTOMATIC | MANUAL }   
       [ , <add_replica_option> [ ,...n ] ]  
    )   
  
  <add_replica_option>::=  
       SEEDING_MODE = { AUTOMATIC | MANUAL }  
     | BACKUP_PRIORITY = n  
     | SECONDARY_ROLE ( {   
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]   
        [,] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]  
     } )  
     | PRIMARY_ROLE ( {   
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]   
        [,] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | NONE } ]  
        [,] [ READ_WRITE_ROUTING_URL = { ( '<server_instance>' ) ] 
     } )  
     | SESSION_TIMEOUT = integer
  
<modify_replica_spec>::=  
  <server_instance> WITH  
    (    
       ENDPOINT_URL = 'TCP://system-address:port'   
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }   
     | FAILOVER_MODE = { AUTOMATIC | MANUAL }   
     | SEEDING_MODE = { AUTOMATIC | MANUAL }   
     | BACKUP_PRIORITY = n  
     | SECONDARY_ROLE ( {   
          ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }   
        | READ_ONLY_ROUTING_URL = 'TCP://system-address:port'   
          } )  
     | PRIMARY_ROLE ( {   
          ALLOW_CONNECTIONS = { READ_WRITE | ALL }   
        | READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | NONE }   
          } )  
     | SESSION_TIMEOUT = seconds  
    )   
  
<add_availability_group_spec>::=  
 <ag_name> WITH  
    (  
       LISTENER_URL = 'TCP://system-address:port',  
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT },  
       FAILOVER_MODE = MANUAL,  
       SEEDING_MODE = { AUTOMATIC | MANUAL }  
    )  
  
<modify_availability_group_spec>::=  
 <ag_name> WITH  
    (  
       LISTENER = 'TCP://system-address:port'  
       | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }  
       | SEEDING_MODE = { AUTOMATIC | MANUAL }  
    )  
  
<add_listener_option> ::=  
   {  
      WITH DHCP [ ON ( <network_subnet_option> ) ]  
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]  
   }  
  
  <network_subnet_option> ::=  
     'ipv4_address', 'ipv4_mask'    
  
  <ip_address_option> ::=  
     {   
        'four_part_ipv4_address', 'four_part_ipv4_mask'  
      | 'ipv6_address'  
     }  
  
<modify_listener_option>::=  
    {  
       ADD IP ( <ip_address_option> )   
     | PORT = listener_port  
    }

Argumen

group_name
Menentukan nama grup ketersediaan baru. group_name harus merupakan pengidentifikasi SQL Server yang valid, dan harus unik di semua grup ketersediaan di kluster WSFC.

= AUTOMATED_BACKUP_PREFERENCE { PRIMER | SECONDARY_ONLY| SEKUNDER | TIDAK ADA }
Menentukan preferensi tentang bagaimana pekerjaan pencadangan harus mengevaluasi replika utama saat memilih tempat untuk melakukan pencadangan. Anda dapat membuat skrip pekerjaan pencadangan tertentu untuk memperhitungkan preferensi pencadangan otomatis. Penting untuk dipahami bahwa preferensi tidak diberlakukan oleh SQL Server, sehingga tidak berdampak pada cadangan ad hoc.

Hanya didukung pada replika utama.

Nilainya adalah sebagai berikut:

PRIMARY
Menentukan bahwa cadangan harus selalu terjadi pada replika utama. Opsi ini berguna jika Anda memerlukan fitur cadangan, seperti membuat cadangan diferensial, yang tidak didukung saat pencadangan dijalankan pada replika sekunder.

Penting

Jika Anda berencana menggunakan pengiriman log untuk menyiapkan database sekunder apa pun untuk grup ketersediaan, atur preferensi pencadangan otomatis ke Primer hingga semua database sekunder telah disiapkan dan bergabung ke grup ketersediaan.

SECONDARY_ONLY
Menentukan bahwa pencadangan tidak boleh dilakukan pada replika utama. Jika replika utama adalah satu-satunya replika online, pencadangan tidak boleh terjadi.

SECONDARY
Menentukan bahwa cadangan harus terjadi pada replika sekunder kecuali ketika replika utama adalah satu-satunya replika online. Dalam hal ini, pencadangan harus terjadi pada replika utama. Ini adalah perilaku default.

NONE
Menentukan bahwa Anda lebih suka pekerjaan cadangan mengabaikan peran replika ketersediaan saat memilih replika untuk melakukan pencadangan. Catatan pekerjaan pencadangan mungkin mengevaluasi faktor lain seperti prioritas cadangan dari setiap replika ketersediaan dalam kombinasi dengan status operasional dan status terhubung.

Penting

Tidak ada penegakan pengaturan AUTOMATED_BACKUP_PREFERENCE. Interpretasi preferensi ini tergantung pada logika, jika ada, yang Anda skrip ke dalam pekerjaan belakang untuk database dalam grup ketersediaan tertentu. Pengaturan preferensi pencadangan otomatis tidak berdampak pada pencadangan ad hoc. Untuk informasi selengkapnya, lihat Mengonfigurasi Pencadangan pada Replika Ketersediaan (SQL Server).

Catatan

Untuk melihat preferensi pencadangan otomatis dari grup ketersediaan yang ada, pilih kolom automated_backup_preference atau automated_backup_preference_desc tampilan katalog sys.availability_groups. Selain itu, sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) dapat digunakan untuk menentukan replika cadangan pilihan. Fungsi ini akan selalu mengembalikan 1 untuk setidaknya salah satu replika, bahkan ketika AUTOMATED_BACKUP_PREFERENCE = NONE.

= FAILURE_CONDITION_LEVEL { 1 | 2 | 3 | 4 | 5 }
Menentukan kondisi kegagalan apa yang akan memicu failover otomatis untuk grup ketersediaan ini. FAILURE_CONDITION_LEVEL diatur pada tingkat grup tetapi hanya relevan pada replika ketersediaan yang dikonfigurasi untuk mode ketersediaan penerapan sinkron (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Selain itu, kondisi kegagalan dapat memicu failover otomatis hanya jika replika primer dan sekunder dikonfigurasi untuk mode failover otomatis (FAILOVER_MODE = OTOMATIS) dan replika sekunder saat ini disinkronkan dengan replika utama.

Hanya didukung pada replika utama.

Tingkat kondisi kegagalan (1-5) berkisar dari tingkat paling tidak ketat, tingkat 1, hingga yang paling ketat, tingkat 5. Tingkat kondisi tertentu mencakup semua tingkat yang kurang ketat. Dengan demikian, tingkat kondisi paling ketat, 5, termasuk empat tingkat kondisi yang kurang ketat (1-4), tingkat 4 mencakup tingkat 1-3, dan sebagainya. Tabel berikut ini menjelaskan kondisi kegagalan yang sesuai dengan setiap tingkat.

Tingkat	Kondisi Kegagalan
1	Menentukan bahwa failover otomatis harus dimulai ketika salah satu hal berikut terjadi: Layanan SQL Server tidak berfungsi. Sewa grup ketersediaan untuk menyambungkan ke kluster WSFC kedaluwarsa karena tidak ada ACK yang diterima dari instans server. Untuk informasi selengkapnya, lihat Cara Kerjanya: Batas Waktu Sewa AlwaysOn SQL Server.
2	Menentukan bahwa failover otomatis harus dimulai ketika salah satu hal berikut terjadi: Instans SQL Server tidak tersambung ke kluster, dan ambang batas HEALTH_CHECK_TIMEOUT yang ditentukan pengguna dari grup ketersediaan terlampaui. Replika ketersediaan dalam status gagal.
3	Menentukan bahwa failover otomatis harus dimulai pada kesalahan internal SQL Server penting, seperti spinlock tanpa induk, pelanggaran akses tulis serius, atau terlalu banyak pembuangan. Ini adalah perilaku default.
4	Menentukan bahwa failover otomatis harus dimulai pada kesalahan internal SQL Server sedang, seperti kondisi kehabisan memori persisten di kumpulan sumber daya internal SQL Server.
5	Menentukan bahwa failover otomatis harus dimulai pada kondisi kegagalan yang memenuhi syarat, termasuk: Kelelahan utas pekerja Mesin SQL. Deteksi kebuntuan yang belum terkelola.

Catatan

Kurangnya respons oleh instans SQL Server terhadap permintaan klien tidak relevan dengan grup ketersediaan.

Nilai FAILURE_CONDITION_LEVEL dan HEALTH_CHECK_TIMEOUT, menentukan kebijakan failover yang fleksibel untuk grup tertentu. Kebijakan failover fleksibel ini memberi Anda kontrol terperinci atas kondisi apa yang harus menyebabkan failover otomatis. Untuk informasi selengkapnya, lihat Kebijakan Failover Fleksibel untuk Failover Otomatis Grup Ketersediaan (SQL Server).

= HEALTH_CHECK_TIMEOUT milidetik
Menentukan waktu tunggu (dalam milidetik) untuk prosedur tersimpan sistem sp_server_diagnostics untuk mengembalikan informasi kesehatan server sebelum kluster WSFC mengasumsikan bahwa instans server lambat atau tidak merespons. HEALTH_CHECK_TIMEOUT diatur pada tingkat grup tetapi hanya relevan pada replika ketersediaan yang dikonfigurasi untuk mode ketersediaan penerapan sinkron dengan failover otomatis (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Selain itu, batas waktu pemeriksaan kesehatan dapat memicu failover otomatis hanya jika replika utama dan sekunder dikonfigurasi untuk mode failover otomatis (FAILOVER_MODE = OTOMATIS) dan replika sekunder saat ini disinkronkan dengan replika utama.

Nilai HEALTH_CHECK_TIMEOUT default adalah 30000 milidetik (30 detik). Nilai minimum adalah 15000 milidetik (15 detik), dan nilai maksimumnya adalah 4294967295 milidetik.

Hanya didukung pada replika utama.

Penting

sp_server_diagnostics tidak melakukan pemeriksaan kesehatan di tingkat database.

= DB_FAILOVER { AKTIF | NONAKTIF }
Menentukan respons yang akan diambil ketika database pada replika utama offline. Saat diatur ke AKTIF, status apa pun selain ONLINE untuk database dalam grup ketersediaan memicu failover otomatis. Ketika opsi ini diatur ke NONAKTIF, hanya kesehatan instans yang digunakan untuk memicu failover otomatis.

Untuk informasi selengkapnya mengenai pengaturan ini, lihat Opsi Deteksi Kesehatan Tingkat Database

= DTC_SUPPORT { PER_DB | TIDAK ADA }
Menentukan apakah transaksi terdistribusi diaktifkan untuk Grup Ketersediaan ini. Transaksi terdistribusi hanya didukung untuk database grup ketersediaan yang dimulai di SQL Server 2016 (13.x), dan transaksi lintas database hanya didukung mulai dari SQL Server 2016 (13.x) SP2. PER_DB membuat grup ketersediaan dengan dukungan untuk transaksi ini dan akan secara otomatis mempromosikan transaksi lintas database yang melibatkan database dalam Grup Ketersediaan ke dalam transaksi terdistribusi. NONE mencegah promosi otomatis transaksi lintas database ke transaksi terdistribusi dan tidak mendaftarkan database dengan RMID yang stabil di DTC. Transaksi terdistribusi tidak dicegah saat NONE pengaturan digunakan, tetapi failover database dan pemulihan otomatis mungkin tidak berhasil dalam beberapa keadaan. Untuk informasi selengkapnya, lihat Transaksi Lintas Database dan Transaksi Terdistribusi untuk Grup Ketersediaan AlwaysOn dan Pencerminan Database (SQL Server).

Catatan

Dukungan untuk mengubah pengaturan DTC_SUPPORT Grup Ketersediaan diperkenalkan di Paket Layanan SQL Server 2016 (13.x) 2. Opsi ini tidak dapat digunakan dengan versi yang lebih lama. Untuk mengubah pengaturan ini di versi SQL Server yang lebih lama, Anda harus DROP dan MEMBUAT grup ketersediaan lagi.

Penting

DTC memiliki batas 32 pendaftaran per transaksi terdistribusi. Karena setiap database dalam grup ketersediaan mendaftar dengan DTC secara terpisah, jika transaksi Anda melibatkan lebih dari 32 database, Anda mungkin mendapatkan kesalahan berikut saat SQL Server mencoba mendaftarkan database ke-33:

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

Untuk detail selengkapnya tentang transaksi terdistribusi di SQL Server, lihat Transaksi terdistribusi

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Diperkenalkan di SQL Server 2017 (14.x). Menetapkan jumlah minimum replika sekunder sinkron yang diperlukan untuk diterapkan sebelum replika utama melakukan transaksi. Menjamin bahwa transaksi SQL Server menunggu hingga log transaksi diperbarui pada jumlah minimum replika sekunder.

Default: 0. Menyediakan perilaku yang sama seperti SQL Server 2016 (13.x).
Minimum: 0.
Maksimum: Jumlah replika dikurangi 1.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT berkaitan dengan replika dalam mode penerapan sinkron. Ketika replika berada dalam mode penerapan sinkron, penulisan pada replika utama menunggu hingga menulis pada replika sinkron yang diterapkan ke log transaksi database replika. Jika SQL Server yang menghosting replika sinkron sekunder berhenti merespons, SQL Server yang menghosting replika utama menandai replika sekunder tersebut sebagai TIDAK DISINKRONKAN dan melanjutkan. Ketika database yang tidak responsif kembali online, database akan berada dalam status "tidak disinkronkan" dan replika ditandai sebagai tidak sehat sampai primer dapat menyinkronkannya lagi. Pengaturan ini menjamin bahwa replika utama tidak dilanjutkan hingga jumlah minimum replika telah melakukan setiap transaksi. Jika jumlah minimum replika tidak tersedia, maka penerapan pada primer gagal. Untuk jenis EXTERNAL kluster, pengaturan diubah saat grup ketersediaan ditambahkan ke sumber daya kluster. Lihat Ketersediaan tinggi dan perlindungan data untuk konfigurasi grup ketersediaan.

Dimulai dengan SQL Server 2022 (16.x), Anda dapat mengatur REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT pada grup ketersediaan terdistribusi. Pengaturan ini tidak didukung untuk CREATE AVAILABILITY GROUP. Anda dapat menggunakan ALTER AVAILABILITY GROUP untuk mengatur REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Contohnya:

ALTER AVAILABILITY GROUP [<name>] 
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = <integer>);

PERAN
Satu-satunya parameter yang valid adalah 'SEKUNDER', dan opsi SET ini hanya valid di Grup Ketersediaan Terdistribusi. Ini digunakan untuk melakukan failover pada grup ketersediaan terdistribusi seperti yang didokumenkan di sini: UBAH GRUP KETERSEDIAAN

MENAMBAHKAN database_name DATABASE
Menentukan daftar satu atau beberapa database pengguna yang ingin Anda tambahkan ke grup ketersediaan. Database ini harus berada di instans SQL Server yang menghosting replika utama saat ini. Anda dapat menentukan beberapa database untuk grup ketersediaan, tetapi setiap database hanya bisa termasuk dalam satu grup ketersediaan. Untuk informasi tentang jenis database yang dapat didukung grup ketersediaan, lihat Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server). Untuk mengetahui database lokal mana yang sudah termasuk dalam grup ketersediaan, lihat kolom replica_id dalam tampilan katalog sys.databases .

Hanya didukung pada replika utama.

Catatan

Setelah Anda membuat grup ketersediaan, Anda harus terhubung ke setiap instans server yang menghosting replika sekunder dan kemudian menyiapkan setiap database sekunder dan menggabungkannya ke grup ketersediaan. Untuk informasi selengkapnya, lihat Memulai Pergerakan Data pada Database Sekunder Always On (SQL Server).

MENGHAPUS database_name DATABASE
Menghapus database utama yang ditentukan dan database sekunder yang sesuai dari grup ketersediaan. Hanya didukung pada replika utama.

Untuk informasi tentang tindak lanjut yang direkomendasikan setelah menghapus database ketersediaan dari grup ketersediaan, lihat Menghapus Database Utama dari Grup Ketersediaan (SQL Server).

TAMBAHKAN REPLIKA AKTIF
Menentukan dari satu hingga delapan instans SQL Server untuk menghosting replika sekunder dalam grup ketersediaan. Setiap replika ditentukan oleh alamat instans servernya diikuti dengan klausa WITH (...).

Hanya didukung pada replika utama.

Anda perlu menggabungkan setiap replika sekunder baru ke grup ketersediaan. Untuk informasi selengkapnya, lihat deskripsi opsi JOIN, nanti di bagian ini.

<server_instance>
Menentukan alamat instans SQL Server yang merupakan host untuk replika. Format alamat tergantung pada apakah instans adalah instans default atau instans bernama dan apakah itu adalah instans mandiri atau instans kluster failover (FCI). Sintaksisnya adalah sebagai berikut:

{ 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

Komponen alamat ini adalah sebagai berikut:

system_name
Adalah nama NetBIOS dari sistem komputer tempat instans target SQL Server berada. Komputer ini harus merupakan simpul WSFC.

FCI_network_name
Adalah nama jaringan yang digunakan untuk mengakses kluster failover SQL Server. Gunakan ini jika instans server berpartisipasi sebagai mitra failover SQL Server. Menjalankan SELECT @@SERVERNAME pada instans server FCI mengembalikan seluruh string 'FCI_network_name[\instance_name]' (yang merupakan nama replika lengkap).

instance_name
Adalah nama instans SQL Server yang dihosting oleh system_name atau FCI_network_name dan yang mengaktifkan Always On. Untuk instans server default, instance_name bersifat opsional. Nama instans tidak peka huruf besar/kecil. Pada instans server yang berdiri sendiri, nama nilai ini sama dengan nilai yang dikembalikan dengan menjalankan SELECT @@SERVERNAME.

\
Adalah pemisah yang hanya digunakan saat menentukan instance_name, untuk memisahkannya dari system_name atau FCI_network_name.

Untuk informasi tentang prasyarat untuk simpul WSFC dan instans server, lihat Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server).

ENDPOINT_URL ='TCP:// system-address:port'
Menentukan jalur URL untuk titik akhir pencerminan database pada instans SQL Server yang akan menghosting replika ketersediaan yang Anda tambahkan atau ubah.

ENDPOINT_URL diperlukan dalam klausul ADD REPLICA ON dan opsional dalam klausa UBAH REPLIKA ON. Untuk informasi selengkapnya, lihat Menentukan URL Titik Akhir Saat Menambahkan atau Memodifikasi Replika Ketersediaan (SQL Server).

'TCP://system-address:port'
Menentukan URL untuk menentukan URL titik akhir atau URL perutean baca-saja. Parameter URL adalah sebagai berikut:

alamat sistem
Adalah string, seperti nama sistem, nama domain yang sepenuhnya memenuhi syarat, atau alamat IP, yang secara tidak ambigu mengidentifikasi sistem komputer tujuan.

pelabuhan
Adalah nomor port yang terkait dengan titik akhir pencerminan instans server (untuk opsi ENDPOINT_URL) atau nomor port yang digunakan oleh Mesin Database instans server (untuk opsi READ_ONLY_ROUTING_URL).

= AVAILABILITY_MODE { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }
Menentukan apakah replika utama harus menunggu replika sekunder untuk mengakui pengerasan (penulisan) rekaman log ke disk sebelum replika utama dapat melakukan transaksi pada database utama tertentu. Transaksi pada database yang berbeda pada replika utama yang sama dapat diterapkan secara independen.

SYNCHRONOUS_COMMIT
Menentukan bahwa replika utama akan menunggu untuk melakukan transaksi hingga diperkeras pada replika sekunder ini (mode penerapan sinkron). Anda dapat menentukan SYNCHRONOUS_COMMIT hingga tiga replika, termasuk replika utama.

ASYNCHRONOUS_COMMIT
Menentukan bahwa replika utama melakukan transaksi tanpa menunggu replika sekunder ini untuk mengeraskan log (mode ketersediaan penerapan sinkron). Anda dapat menentukan ASYNCHRONOUS_COMMIT hingga lima replika ketersediaan, termasuk replika utama.

CONFIGURATION_ONLY Menentukan bahwa replika utama secara sinkron menerapkan metadata konfigurasi grup ketersediaan ke database master pada replika ini. Replika tidak akan berisi data pengguna. Opsi ini:

Dapat dihosting di SQL Server edisi apa pun, termasuk Edisi Ekspres.
Mengharuskan titik akhir pencerminan data dari replika CONFIGURATION_ONLY menjadi jenis WITNESS.
Tidak dapat diubah.
Tidak valid ketika CLUSTER_TYPE = WSFC.

Untuk informasi selengkapnya, lihat Replika konfigurasi saja.

AVAILABILITY_MODE diperlukan dalam klausul ADD REPLICA ON dan opsional dalam klausa UBAH REPLIKA ON. Untuk informasi selengkapnya, lihat Mode Ketersediaan (Grup Ketersediaan AlwaysOn).

= FAILOVER_MODE { OTOMATIS | MANUAL }
Menentukan mode failover replika ketersediaan yang Anda tentukan.

OTOMATIS
Mengaktifkan failover otomatis. OTOMATIS hanya didukung jika Anda juga menentukan AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Anda dapat menentukan OTOMATIS untuk tiga replika ketersediaan, termasuk replika utama.

Catatan

Sebelum SQL Server 2016, Anda dibatasi pada dua replika failover otomatis, termasuk replika utama

Catatan

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.

MANUAL
Mengaktifkan failover manual atau failover manual paksa (failover paksa) oleh administrator database.

FAILOVER_MODE diperlukan dalam klausul ADD REPLICA ON dan opsional dalam klausa UBAH REPLIKA ON. Ada dua jenis failover manual, failover manual tanpa kehilangan data dan failover paksa (dengan kemungkinan kehilangan data), yang didukung dalam kondisi yang berbeda. Untuk informasi selengkapnya, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

= SEEDING_MODE { OTOMATIS | MANUAL }
Menentukan bagaimana replika sekunder awalnya akan disemai.

OTOMATIS
Mengaktifkan seeding langsung. Metode ini akan menyemai replika sekunder melalui jaringan. Metode ini tidak mengharuskan Anda untuk mencadangkan dan memulihkan salinan database utama pada replika.

Catatan

Untuk seeding langsung, Anda harus mengizinkan pembuatan database pada setiap replika sekunder dengan memanggil ALTER AVAILABILITY GROUP dengan opsi GRANT CREATE ANY DATABASE .

MANUAL
Menentukan seeding manual (default). Metode ini mengharuskan Anda membuat cadangan database pada replika utama dan memulihkan cadangan tersebut secara manual pada replika sekunder.

=BACKUP_PRIORITY n
Menentukan prioritas Anda untuk melakukan pencadangan pada replika ini relatif terhadap replika lain dalam grup ketersediaan yang sama. Nilainya adalah bilangan bulat dalam rentang 0,.100. Nilai-nilai ini memiliki arti berikut:

1..100 menunjukkan bahwa replika ketersediaan dapat dipilih untuk melakukan pencadangan. 1 menunjukkan prioritas terendah, dan 100 menunjukkan prioritas tertinggi. Jika BACKUP_PRIORITY = 1, replika ketersediaan akan dipilih untuk melakukan pencadangan hanya jika tidak ada replika ketersediaan prioritas yang lebih tinggi yang saat ini tersedia.
0 menunjukkan bahwa replika ketersediaan ini tidak akan pernah dipilih untuk melakukan pencadangan. Ini berguna, misalnya, untuk replika ketersediaan jarak jauh tempat Anda tidak pernah ingin pencadangan gagal.

Untuk informasi selengkapnya, lihat Sekunder Aktif: Pencadangan pada Replika Sekunder (Grup Ketersediaan AlwaysOn).

SECONDARY_ROLE ( ... )
Menentukan pengaturan khusus peran yang akan berlaku jika replika ketersediaan ini saat ini memiliki peran sekunder (yaitu, setiap kali itu adalah replika sekunder). Dalam tanda kurung, tentukan salah satu atau kedua opsi peran sekunder. Jika Anda menentukan keduanya, gunakan daftar yang dipisahkan koma.

Opsi peran sekunder adalah sebagai berikut:

= ALLOW_CONNECTIONS { NO | READ_ONLY | SEMUA }
Menentukan apakah database replika ketersediaan tertentu yang melakukan peran sekunder (yaitu, bertindak sebagai replika sekunder) dapat menerima koneksi dari klien, salah satu dari:

TIDAK
Tidak ada koneksi pengguna yang diizinkan ke database sekunder dari replika ini. Mereka tidak tersedia untuk akses baca. Ini adalah perilaku default.

READ_ONLY
Hanya koneksi yang diizinkan ke database di replika sekunder tempat properti Niat Aplikasi diatur ke ReadOnly. Untuk informasi selengkapnya tentang properti ini, lihat Menggunakan Kata Kunci String Koneksi dengan SQL Server Native Client.

SEMUA
Semua koneksi diizinkan ke database di replika sekunder untuk akses baca-saja.

Untuk informasi selengkapnya, lihat Sekunder Aktif: Replika Sekunder yang Dapat Dibaca (Grup Ketersediaan AlwaysOn).

READ_ONLY_ROUTING_URL ='TCP://system-address:port'
Menentukan URL yang akan digunakan untuk merutekan permintaan koneksi baca-niat ke replika ketersediaan ini. Ini adalah URL yang didengarkan mesin database SQL Server. Biasanya, instans default Mesin Database SQL Server mendengarkan port TCP 1433.

Untuk instans bernama, Anda bisa mendapatkan nomor port dengan mengkueri port dan type_desc kolom tampilan manajemen dinamis sys.dm_tcp_listener_states . Instans server menggunakan pendengar Transact-SQL (type_desc='TSQL').

Untuk informasi selengkapnya tentang menghitung URL perutean baca-saja untuk replika ketersediaan, lihat Menghitung read_only_routing_url untuk AlwaysOn.

Catatan

Untuk instans SQL Server bernama, pendengar Transact-SQL harus dikonfigurasi untuk menggunakan port tertentu. Untuk informasi selengkapnya, lihat Mengonfigurasi Server untuk Mendengarkan Port TCP Tertentu (Pengelola Konfigurasi SQL Server).

PRIMARY_ROLE ( ... )
Menentukan pengaturan khusus peran yang akan berlaku jika replika ketersediaan ini saat ini memiliki peran utama (yaitu, setiap kali itu adalah replika utama). Dalam tanda kurung, tentukan salah satu atau kedua opsi peran utama. Jika Anda menentukan keduanya, gunakan daftar yang dipisahkan koma.

Opsi peran utama adalah sebagai berikut:

= ALLOW_CONNECTIONS { READ_WRITE | SEMUA }
Menentukan jenis koneksi yang dapat diterima database dari replika ketersediaan tertentu yang melakukan peran utama (yaitu, bertindak sebagai replika utama) yang dapat diterima dari klien, salah satu dari:

BACA_TULIS
Koneksi tempat properti koneksi Niat Aplikasi diatur ke ReadOnly tidak diizinkan. Ketika properti Niat Aplikasi diatur ke ReadWrite atau properti koneksi Niat Aplikasi tidak diatur, koneksi diizinkan. Untuk informasi selengkapnya tentang properti koneksi Niat Aplikasi, lihat Menggunakan Kata Kunci String Koneksi dengan Klien Asli SQL Server.

SEMUA
Semua koneksi diizinkan ke database di replika utama. Ini adalah perilaku default.

= READ_ONLY_ROUTING_LIST { ('<server_instance>' [ ,...n ] ) | TIDAK ADA }
Menentukan daftar instans server yang dipisahkan koma yang menghosting replika ketersediaan untuk grup ketersediaan ini yang memenuhi persyaratan berikut saat berjalan di bawah peran sekunder:

Dikonfigurasi untuk mengizinkan semua koneksi atau koneksi baca-saja (lihat argumen ALLOW_CONNECTIONS dari opsi SECONDARY_ROLE, di atas).
Tentukan URL perutean baca-saja (lihat argumen READ_ONLY_ROUTING_URL opsi SECONDARY_ROLE, di atas).

Nilai READ_ONLY_ROUTING_LIST adalah sebagai berikut:

<server_instance>
Menentukan alamat instans SQL Server yang merupakan host untuk replika ketersediaan yang merupakan replika sekunder yang dapat dibaca saat berjalan di bawah peran sekunder.

Gunakan daftar yang dipisahkan koma untuk menentukan semua instans server yang mungkin menghosting replika sekunder yang dapat dibaca. Perutean baca-saja akan mengikuti urutan di mana instans server ditentukan dalam daftar. Jika Anda menyertakan instans server host replika pada daftar perutean baca-saja replika, menempatkan instans server ini di akhir daftar biasanya merupakan praktik yang baik, sehingga koneksi niat baca masuk ke replika sekunder, jika tersedia.

Dimulai dengan SQL Server 2016 (13.x), Anda dapat menyeimbangkan beban permintaan baca-niat di seluruh replika sekunder yang dapat dibaca. Anda menentukan ini dengan menempatkan replika dalam sekumpulan tanda kurung berlapis dalam daftar perutean baca-saja. Untuk informasi dan contoh selengkapnya, lihat Mengonfigurasi penyeimbangan beban di seluruh replika baca-saja.

NONE
Menentukan bahwa ketika replika ketersediaan ini adalah replika utama, perutean baca-saja tidak akan didukung. Ini adalah perilaku default. Saat digunakan dengan MODIFIKASI REPLICA ON, nilai ini menonaktifkan daftar yang ada, jika ada.

= READ_WRITE_ROUTING_URL { ('<server_instance>') }
Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2019 (15.x))

Menentukan instans server yang menghosting replika ketersediaan untuk grup ketersediaan ini yang memenuhi persyaratan berikut saat berjalan di bawah peran utama:

Spesifikasi replika PRIMARY_ROLE mencakup READ_WRITE_ROUTING_URL.
string koneksi adalah ReadWrite baik dengan menentukan ApplicationIntent sebagai ReadWrite atau dengan tidak mengatur ApplicationIntent dan membiarkan default (ReadWrite) berlaku.

Untuk informasi selengkapnya, lihat Pengalihan koneksi baca/tulis replika sekunder ke primer (Grup Ketersediaan AlwaysOn).

=SESSION_TIMEOUT detik
Menentukan periode batas waktu sesi dalam detik. Jika Anda tidak menentukan opsi ini, secara default, periode waktunya adalah 10 detik. Nilai minimum adalah 5 detik.

Penting

Kami menyarankan agar Anda menjaga periode waktu habis pada 10 detik atau lebih besar.

Untuk informasi selengkapnya tentang periode batas waktu sesi, lihat Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server).

UBAH REPLIKA AKTIF
Memodifikasi salah satu replika grup ketersediaan. Daftar replika yang akan dimodifikasi berisi alamat instans server dan klausa WITH (...) untuk setiap replika.

Hanya didukung pada replika utama.

HAPUS REPLIKA AKTIF
Menghapus replika sekunder yang ditentukan dari grup ketersediaan. Replika utama saat ini tidak dapat dihapus dari grup ketersediaan. Saat dihapus, replika berhenti menerima data. Database sekundernya dihapus dari grup ketersediaan dan memasuki status PEMULIHAN.

Hanya didukung pada replika utama.

Catatan

Jika Anda menghapus replika saat tidak tersedia atau gagal, ketika kembali online, replika akan menemukan bahwa replika tersebut tidak lagi termasuk dalam grup ketersediaan.

IKUTI
Menyebabkan instans server lokal menghosting replika sekunder dalam grup ketersediaan yang ditentukan.

Hanya didukung pada replika sekunder yang belum bergabung ke grup ketersediaan.

Untuk informasi selengkapnya, lihat Menggabungkan Replika Sekunder ke Grup Ketersediaan (SQL Server).

FAILOVER
Memulai failover manual grup ketersediaan tanpa kehilangan data ke replika sekunder tempat Anda terhubung. Replika yang akan menghosting replika utama adalah target failover. Target failover akan mengambil alih peran utama dan memulihkan salinannya dari setiap database dan membuatnya online sebagai database utama baru. Replika utama sebelumnya secara bersamaan beralih ke peran sekunder, dan databasenya menjadi database sekunder dan segera ditangguhkan. Berpotensi, peran ini dapat dialihkan bolak-balik oleh serangkaian kegagalan.

Hanya didukung pada replika sekunder penerapan sinkron yang saat ini disinkronkan dengan replika utama. Perhatikan bahwa agar replika sekunder disinkronkan, replika utama juga harus berjalan dalam mode penerapan sinkron.

Catatan

Perintah failover kembali segera setelah target failover menerima perintah. Namun, pemulihan database terjadi secara asinkron setelah grup ketersediaan selesai gagal.

Untuk informasi tentang batasan, prasyarat, dan rekomendasi untuk melakukan failover manual yang direncanakan, lihat Melakukan Failover Manual terencana dari Grup Ketersediaan (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Perhatian

Memaksa failover, yang mungkin melibatkan beberapa kehilangan data, benar-benar merupakan metode pemulihan bencana. Oleh karena itu, Kami sangat menyarankan Agar Anda memaksa failover hanya jika replika utama tidak lagi berjalan, Anda bersedia mengambil risiko kehilangan data, dan Anda harus segera memulihkan layanan ke grup ketersediaan.

Hanya didukung pada replika yang perannya berada dalam status SEKUNDER atau PENYELESAIAN. --Replika tempat Anda memasukkan perintah failover dikenal sebagai target failover.

Memaksa failover grup ketersediaan, dengan kemungkinan kehilangan data, ke target failover. Target failover akan mengambil alih peran utama dan memulihkan salinannya dari setiap database dan membuatnya online sebagai database utama baru. Pada replika sekunder yang tersisa, setiap database sekunder ditangguhkan hingga dilanjutkan secara manual. Ketika replika utama sebelumnya tersedia, replika tersebut akan beralih ke peran sekunder, dan databasenya akan menjadi database sekunder yang ditangguhkan.

Catatan

Perintah failover kembali segera setelah target failover menerima perintah. Namun, pemulihan database terjadi secara asinkron setelah grup ketersediaan selesai gagal.

Untuk informasi tentang batasan, prasyarat, dan rekomendasi untuk memaksa failover dan efek failover paksa pada database utama sebelumnya dalam grup ketersediaan, lihat Melakukan Failover Manual Paksa dari Grup Ketersediaan (SQL Server).

TAMBAHKAN LISTENER 'dns_name'(<add_listener_option)>
Menentukan pendengar grup ketersediaan baru untuk grup ketersediaan ini. Hanya didukung pada replika utama.

Penting

Sebelum Anda membuat pendengar pertama Anda, kami sangat menyarankan Anda membaca Membuat atau Mengonfigurasi Listener Grup Ketersediaan (SQL Server).

Setelah Anda membuat pendengar untuk grup ketersediaan tertentu, kami sangat menyarankan Anda melakukan hal berikut:

Minta administrator jaringan Anda untuk memesan alamat IP pendengar untuk penggunaan eksklusifnya.
Berikan nama host DNS pendengar kepada pengembang aplikasi untuk digunakan dalam string koneksi saat meminta koneksi klien ke grup ketersediaan ini.

dns_name
Menentukan nama host DNS pendengar grup ketersediaan. Nama DNS pendengar harus unik di domain dan di NetBIOS.

dns_name adalah nilai string. Nama ini hanya dapat berisi karakter alfanumerik, tanda hubung (-), dan tanda hubung (_), dalam urutan apa pun. Nama host DNS tidak peka huruf besar/kecil. Panjang maksimum adalah 63 karakter.

Kami menyarankan agar Anda menentukan string yang bermakna. Misalnya, untuk grup ketersediaan bernama AG1, nama host DNS yang bermakna adalah ag1-listener.

Penting

NetBIOS hanya mengenali 15 karakter pertama dalam dns_name. Jika Anda memiliki dua kluster WSFC yang dikontrol oleh Direktori Aktif yang sama dan Anda mencoba membuat pendengar grup ketersediaan di kedua kluster menggunakan nama dengan lebih dari 15 karakter dan awalan karakter 15 yang identik, Anda akan mendapatkan pelaporan kesalahan bahwa sumber daya Nama Jaringan Virtual tidak dapat dibawa online. Untuk informasi tentang aturan penamaan awalan untuk nama DNS, lihat Menetapkan Nama Domain.

BERGABUNG DENGAN GRUP KETERSEDIAAN AKTIF
Bergabung ke grup ketersediaan terdistribusi. Saat Anda membuat grup ketersediaan terdistribusi, grup ketersediaan pada kluster tempat grup tersebut dibuat adalah grup ketersediaan utama. Grup ketersediaan yang bergabung dengan grup ketersediaan terdistribusi adalah grup ketersediaan sekunder.

<ag_name>
Menentukan nama grup ketersediaan yang membentuk setengah dari grup ketersediaan terdistribusi.

LISTENER ='TCP://system-address:port'
Menentukan jalur URL untuk pendengar yang terkait dengan grup ketersediaan.

Klausa LISTENER diperlukan.

'TCP://system-address:port'
Menentukan URL untuk pendengar yang terkait dengan grup ketersediaan. Parameter URL adalah sebagai berikut:

alamat sistem
Adalah string, seperti nama sistem, nama domain yang sepenuhnya memenuhi syarat, atau alamat IP, yang secara tidak ambigu mengidentifikasi pendengar.

pelabuhan
Adalah nomor port yang terkait dengan titik akhir pencerminan grup ketersediaan. Perhatikan bahwa ini bukan port pendengar.

= AVAILABILITY_MODE { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
Menentukan apakah replika utama harus menunggu grup ketersediaan sekunder untuk mengakui penguatan (penulisan) rekaman log ke disk sebelum replika utama dapat melakukan transaksi pada database utama tertentu.

SYNCHRONOUS_COMMIT
Menentukan bahwa replika utama akan menunggu untuk melakukan transaksi hingga diperkeras pada grup ketersediaan sekunder. Anda dapat menentukan SYNCHRONOUS_COMMIT hingga dua grup ketersediaan, termasuk grup ketersediaan utama.

ASYNCHRONOUS_COMMIT
Menentukan bahwa replika utama melakukan transaksi tanpa menunggu grup ketersediaan sekunder ini mengeraskan log. Anda dapat menentukan ASYNCHRONOUS_COMMIT hingga dua grup ketersediaan, termasuk grup ketersediaan utama.

Klausa AVAILABILITY_MODE diperlukan.

= FAILOVER_MODE { MANUAL }
Menentukan mode failover dari grup ketersediaan terdistribusi.

MANUAL
Mengaktifkan failover manual yang direncanakan atau failover manual paksa (biasanya disebut failover paksa) oleh administrator database.

Failover otomatis ke grup ketersediaan sekunder tidak didukung.

SEEDING_MODE**=** { AUTOMATIC | MANUAL }
Menentukan bagaimana grup ketersediaan sekunder awalnya akan disemai.

OTOMATIS
Mengaktifkan seeding otomatis. Metode ini akan menyemai grup ketersediaan sekunder melalui jaringan. Metode ini tidak mengharuskan Anda untuk mencadangkan dan memulihkan salinan database utama pada replika grup ketersediaan sekunder.

MANUAL
Menentukan seeding manual. Metode ini mengharuskan Anda membuat cadangan database pada replika utama dan memulihkan cadangan tersebut secara manual pada replika grup ketersediaan sekunder.

UBAH GRUP KETERSEDIAAN AKTIF
Memodifikasi salah satu pengaturan grup ketersediaan grup ketersediaan terdistribusi. Daftar grup ketersediaan yang akan dimodifikasi berisi nama grup ketersediaan dan klausa WITH (...) untuk setiap grup ketersediaan.

Penting

Perintah ini harus diulang pada grup ketersediaan utama dan instans grup ketersediaan sekunder.

MEMBERIKAN BUAT DATABASE APA PUN
Mengizinkan grup ketersediaan untuk membuat database atas nama replika utama, yang mendukung seeding langsung (SEEDING_MODE = AUTOMATIC). Parameter ini harus dijalankan pada setiap replika sekunder yang mendukung seeding langsung setelah sekunder tersebut bergabung dengan grup ketersediaan. Memerlukan izin CREATE ANY DATABASE.

TOLAK BUAT DATABASE APA PUN
Menghapus kemampuan grup ketersediaan untuk membuat database atas nama replika utama.

<add_listener_option>
ADD LISTENER mengambil salah satu opsi berikut:

WITH DHCP [ ON { ('four_part_ipv4_address','four_part_ipv4_mask') } ]
Menentukan bahwa pendengar grup ketersediaan akan menggunakan Dynamic Host Configuration Protocol (DHCP). Secara opsional, gunakan klausul ON untuk mengidentifikasi jaringan tempat pendengar ini akan dibuat. DHCP terbatas pada satu subnet yang digunakan untuk setiap instans server yang menghosting replika ketersediaan dalam grup ketersediaan.

Penting

Kami tidak merekomendasikan DHCP di lingkungan produksi. Jika ada waktu henti dan sewa IP DHCP kedaluwarsa, waktu tambahan diperlukan untuk mendaftarkan alamat IP jaringan DHCP baru yang terkait dengan nama DNS pendengar dan berdampak pada konektivitas klien. Namun, DHCP baik untuk menyiapkan lingkungan pengembangan dan pengujian Anda untuk memverifikasi fungsi dasar grup ketersediaan dan untuk integrasi dengan aplikasi Anda.

Contohnya:

WITH DHCP ON ('10.120.19.0','255.255.254.0')

DENGAN IP ( { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') } [ , ...n ] ) [ , PORT =listener_port ]
Menentukan bahwa, alih-alih menggunakan DHCP, pendengar grup ketersediaan akan menggunakan satu atau beberapa alamat IP statis. Untuk membuat grup ketersediaan di beberapa subnet, setiap subnet memerlukan satu alamat IP statis dalam konfigurasi pendengar. Untuk subnet tertentu, alamat IP statis dapat berupa alamat IPv4 atau alamat IPv6. Hubungi administrator jaringan Anda untuk mendapatkan alamat IP statis untuk setiap subnet yang akan menghosting replika ketersediaan untuk grup ketersediaan baru.

Contohnya:

WITH IP ( ('10.120.19.155','255.255.254.0') )

ipv4_address
Menentukan alamat empat bagian IPv4 untuk pendengar grup ketersediaan. Contohnya,10.120.19.155.

ipv4_mask
Menentukan masker empat bagian IPv4 untuk pendengar grup ketersediaan. Contohnya,255.255.254.0.

ipv6_address
Menentukan alamat IPv6 untuk pendengar grup ketersediaan. Contohnya,2001::4898:23:1002:20f:1fff:feff:b3a3.

PORT = listener_port
Menentukan nomor port-listener_port-untuk digunakan oleh pendengar grup ketersediaan yang ditentukan oleh klausul WITH IP. PORT bersifat opsional.

Nomor port default, 1433, didukung. Namun, jika Anda memiliki masalah keamanan, sebaiknya gunakan nomor port yang berbeda.

Misalnya: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

UBAH LISTENER 'dns_name'(<modify_listener_option)>
Memodifikasi pendengar grup ketersediaan yang ada untuk grup ketersediaan ini. Hanya didukung pada replika utama.

<modify_listener_option>
UBAH LISTENER mengambil salah satu opsi berikut:

TAMBAHKAN IP { ('four_part_ipv4_address','four_part_ipv4_mask') | ('dns_nameipv6_address') }
Menambahkan alamat IP yang ditentukan ke pendengar grup ketersediaan yang ditentukan oleh dns_name.

PORT = listener_port
Lihat deskripsi argumen ini sebelumnya di bagian ini.

MULAI ULANG LISTENER 'dns_name'
Memulai ulang pendengar yang terkait dengan nama DNS yang ditentukan. Hanya didukung pada replika utama.

HAPUS LISTENER 'dns_name'
Menghapus pendengar yang terkait dengan nama DNS yang ditentukan. Hanya didukung pada replika utama.

LURING
Membuat grup ketersediaan online offline. Tidak ada kehilangan data untuk database penerapan sinkron.

Setelah grup ketersediaan offline, databasenya menjadi tidak tersedia untuk klien, dan Anda tidak dapat membuat grup ketersediaan kembali online. Oleh karena itu, gunakan opsi OFFLINE hanya selama migrasi lintas kluster grup ketersediaan AlwaysOn, saat memigrasikan sumber daya grup ketersediaan ke kluster WSFC baru.

Untuk informasi selengkapnya, lihat Mengambil Grup Ketersediaan Offline (SQL Server).

Prasyarat dan Pembatasan

Untuk informasi tentang prasyarat dan pembatasan replika ketersediaan dan pada instans server host dan komputer mereka, lihat Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server).

Untuk informasi tentang pembatasan pada pernyataan AVAILABILITY GROUP Transact-SQL, lihat Gambaran Umum Pernyataan Transact-SQL untuk Grup Ketersediaan AlwaysOn (SQL Server).

Keamanan

Izin

Memerlukan izin UBAH GRUP KETERSEDIAAN pada grup ketersediaan, izin GRUP KETERSEDIAAN KONTROL, izin UBAH GRUP KETERSEDIAAN APA PUN, atau izin SERVER KONTROL. Juga memerlukan izin UBAH DATABASE APA PUN.

Contoh

J. Menggabungkan replika sekunder ke grup ketersediaan

Contoh berikut menggabungkan replika sekunder tempat Anda terhubung ke AccountsAG grup ketersediaan.

ALTER AVAILABILITY GROUP AccountsAG JOIN;  
GO

B. Memaksa failover grup ketersediaan

Contoh berikut memaksa AccountsAG grup ketersediaan untuk melakukan failover ke replika sekunder tempat Anda terhubung.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
GO

Lihat Juga

BUAT GRUP KETERSEDIAAN (Transact-SQL)
ALTER DATABASE SET HADR (Transact-SQL)
DROP AVAILABILITY GROUP (Transact-SQL)
sys.availability_replicas (T-SQL)
sys.availability_groups (Transact-SQL)
Memecahkan Masalah Konfigurasi Grup Ketersediaan AlwaysOn (SQL Server)
Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Listener Grup Ketersediaan, Konektivitas Klien, dan Kegagalan Aplikasi (SQL Server)

Bagikan melalui

UBAH GRUP KETERSEDIAAN (Transact-SQL)

Sintaks

Argumen

Prasyarat dan Pembatasan

Keamanan

Izin

Contoh

J. Menggabungkan replika sekunder ke grup ketersediaan

B. Memaksa failover grup ketersediaan

Lihat Juga

Saran dan Komentar

Sumber Daya Tambahan: