Jenis koneksi klien ke replika dalam grup ketersediaan AlwaysOn

Berlaku untuk:SQL Server

Dalam grup ketersediaan Always On, Anda dapat mengonfigurasi satu atau beberapa replika ketersediaan untuk mengizinkan koneksi baca-saja saat beroperasi dalam peran sekunder (yaitu, saat beroperasi sebagai replika sekunder). Anda juga dapat mengonfigurasi setiap replika ketersediaan untuk mengizinkan atau mengecualikan koneksi baca-saja saat beroperasi dalam peran utama (yaitu, saat beroperasi sebagai replika utama).

Untuk memfasilitasi akses klien ke database utama atau sekunder dari grup ketersediaan tertentu, Anda harus menentukan pendengar grup ketersediaan. Secara bawaan, listener grup ketersediaan mengarahkan koneksi masuk ke replika utama. Namun, Anda dapat mengonfigurasi grup ketersediaan agar mendukung perutean khusus baca-saja, yang memungkinkan listener grup ketersediaan mengalihkan permintaan koneksi dari aplikasi dengan niat baca ke replika sekunder yang dapat dibaca. Untuk informasi selengkapnya, lihat Mengonfigurasi Perutean Baca-Saja untuk Grup Ketersediaan (SQL Server).

Selama failover, replika sekunder beralih ke peran utama dan replika utama sebelumnya beralih ke peran sekunder. Selama proses failover, semua koneksi klien ke replika utama dan replika sekunder dihentikan. Setelah failover, saat klien terhubung kembali ke listener grup ketersediaan, listener menghubungkan kembali klien ke replika utama yang baru, kecuali untuk permintaan koneksi read-intent. Jika perutean baca-saja dikonfigurasi pada klien dan pada instans server yang menghosting replika utama baru dan setidaknya pada satu replika sekunder yang dapat dibaca, permintaan koneksi baca-niat dirutekan kembali ke replika sekunder yang mendukung jenis akses koneksi yang diperlukan klien. Untuk memastikan pengalaman klien tetap lancar setelah terjadi failover, penting untuk mengonfigurasi akses koneksi untuk peran sekunder maupun primer dari setiap replika ketersediaan.

Catatan

Untuk informasi tentang listener grup ketersediaan, yang menangani permintaan koneksi klien, lihat Listener Grup Ketersediaan, Konektivitas Klien, dan Pengalihan Otomatis Aplikasi (SQL Server).

Jenis Akses Koneksi yang Didukung oleh Peran Sekunder

Peran sekunder mendukung tiga alternatif untuk koneksi klien, sebagai berikut:

Tidak ada koneksi
Tidak ada koneksi pengguna yang diizinkan. Database sekunder tidak tersedia untuk akses baca. Ini adalah perilaku default dalam peran sekunder.

Hanya koneksi baca-niat
Database sekunder hanya tersedia untuk koneksi yang properti koneksi Application Intent-nya diatur ke ReadOnly (koneksi dengan tujuan baca).

Untuk informasi tentang properti koneksi ini, lihat Dukungan SQL Server Native Client untuk Ketersediaan Tinggi dan Pemulihan Bencana.

Perbolehkan koneksi baca-saja
Semua database sekunder tersedia untuk koneksi akses baca. Opsi ini memungkinkan klien versi yang lebih rendah untuk terhubung.

Untuk informasi selengkapnya, lihat Mengonfigurasi Akses Baca-Saja pada Replika Ketersediaan (SQL Server).

Jenis Akses Koneksi yang Didukung oleh Peran Utama

Peran utama mendukung dua alternatif untuk koneksi klien, sebagai berikut:

Semua koneksi diperbolehkan
Baik koneksi baca-tulis maupun baca-saja diizinkan untuk terhubung ke database utama. Ini adalah perilaku default untuk peran utama.

Perbolehkan hanya koneksi baca-tulis
Saat properti koneksi Application Intent diatur ke ReadWrite atau tidak diatur, koneksi tersebut diizinkan. Koneksi yang kata kunci string koneksi Application Intent-nya ditetapkan ke ReadOnly tidak diizinkan. Hanya mengizinkan koneksi baca-tulis dapat membantu mencegah pelanggan Anda menghubungkan beban kerja yang ditujukan untuk baca ke replika utama secara tidak sengaja.

Untuk informasi tentang properti koneksi ini, lihat Menggunakan Kata Kunci String Koneksi dengan SQL Server Native Client.

