Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server)

Berlaku untuk:SQL Server

Untuk menyambungkan ke sesi pencerminan database, klien dapat menggunakan SQL Server Native Client atau Penyedia Data .NET Framework untuk SQL Server. Saat dikonfigurasi untuk database SQL Server, penyedia akses data ini mendukung pencerminan database sepenuhnya. Untuk informasi tentang pertimbangan pemrograman untuk menggunakan database cermin, lihat Menggunakan Pencerminan Database. Selain itu, instans server utama saat ini harus tersedia dan login klien harus dibuat pada instans server. Untuk informasi selengkapnya, lihat Memecahkan Masalah Pengguna Tanpa Injil (SQL Server). Koneksi klien ke sesi pencerminan database tidak melibatkan instans server saksi, jika ada.

Membuat Koneksi Awal ke Sesi Pencerminan Database

Untuk koneksi awal ke database cermin, klien harus menyediakan string koneksi yang secara minimal memasok nama instans server. Nama server yang diperlukan ini harus mengidentifikasi instans server utama saat ini dan dikenal sebagai nama mitra awal.

Secara opsional, string koneksi juga dapat memberikan nama instans server lain, yang harus mengidentifikasi instans server cermin saat ini, untuk digunakan jika mitra awal tidak tersedia selama upaya koneksi pertama. Nama kedua dikenal sebagai nama mitra failover.

string koneksi juga harus menyediakan nama database. Ini diperlukan untuk mengaktifkan upaya failover oleh penyedia akses data.

Saat menerima string koneksi, penyedia akses data menyimpan nama mitra awal dan nama mitra failover, jika disediakan, dalam cache dalam memori volatil klien (untuk kode terkelola, cache dicakup ke domain aplikasi). Setelah di-cache, nama mitra awal tidak pernah diperbarui oleh penyedia akses data. Ketika klien memberikan nama mitra failover, penyedia akses data juga menyimpan nama mitra failover ini untuk sementara jika penyedia tidak dapat terhubung menggunakan nama mitra awal.

Sesi pencerminan database tidak melindungi dari masalah akses server yang khusus untuk klien, seperti ketika komputer klien mengalami masalah berkomunikasi dengan jaringan. Upaya koneksi ke database cermin juga dapat gagal karena berbagai alasan yang tidak terkait dengan penyedia akses data; misalnya, upaya koneksi dapat gagal karena instans server utama tidak aktif, seperti yang terjadi ketika database gagal, atau karena kesalahan jaringan.

Saat mencoba menyambungkan, penyedia akses data dimulai dengan menggunakan nama mitra awal. Jika instans server yang ditentukan tersedia dan merupakan instans server utama saat ini, upaya koneksi biasanya berhasil.

Catatan

Jika sesi pencerminan dijeda, klien biasanya terhubung ke server utama dan mengunduh nama mitra. Namun, database tidak tersedia untuk klien sampai pencerminan dilanjutkan.

Jika upaya tersebut tidak berhasil, penyedia akses data mencoba nama mitra failover, jika tersedia. Jika salah satu nama mitra mengidentifikasi server utama saat ini dengan benar, penyedia akses data biasanya berhasil membuka koneksi awal. Saat menyelesaikan koneksi ini, penyedia akses data mengunduh nama instans server dari server cermin saat ini. Nama ini disimpan dalam cache sebagai nama mitra failover, menimpa nama mitra failover yang disediakan klien, jika ada. Setelah itu, Penyedia Data .NET Framework untuk SQL Server tidak memperbarui nama mitra failover. Sebaliknya, SQL Server Native Client memperbarui cache setiap kali koneksi berikutnya atau reset koneksi mengembalikan nama mitra yang berbeda.

Gambar berikut mengilustrasikan koneksi klien ke mitra awal, Partner_A, untuk database cermin bernama Db_1. Angka ini menunjukkan kasus di mana nama mitra awal yang disediakan oleh klien mengidentifikasi server utama saat ini dengan benar, Partner_A. Upaya koneksi awal berhasil, dan penyedia akses data menyimpan nama server cermin (saat ini Partner_B) sebagai nama mitra failover di cache lokal. Terakhir, klien terhubung ke salinan utama database Db_1 .

