Sekarang Grup Ketersediaan menjadi lebih luas, saya pikir saya akan membahas topik yang mungkin diabaikan selama perencanaan awal dan instalasi SQL Server di lingkungan jenis ini. Untuk benar-benar memiliki konfigurasi yang toleran terhadap kesalahan, beberapa pemikiran dan perencanaan harus masuk ke dalam penyiapan konektivitas database.
Saya tidak akan membahas detail pengaturan lingkungan AlwaysOn Anda di pos ini, tetapi untuk bantuan tambahan, saya sarankan Anda melihat pos Aaron Bertrand, "Pemecahan Masalah AlwaysOn – Terkadang dibutuhkan banyak mata." Setelah lingkungan Anda dikonfigurasi, langkah selanjutnya dalam menyediakan konektivitas database adalah membuat Availability Group Listener menggunakan SQL Management Studio atau T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
String Koneksi Pendengar AG
Nama Jaringan Virtual (VNN) Anda terdaftar di DNS dan selalu dimiliki oleh contoh SQL Server tempat replika utama berada. Semua alamat IP yang diberikan saat mengonfigurasi AG Listener terdaftar di DNS dengan nama jaringan virtual yang sama.
Setelah Anda membuat AG Listener, Anda harus memastikan klien Anda dapat terhubung. Koneksi aplikasi Anda beroperasi dengan cara yang sama seperti biasanya, namun, alih-alih mengarah ke server tertentu di string koneksi, Anda mengarah ke AG Listener.
Pendengar AG hanya dapat dihubungkan untuk menggunakan TCP, dan diselesaikan oleh DNS lokal Anda ke daftar alamat IP dan port TCP yang dipetakan ke VNN. Klien Anda akan mencoba menyambung ke masing-masing alamat IP secara bergantian hingga mendapat koneksi atau hingga mencapai batas waktu koneksi. Parameter string koneksi penting yang perlu dipertimbangkan untuk digunakan adalah MultiSubnetFailover. Jika parameter ini disetel ke true, klien akan mencoba koneksi secara paralel yang memungkinkan konektivitas yang lebih cepat dan jika perlu, failover klien yang lebih cepat:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Saat terjadi failover, koneksi klien direset, dan kepemilikan AG Listener berpindah ke contoh SQL Server yang mengambil alih peran replika utama. Titik akhir VNN kemudian terikat ke alamat IP baru dan port TCP dari instans replika utama baru. Bergantung pada klien, koneksi ulang otomatis ke AG akan terjadi, atau pengguna mungkin harus memulai ulang aplikasi atau koneksi yang terpengaruh secara manual.
Tujuan Aplikasi
Salah satu alasan terbesar untuk menerapkan Grup Ketersediaan adalah untuk menyediakan kemampuan untuk memanfaatkan lingkungan cadangan atau pemulihan bencana Anda untuk memindahkan pekerjaan dari lingkungan produksi Anda. Server-server ini sekarang dapat digunakan untuk pencadangan, analisis, kueri dan pelaporan ad-hoc, atau operasi lain yang cukup memiliki salinan database hanya-baca.
Untuk memberikan akses baca-saja ke replika sekunder Anda, parameter string koneksi ApplicationIntent digunakan. Daftar perutean baca-saja opsional dari titik akhir SQL Server dapat dikonfigurasi pada setiap replika. Daftar ini digunakan untuk mengalihkan permintaan koneksi klien yang menggunakan parameter ApplicationIntent=ReadOnly ke replika sekunder pertama yang tersedia yang telah dikonfigurasi dengan filter maksud aplikasi yang sesuai.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Pemfilteran Maksud Aplikasi
Untuk memfasilitasi Maksud Aplikasi dari klien yang terhubung ke Grup Ketersediaan Anda, setiap instans SQL Server dalam grup harus dikonfigurasi dengan Filter Maksud Aplikasi yang sesuai. Filter menentukan jenis koneksi mana yang akan diterima setiap replika.
Replika utama yang dikonfigurasi untuk memiliki Koneksi dalam Peran Utama "Izinkan semua koneksi" akan menerima koneksi apa pun yang dibuat melalui AG Listener. Replika utama yang dikonfigurasi sebagai “Izinkan koneksi baca/tulis” akan menolak koneksi apa pun yang menetapkan “ApplicationIntent=ReadOnly.”
Saat mengonfigurasi replika, Anda juga harus menentukan apakah masing-masing replika akan menjadi Sekunder yang Dapat Dibaca atau tidak. Replika yang dikonfigurasi sebagai "Tidak" akan menolak semua koneksi. Replika ini diasumsikan hanya digunakan untuk failover dalam situasi pemulihan bencana. Jika replika sekunder dikonfigurasi sebagai "Ya", semua koneksi akan diizinkan, tetapi hanya untuk akses baca, bahkan jika "ApplicationIntent=ReadOnly" tidak ditentukan. Terakhir, jika sekunder dikonfigurasi sebagai “Hanya baca maksud”, hanya klien yang menentukan “ApplicationIntent=ReadOnly” yang akan diizinkan untuk terhubung.
Perutean Hanya-Baca
Sekarang setelah kita mengetahui cara mengonfigurasi Application Intent pada instance server, dan membuat string koneksi yang diperlukan, kita harus mengonfigurasi perutean hanya-baca Grup Ketersediaan. Saat Anda terhubung ke AG Listener menggunakan string koneksi seperti yang ditentukan di atas, listener akan menanyakan instance replika utama dan menentukan apakah koneksi harus dibuat ke primer (baca/tulis) atau ke sekunder hanya-baca. Untuk mencapai ini, daftar perutean harus dibuat untuk SETIAP replika ketersediaan yang digunakan jika dan ketika replika mengambil peran utama. Biasanya, praktik terbaik adalah menyertakan setiap URL perutean hanya-baca untuk setiap replika sekunder hanya-baca dengan URL replika lokal di akhir daftar. Permintaan koneksi read-intent dirutekan ke sekunder pertama yang dapat dibaca yang tersedia pada daftar perutean, tidak ada penyeimbangan beban antara sekunder.
Pertama, ubah setiap replika untuk menyediakan URL perutean hanya-baca:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
Kedua, ubah setiap replika untuk menyediakan daftar perutean hanya-baca yang akan digunakan saat replika yang diberikan dalam peran utama:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); URL perutean harus dalam bentuk “TCP://:”. Untuk bantuan dalam menentukan URL Anda, lihat blog dan skrip ini yang dibuat oleh Matt Neerincx.
Kesimpulan
Dengan perutean hanya-baca Anda yang dikonfigurasi, AG Listener dibuat, dan aplikasi klien Anda menggunakan string koneksi yang benar, Anda harus memiliki koneksi yang sepenuhnya toleran terhadap kesalahan untuk Availability Group Anda. Pastikan Anda meluangkan waktu untuk menguji konektivitas Anda, dan kemampuan aplikasi Anda untuk mengikuti server Anda saat gagal.