Untuk informasi selengkapnya, lihat Mengonfigurasi Akses Baca-Saja pada Replika Ketersediaan (SQL Server).

Bagaimana Konfigurasi Akses Koneksi Memengaruhi Konektivitas Klien

Pengaturan akses koneksi replika menentukan apakah upaya koneksi gagal atau berhasil. Tabel berikut ini meringkas apakah upaya koneksi tertentu berhasil atau gagal untuk setiap pengaturan akses koneksi.

Peran Replika Akses koneksi didukung pada replika Maksud Koneksi Hasil Upaya Koneksi
Sekunder Semua Niat baca, baca-tulis, atau tidak ada niat koneksi yang ditentukan Berhasil
Sekunder Tidak ada (Ini adalah perilaku sekunder default.) Niat baca, baca-tulis, atau tidak ada niat koneksi yang ditentukan Kegagalan
Sekunder Hanya niat baca Maksud membaca Berhasil
Sekunder Hanya niat baca Baca-tulis atau tidak ada tujuan koneksi yang ditentukan Kegagalan
Primer Semua (Ini adalah perilaku utama default.) Baca-saja, baca-tulis, atau tidak ada niat koneksi yang ditentukan Berhasil
Primer Baca-tulis Hanya niat baca Kegagalan
Primer Baca-tulis Baca/tulis atau tidak ada maksud koneksi yang ditentukan Berhasil

Untuk informasi tentang mengonfigurasi grup ketersediaan untuk menerima koneksi klien ke replikanya, lihat Listener Grup Ketersediaan, Konektivitas Klien, dan Failover Aplikasi (SQL Server).

Contoh Konfigurasi Akses Koneksi

Bergantung pada bagaimana replika ketersediaan yang berbeda dikonfigurasi untuk akses koneksi, dukungan terhadap koneksi klien mungkin berubah setelah terjadi failover pada grup ketersediaan. Misalnya, pertimbangkan grup ketersediaan yang pelaporan dilakukan pada replika sekunder komit asinkron jarak jauh. Semua aplikasi yang hanya-baca untuk database dalam grup ketersediaan ini menetapkan properti koneksi Application Intent ke ReadOnly, sehingga semua koneksi yang hanya-baca merupakan koneksi dengan maksud baca.

Contoh grup ketersediaan ini memiliki dua replika dengan commit sinkron di pusat komputasi utama dan dua replika dengan commit asinkron di lokasi satelit. Untuk peran utama, semua replika dikonfigurasi untuk akses baca-tulis, yang mencegah koneksi baca-niat ke replika utama dalam semua situasi. Peran sekunder penerapan sinkron menggunakan konfigurasi akses koneksi default ("tidak ada"), yang mencegah semua koneksi klien di bawah peran sekunder. Sebaliknya, replika komit asinkron dikonfigurasi untuk mengizinkan koneksi dengan maksud baca saat berperan sebagai sekunder. Tabel berikut ini meringkas contoh konfigurasi ini:

Replika Mode Penerapan Peran Awal Akses Koneksi untuk Peran Sekunder Akses Koneksi untuk Peran Utama
Replika1 Sinkron Primer Tidak Baca-tulis
Replika2 Sinkron Sekunder Tidak Baca-tulis
Replika3 Asinkron Sekunder Baca-niat saja Baca-tulis
Replika4 Asinkron Sekunder Hanya niat baca Baca-tulis

Biasanya, dalam skenario contoh ini, failover hanya terjadi di antara replika komit sinkron, dan segera setelah failover, aplikasi yang ditujukan untuk operasi baca dapat tersambung kembali ke salah satu replika sekunder komit asinkron. Namun, ketika bencana terjadi di pusat komputasi utama, kedua replika dengan komit sinkron akan hilang. Administrator basis data di situs satelit merespons dengan melakukan failover manual secara paksa ke replika sekunder dengan mode penerapan asinkron. Database sekunder pada replika sekunder yang tersisa ditangguhkan akibat failover paksa, sehingga tidak tersedia untuk beban kerja baca-saja. Replika utama baru, yang dikonfigurasi untuk koneksi baca-tulis, mencegah beban kerja baca-niat bersaing dengan beban kerja baca-tulis. Ini berarti bahwa hingga administrator database mengaktifkan kembali database sekunder pada replika sekunder dengan penerapan asinkron yang tersisa, klien read-intent tidak dapat terhubung ke replika ketersediaan mana pun.

Tugas Terkait

Konten terkait

  • Last updated on