Upaya koneksi awal mungkin gagal, misalnya, karena kesalahan jaringan atau instans server yang tidak aktif. Karena mitra awal tidak tersedia, bagi penyedia akses data untuk mencoba terhubung ke mitra failover, klien harus telah memberikan nama mitra failover di string koneksi.

Dalam hal ini, jika nama mitra failover tidak tersedia, upaya koneksi asli berlanjut hingga batas waktu koneksi jaringan atau kesalahan dikembalikan (sama seperti untuk database yang tidak dicerminkan).

Ketika nama mitra failover disediakan dalam string koneksi, perilaku penyedia akses data tergantung pada protokol jaringan dan sistem operasi klien, sebagai berikut:

• Untuk TCP/IP, upaya koneksi diatur oleh algoritma coba lagi koneksi yang khusus untuk pencerminan database. Algoritma coba lagi koneksi menentukan waktu maksimum (waktu coba lagi) yang dialokasikan untuk membuka koneksi dalam upaya koneksi tertentu.

• Untuk protokol jaringan lainnya

  Jika terjadi kesalahan atau jika mitra awal tidak tersedia, upaya koneksi awal menunggu hingga periode batas waktu koneksi jaringan kedaluwarsa atau periode batas waktu masuk kedaluwarsa pada penyedia akses data. Biasanya, penantian ini berada pada urutan 20 hingga 30 detik. Setelah itu, jika penyedia akses data belum kehabisan waktu, penyedia akses data mencoba terhubung ke mitra failover. Jika periode batas waktu koneksi kedaluwarsa sebelum koneksi berhasil atau mitra failover tidak tersedia, upaya koneksi gagal. Jika mitra failover tersedia dalam periode batas waktu masuk dan sekarang menjadi server utama, upaya koneksi biasanya berhasil.

String Koneksi ion untuk Database Cermin

string koneksi yang disediakan oleh klien berisi informasi yang digunakan penyedia akses data untuk menyambungkan ke database. Bagian ini membahas kata kunci yang secara khusus relevan untuk menyambungkan ke database cermin menggunakan Koneksi Driver ODBC Klien Asli SQL Server.

Atribut Jaringan

string koneksi harus berisi atribut Jaringan untuk menentukan protokol jaringan. Ini memastikan bahwa protokol jaringan yang ditentukan tetap ada di antara koneksi ke mitra yang berbeda. Protokol terbaik untuk menyambungkan ke database cermin adalah TCP/IP. Untuk memastikan bahwa klien meminta TCP/IP untuk setiap koneksi ke mitra, string koneksi menyediakan atribut berikut:

Network=dbmssocn;   

Penting

Sebaiknya simpan TCP/IP di bagian atas daftar protokol klien. Namun, jika string koneksi menentukan atribut Jaringan, ini akan mengambil alih urutan daftar.

Atau, untuk memastikan bahwa permintaan klien bernama pipa untuk setiap koneksi ke mitra, string koneksi menyediakan atribut berikut:

Network=dbnmpntw;   

Penting

Karena pipa bernama tidak menggunakan algoritma coba lagi TCP/IP, dalam banyak kasus, upaya koneksi pipa bernama mungkin kehabisan waktu sebelum menyambungkan ke database cermin.

Atribut Server

string koneksi harus berisi atribut Server yang menyediakan nama mitra awal, yang harus mengidentifikasi instans server utama saat ini.

Cara paling sederhana untuk mengidentifikasi instans server adalah dengan menentukan namanya , <server_name>[\<SQL_Server_instance_name>]. Misalnya:

Server=Partner_A;

or

Server=Partner_A\Instance_2;

Namun, ketika nama sistem digunakan, klien harus melakukan pencarian DNS untuk mendapatkan alamat IP server dan kueri Browser SQL Server untuk mendapatkan nomor port server tempat mitra berada. Pencarian dan kueri tersebut dapat dilewati dengan menentukan alamat IP dan nomor port mitra di atribut Server , daripada menentukan nama server. Ini disarankan untuk meminimalkan kemungkinan penundaan eksternal saat terhubung ke mitra tersebut.

