Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server)
Untuk menyambungkan ke sesi pencerminan database, klien dapat menggunakan Penyedia Data SQL Server Native Client atau .NET Framework untuk SQL Server. Saat dikonfigurasi untuk database SQL Server 2014, 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 Sumber (SQL Server). Koneksi klien ke sesi pencerminan database tidak melibatkan instans server bukti, 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 di 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 saat 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 atau reset koneksi berikutnya mengembalikan nama mitra yang berbeda.
Gambar berikut mengilustrasikan koneksi klien ke mitra awal, Partner_A, untuk database cermin bernama Db_1. Gambar 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 menyediakan nama mitra failover dalam 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 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 berakhir atau periode batas waktu masuk berakhir pada penyedia akses data. Biasanya, penantian ini berada pada urutan 20 hingga 30 detik. Setelah itu, jika penyedia akses data belum kehabisan waktu, ia mencoba untuk 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 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 SQL Server Native Client Koneksi Driver ODBC.
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 Server atribut yang memasok 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>]. Contohnya:
Server=Partner_A;
atau
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 dalam Server atribut , 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, Server atribut 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 Database atribut untuk menyediakan nama database yang dicerminkan. Jika database tidak tersedia saat klien mencoba menyambungkan, pengecualian akan dinaikkan.
Misalnya, untuk menyambungkan secara tegas 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 Server atribut (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 dalam Server atribut ("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 bergantung pada API yang Anda gunakan. Tabel berikut mencantumkan kata kunci ini:
| API | Kata kunci untuk atribut mitra failover |
|---|---|
| Penyedia OLE DB | FailoverPartner |
| Driver ODBC | Failover_Partner |
| Objek Data ActiveX (ADO) | Failover Partner |
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 dalam Failover Partner atribut . Jika upaya koneksi awal gagal selama koneksi pertama ke database, upaya untuk terhubung ke mitra failover akan dibebaskan dari mengandalkan DNS dan SQL Server Browser. Setelah koneksi dibuat, nama mitra failover akan ditimpa dengan nama mitra failover, jadi jika failover terjadi, koneksi yang dialihkan akan memerlukan DNS dan SQL Server Browser.
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 ConnectionStringSqlConnection objek . 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
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 koneksinya adalah:
"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"
Algoritma Coba Lagi Koneksi (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, pengendali domain lambat/Kerberos Key Distribution Center (KDC), waktu yang dihabiskan untuk menghubungi browser SQL Server, kemacetan jaringan, dan sebagainya. Faktor eksternal tersebut dapat mencegah klien tersambung 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, sampai koneksi dibuka atau periode masuk habis. Periode batas waktu masuk default adalah 15 detik. Kami menyarankan agar periode waktu habis 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 babak 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:
Coba LagiTime=PreviousRetryTime+( 0.08 *LoginTimeout)
Di mana PreviousRetryTime awalnya adalah 0.
Misalnya, jika menggunakan periode waktu habis 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 dikurangi, memungkinkan hanya 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 kegagalan 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 waktu habis 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 coba lagi 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 dua kali lipat ke 200, 400, dan 800. Untuk semua putaran selanjutnya, penundaan coba lagi adalah 1 detik hingga upaya koneksi berhasil atau kehabisan waktu.
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 beralih 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 untuk terhubung kembali ke server awal, penyedia akses data dapat mencoba untuk terhubung kembali menggunakan nama mitra failover yang disimpan di cache klien. Namun, menyambungkan kembali 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 yang string koneksinya menyediakan nama mitra failover. Jika upaya koneksi pertama gagal, upaya koneksi bergantian 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 instans tersebut terhubung ke instans server utama tetapi bukan 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 aplikasi dapat terhubung kembali ke server cermin adalah dengan menyediakan nama mitra failover dalam string koneksinya.
Dampak Pengalihan pada Aplikasi Klien
Setelah failover, penyedia akses data mengalihkan koneksi ke instans server utama saat ini. Namun, pengalihan transparan kepada klien. Kepada 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. Sebenarnya, bagaimanapun, 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 sudah kedaluarsa, atau kedaluarsa. Misalnya, pertimbangkan mitra failover bernama Partner_B yang digantikan oleh instans server lain, Partner_C. Sekarang, jika klien menyediakan Partner_B sebagai nama mitra failover, nama tersebut kedaluarsa. Ketika nama mitra failover yang disediakan klien kedaluarsa, 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 koneksinya. 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 failover terjadi (memutus sambungan 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), mengganti 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 dialihkan 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