Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 dalam menggunakan basis data tercermin, lihat Menggunakan Pencerminan Basis Data. Selain itu, instans server utama saat ini harus tersedia dan login klien harus dibuat pada instans server. Untuk informasi selengkapnya, lihat Memecahkan Masalah Pengguna Yatim (SQL Server). Koneksi klien ke sesi pencerminan basis data tidak melibatkan instans server saksi, jika instans tersebut 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. Hal ini diperlukan untuk mengaktifkan percobaan 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 terhubung, penyedia akses data terlebih dahulu menggunakan nama mitra pertama. 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 dapat diakses oleh klien hingga pencerminan dilanjutkan kembali.
Jika upaya tersebut tidak berhasil, penyedia akses data akan mencoba nama failover partner, 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 di 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 dari 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 itu, jika nama mitra failover tidak tersedia, upaya koneksi awal akan terus berlanjut hingga batas waktu koneksi jaringan tercapai atau terjadi kesalahan (sama seperti pada database tanpa pencerminan).
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 percobaan ulang koneksi yang khusus digunakan untuk pencerminan basis data. algoritma percobaan ulang koneksi menentukan waktu maksimum (waktu percobaan ulang) yang diberikan untuk membuka koneksi dalam percobaan 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, waktu tunggu ini sekitar 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 untuk Database Tercermin
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 klien meminta pipa bernama untuk setiap koneksi dengan mitra, string koneksi menyertakan atribut berikut:
Network=dbnmpntw;
Penting
Karena named pipe tidak menggunakan algoritma percobaan ulang TCP/IP, dalam banyak kasus, upaya koneksi named pipe dapat habis waktu sebelum terhubung 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>]. 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 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 Basis Data
Selain itu, string koneksi harus menentukan atribut Database untuk menyediakan nama database yang dicerminkan. Jika basis data tidak tersedia saat klien mencoba terhubung, pengecualian akan dimunculkan.
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) 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 Pasangan 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 (Pengandar ODBC) | Failover_Partner |
| ActiveX Data Objects (ADO) | Mitra Pengalihan Otomatis |
Cara paling sederhana untuk mengidentifikasi instans server adalah dengan nama sistemnya, <server_name>[\<SQL_Server_instance_name>].
Atau, alamat IP dan nomor port dapat ditentukan dalam atribut Failover Partner. 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 berhasil dibuat, nama mitra failover akan ditimpa dengan nama mitra failover, sehingga jika terjadi failover, koneksi yang diarahkan ulang 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 ConnectionString objek SqlConnection . 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 koneksi 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. Hal ini berlaku baik untuk membuat koneksi awal ke sesi maupun untuk menghubungkan kembali setelah kehilangan koneksi yang telah terjalin. 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 mengabaikan DNS dan SQL Server Browser saat mencoba tersambung ke mitra awal, lihat Membuat Sambungan Awal ke Sesi Pencerminan Database, yang dibahas sebelumnya dalam topik ini.
Jika upaya koneksi gagal atau waktu coba lagi kedaluwarsa sebelum berhasil, penyedia akses data mencoba mitra lain. Jika koneksi belum terjalin hingga saat ini, penyedia akan secara bergantian mencoba nama mitra awal dan mitra failover hingga koneksi berhasil dibuat atau batas waktu login berakhir. Batas waktu login default adalah 15 detik. Kami menyarankan agar periode waktu keluar masuk setidaknya 5 detik. Menentukan batas waktu tunggu yang lebih singkat dapat menyebabkan tidak satu pun upaya koneksi berhasil.
Waktu percobaan ulang merupakan persentase dari periode login. Waktu tunggu sebelum mencoba lagi untuk upaya koneksi menjadi semakin lama pada setiap putaran berikutnya. Pada babak pertama, waktu tunggu untuk mencoba lagi pada masing-masing dari dua percobaan adalah 8 persen dari total periode login. 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:
| Bulat | Perhitungan RetryTime | Waktu percobaan ulang 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 batas waktu login default, waktu maksimum yang dialokasikan untuk tiga tahap pertama upaya koneksi adalah 14,4 detik. Jika setiap upaya menggunakan seluruh waktu yang dialokasikan, hanya akan tersisa 0,6 detik sebelum periode login berakhir. Dalam hal itu, putaran keempat akan dipersingkat, sehingga hanya memungkinkan satu upaya cepat terakhir untuk terhubung menggunakan nama mitra awal. Namun, upaya koneksi mungkin gagal dalam waktu yang lebih singkat daripada waktu percobaan ulang yang dialokasikan, terutama pada putaran-putaran berikutnya. 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, jeda sebelum mencoba lagi diberlakukan untuk mencegah klien membebani pihak mitra dengan serangkaian upaya koneksi yang dilakukan secara 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 sedang melakukan failover, mitra tersebut segera merespons bahwa mitra tersebut tidak aktif. Dalam hal ini, setiap putaran upaya koneksi jauh lebih singkat daripada waktu coba lagi yang dialokasikan. Ini berarti bahwa banyak siklus upaya koneksi dapat terjadi sebelum periode login berakhir karena habis waktu. Untuk menghindari membebani mitra secara berlebihan dengan serangkaian upaya koneksi yang cepat selama failover, penyedia akses data menambahkan jeda singkat sebelum mencoba lagi setelah setiap siklus percobaan ulang. Panjang penundaan coba lagi yang diberikan ditentukan oleh algoritma penundaan coba lagi. Setelah babak pertama, penundaannya adalah 100 milidetik. Setelah setiap dari tiga putaran berikutnya, jeda percobaan ulang berlipat dua 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 mengilustrasikan bagaimana jeda percobaan ulang memengaruhi upaya koneksi selama failover manual, di mana mitra saling bertukar peran. 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.
Penyambungan kembali menyerupai koneksi awal yang string koneksinya menyertakan 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 koneksi dilakukan ke instans server utama, tetapi tidak memverifikasi apakah instans ini adalah instans server mitra yang ditentukan dalam nama mitra awal pada 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. Bagi klien, koneksi yang dialihkan tampak seperti koneksi ke instans server yang diidentifikasi dengan 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 sudah tidak mutakhir, atau kedaluwarsa. 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 adalah Partner_A, dan nama mitra failover adalah 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 terhubung dengan 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 koneksi 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 tidak berhasil, dan pada akhirnya permintaan koneksi kehabisan waktu lalu gagal. |