Catatan

Kueri Browser SQL Server diperlukan jika string koneksi menentukan nama instans bernama dan bukan port.

Untuk menentukan alamat IP dan port, atribut Server mengambil formulir berikut, Server=<ip_address<,>port>, misalnya:

Server=123.34.45.56,4724;   

Catatan

Alamat IP dapat berupa IP Versi 4 (IPv4) atau IP Versi 6 (IPv6).

Atribut Database

Selain itu, string koneksi harus menentukan atribut Database untuk menyediakan nama database yang dicerminkan. Jika database tidak tersedia saat klien mencoba menyambungkan, pengecualian akan dinaikkan.

Misalnya, untuk secara tegas terhubung ke database AdventureWorks di server utama Partner_A, klien menggunakan string koneksi berikut:

" Server=Partner_A; Database=AdventureWorks "

Catatan

String ini menghilangkan informasi autentikasi.

Penting

Menggabungkan awalan protokol dengan atribut Server (<Server=tcp:nama> server) tidak kompatibel dengan atribut Jaringan, dan menentukan protokol di kedua tempat kemungkinan akan mengakibatkan kesalahan. Oleh karena itu, kami menyarankan agar string koneksi menentukan protokol menggunakan atribut Jaringan dan hanya menentukan nama server di atribut Server ("Network=dbmssocn; Server=<nama>" server).

Atribut Mitra Failover

Selain nama mitra awal, klien juga dapat menentukan nama mitra failover, yang harus mengidentifikasi instans server cermin saat ini. Mitra failover ditentukan oleh salah satu kata kunci untuk atribut mitra failover. Kata kunci untuk atribut ini tergantung pada API yang Anda gunakan. Tabel berikut mencantumkan kata kunci ini:

API	Kata kunci untuk atribut mitra failover
Penyedia OLE DB	FailoverPartner
ODBC Driver	Failover_Partner
Objek Data ActiveX (ADO)	Mitra Failover

Cara paling sederhana untuk mengidentifikasi instans server adalah dengan nama sistemnya, <server_name>[\<SQL_Server_instance_name>].

Atau, alamat IP dan nomor port dapat disediakan di atribut Mitra Failover. Jika upaya koneksi awal gagal selama koneksi pertama ke database, upaya untuk terhubung ke mitra failover akan dibebaskan dari mengandalkan DNS dan Browser SQL Server. Setelah koneksi dibuat, nama mitra failover akan ditimpa dengan nama mitra failover, jadi jika kegagalan terjadi, koneksi yang dialihkan akan memerlukan DNS dan Browser SQL Server.

Catatan

Ketika hanya nama mitra awal yang disediakan, pengembang aplikasi tidak perlu mengambil tindakan apa pun atau menulis kode apa pun kecuali tentang cara menyambungkan kembali.

Catatan

Pengembang aplikasi kode terkelola menyediakan nama mitra failover di Koneksi ionString objek Sql Koneksi ion. Untuk informasi tentang menggunakan string koneksi ini, lihat "Dukungan Pencerminan Database di Penyedia Data .NET Framework untuk SQL Server" dalam dokumentasi ADO.NET, yang merupakan bagian dari Microsoft .NET Framework SDK.

Contoh String Koneksi ion

Misalnya, untuk secara eksplisit terhubung menggunakan TCP/IP ke database AdventureWorks baik di Partner_A atau Partner_B, aplikasi klien yang menggunakan Driver ODBC dapat menyediakan string koneksi berikut:

"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Atau, klien dapat menggunakan alamat IP dan nomor port untuk mengidentifikasi mitra awal, Partner_A; misalnya, jika alamat IP adalah 250.65.43.21 dan nomor port adalah 4734, string koneksi adalah:

"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Algoritma Coba Lagi Koneksi ion (untuk Koneksi TCP/IP)

Untuk koneksi TCP/IP, ketika kedua nama mitra berada di cache, penyedia akses data mematuhi algoritma coba lagi koneksi. Ini berlaku baik untuk membuat koneksi awal ke sesi dan untuk menyambungkan kembali setelah kehilangan koneksi yang dibuat. Setelah koneksi dibuka, menyelesaikan langkah-langkah pra-masuk dan masuk membutuhkan waktu tambahan.

Catatan

Waktu yang dihabiskan dalam membuka koneksi dapat melebihi waktu coba lagi karena faktor eksternal, seperti pencarian DNS lambat, pengontrol domain lambat/Pusat Distribusi Kunci Kerberos (KDC), waktu yang dihabiskan untuk menghubungi Browser SQL Server, kemacetan jaringan, dan sebagainya. Faktor eksternal tersebut dapat mencegah klien menyambungkan ke database cermin. Selain itu, faktor eksternal dapat menyebabkan koneksi membutuhkan waktu lebih lama untuk dibuka daripada waktu coba lagi yang dialokasikan. Untuk informasi tentang melewati DNS dan Browser SQL Server untuk upaya koneksi ke mitra awal, lihat Membuat Koneksi awal ke Sesi Pencerminan Database, sebelumnya dalam topik ini.

Jika upaya koneksi gagal atau waktu coba lagi kedaluwarsa sebelum berhasil, penyedia akses data mencoba mitra lain. Jika koneksi tidak dibuka pada titik ini, penyedia secara bergantian mencoba nama mitra awal dan failover, hingga koneksi dibuka atau periode masuk habis. Periode batas waktu masuk default adalah 15 detik. Kami menyarankan agar periode waktu keluar masuk setidaknya 5 detik. Menentukan periode waktu habis yang lebih kecil mungkin mencegah salah satu upaya koneksi berhasil.

Waktu coba lagi adalah persentase dari periode masuk. Waktu coba lagi untuk upaya koneksi lebih besar di setiap putaran berturut-turut. Pada putaran pertama, waktu coba lagi untuk masing-masing dari dua upaya adalah 8 persen dari total periode masuk. Dalam setiap putaran berturut-turut, algoritma coba lagi meningkatkan waktu coba lagi maksimum dengan jumlah yang sama. Dengan demikian, waktu coba lagi untuk delapan upaya koneksi pertama adalah sebagai berikut:

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

Waktu coba lagi dihitung menggunakan rumus berikut:

RetryTime PreviousRetryTime+( 0.08* LoginTimeout)=

Di mana PreviousRetryTime awalnya adalah 0.

Misalnya, jika menggunakan periode batas waktu masuk default 15 detik, LoginTimeout= 15. Dalam hal ini, waktu coba lagi yang dialokasikan dalam tiga putaran pertama adalah sebagai berikut:

Round	Perhitungan RetryTime	Coba lagi waktu per upaya
1	0 +(0,08 * 15)	1.2 detik
2	1.2 +(0.08 * 15)	2,4 detik
3	2.4 +(0.08 * 15)	3,6 detik
4	3.6 +(0.08 * 15)	4,8 detik

Gambar berikut mengilustrasikan waktu coba lagi ini untuk upaya koneksi berturut-turut, yang masing-masing kehabisan waktu.

Untuk periode waktu habis masuk default, waktu maksimum yang dialokasikan ke tiga putaran pertama upaya koneksi adalah 14,4 detik. Jika setiap upaya menggunakan semua waktu yang dialokasikan, hanya 0,6 detik waktu yang akan tetap ada sebelum periode masuk habis. Dalam hal ini, putaran keempat akan dikurasi, hanya memungkinkan upaya cepat akhir untuk terhubung menggunakan nama mitra awal. Namun, upaya koneksi mungkin gagal dalam waktu coba lagi yang kurang dari yang dialokasikan, terutama di putaran selanjutnya. Misalnya, menerima kesalahan jaringan dapat menyebabkan upaya berakhir sebelum waktu coba lagi kedaluwarsa. Jika upaya sebelumnya gagal karena kesalahan jaringan, waktu tambahan akan tersedia untuk putaran keempat dan, mungkin, putaran tambahan.

Penyebab lain dari upaya yang gagal adalah instans server yang tidak aktif, seperti yang terjadi ketika instans server terlibat dalam failover atas databasenya. Dalam hal ini, penundaan coba lagi diberlakukan untuk mencegah klien membebani mitra dengan suksesi upaya koneksi yang cepat.

Catatan

Ketika kedua nama mitra tersedia, jika periode batas waktu masuk tidak terbatas, klien mencoba untuk terhubung kembali ke server tanpa batas waktu, bergantian antara nama mitra awal dan nama mitra failover.

Coba Lagi Penundaan Selama Failover

Jika klien mencoba terhubung ke mitra yang gagal, mitra segera merespons bahwa klien tidak aktif. Dalam hal ini, setiap putaran upaya koneksi jauh lebih singkat daripada waktu coba lagi yang dialokasikan. Ini berarti bahwa banyak putaran upaya koneksi dapat terjadi sebelum periode masuk habis. Untuk menghindari kelebihan beban mitra dengan serangkaian upaya koneksi yang cepat selama failover, penyedia akses data menambahkan penundaan percobaan kembali singkat setelah setiap siklus coba lagi. Panjang penundaan coba lagi yang diberikan ditentukan oleh algoritma penundaan coba lagi. Setelah babak pertama, penundaannya adalah 100 milidetik. Setelah masing-masing dari tiga putaran berikutnya, penundaan coba lagi ganda menjadi 200, 400, dan 800. Untuk semua putaran selanjutnya, penundaan coba lagi adalah 1 detik hingga upaya koneksi berhasil atau waktu habis.

Catatan

Jika instans server dihentikan, permintaan koneksi akan segera gagal.

Gambar berikut menggambarkan bagaimana penundaan coba lagi memengaruhi upaya koneksi selama failover manual, di mana mitra mengalihkan peran mereka. Periode batas waktu masuk adalah 15 detik.

Menyambungkan kembali ke Sesi Pencerminan Database

Jika koneksi yang dibuat ke sesi pencerminan database gagal karena alasan apa pun, misalnya, karena kegagalan pencerminan database, dan aplikasi mencoba menyambungkan kembali ke server awal, penyedia akses data dapat mencoba terhubung kembali menggunakan nama mitra failover yang disimpan di cache klien. Namun, menyambungkan ulang tidak otomatis. Aplikasi harus menyadari kesalahan. Kemudian, aplikasi perlu menutup koneksi yang gagal dan membuka koneksi baru menggunakan atribut string koneksi yang sama. Pada titik ini, penyedia akses data mengalihkan koneksi ke mitra failover. Jika instans server yang diidentifikasi dengan nama ini saat ini adalah server utama, upaya koneksi biasanya berhasil. Jika tidak jelas apakah transaksi dilakukan atau digulung balik, aplikasi harus memeriksa status transaksi, dengan cara yang sama seperti saat menyambungkan kembali ke instans server yang berdiri sendiri.

Menyambungkan kembali menyerupan koneksi awal tempat string koneksi menyediakan nama mitra failover. Jika upaya koneksi pertama gagal, upaya koneksi bolak-balik antara nama mitra awal dan nama mitra failover hingga klien terhubung ke server utama atau penyedia akses data kehabisan waktu.

Catatan

SQL Server Native Client memverifikasi bahwa ia terhubung ke instans server utama tetapi tidak apakah instans ini adalah mitra instans server yang ditentukan dalam nama mitra awal string koneksi.

Jika koneksi menggunakan TCP/IP, algoritma coba lagi koneksi menentukan jumlah waktu yang dialokasikan untuk upaya koneksi di setiap putaran.

Penting

Jika klien terputus dari database, penyedia akses data tidak mencoba menyambungkan kembali. Klien harus mengeluarkan permintaan koneksi baru. Selain itu, jika aplikasi dimatikan karena kehilangan koneksi, aplikasi akan kehilangan nama mitra yang di-cache. Jika koneksi hilang karena server utama menjadi tidak tersedia, satu-satunya cara agar aplikasi dapat terhubung kembali ke server cermin adalah dengan menyediakan nama mitra failover dalam string koneksi.

Dampak Pengalihan pada Aplikasi Klien

Setelah failover, penyedia akses data mengalihkan koneksi ke instans server utama saat ini. Namun, pengalihan bersifat transparan kepada klien. Ke klien, koneksi yang dialihkan tampaknya merupakan koneksi ke instans server yang diidentifikasi oleh nama mitra awal. Ketika mitra awal saat ini adalah server cermin, klien dapat tampak terhubung ke server cermin dan memperbarui database cermin. Namun, sebenarnya, klien telah dialihkan ke mitra failover, yang merupakan database utama saat ini, dan klien memperbarui database utama baru.

Setelah dialihkan ke mitra failover, klien dapat mengalami hasil yang tidak terduga saat menggunakan pernyataan TRANSACT-SQL USE untuk menggunakan database yang berbeda. Ini dapat terjadi jika instans server utama saat ini (mitra failover) memiliki sekumpulan database yang berbeda dari server utama asli (mitra awal).

Dampak Dari Nama Mitra Failover Kedaluarsa

Administrator database dapat mengubah mitra failover kapan saja. Oleh karena itu, nama mitra failover yang disediakan klien mungkin kedaluarsa, atau kedaluarsa. Misalnya, pertimbangkan mitra failover bernama Partner_B yang digantikan oleh instans server lain, Partner_C. Sekarang, jika klien memasok Partner_B sebagai nama mitra failover, nama itu kedaluarsa. Ketika nama mitra failover yang disediakan klien basi, perilaku penyedia akses data sama dengan kasus di mana nama mitra failover tidak disediakan oleh klien.

Misalnya, pertimbangkan situasi di mana klien menggunakan satu string koneksi untuk serangkaian empat upaya koneksi. Dalam string koneksi, nama mitra awal Partner_A, dan nama mitra failover Partner_B:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"  

Tabel berikut menunjukkan empat konfigurasi mitra dan menunjukkan untuk masing-masing apakah string koneksi ini berfungsi untuk menghubungkan klien untuk pertama kalinya.

Catatan

Aplikasi dapat melacak perubahan konfigurasi dan mengubah string koneksi yang sesuai. Ini membutuhkan kode tambahan tetapi mengurangi beban administratif.

Konfigurasi	Server utama	Server cermin	Perilaku saat mencoba menyambungkan menentukan Partner_A dan Partner_B
Konfigurasi pencerminan asli.	Partner_A	Partner_B	Partner_A di-cache sebagai nama mitra awal. Klien berhasil menyambungkan ke Partner_A. Klien mengunduh nama server cermin, Partner_B, dan menyimpannya dalam cache, mengabaikan nama mitra failover yang disediakan klien.
Partner_A mengalami kegagalan perangkat keras, dan kegagalan terjadi (memutus klien).	Partner_B	tidak ada	Partner_A masih di-cache sebagai nama mitra awal, tetapi nama mitra failover yang disediakan klien, Partner_B, memungkinkan klien untuk terhubung ke server utama saat ini.
Administrator database berhenti mencerminkan (memutus sambungan klien), menggantikan Partner_A dengan Partner_C, dan memulai ulang pencerminan.	Partner_B	Partner_C	Klien mencoba untuk terhubung ke Partner_A dan gagal; kemudian klien mencoba Partner_B (server utama saat ini) dan berhasil. Penyedia akses data mengunduh nama server cermin saat ini, Partner_C, dan menyimpannya sebagai nama mitra failover saat ini.
Layanan di-failover secara manual ke Partner_C (memutus sambungan klien).	Partner_C	Partner_B	Klien mencoba menyambungkan ke Partner_A pada awalnya, lalu ke Partner_B. Kedua nama gagal, dan akhirnya waktu permintaan koneksi habis dan gagal.

Lihat Juga

Pencerminan Database (SQL Server)
Kemungkinan Kegagalan Selama Pencerminan Database