Bagikan melalui

Keandalan di Azure SQL Database

Artikel ini menjelaskan dukungan keandalan di Azure SQL Database, yang mencakup ketahanan intra-regional melalui zona ketersediaan dan penyebaran multi-wilayah.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Rekomendasi penyebaran produksi

Untuk mempelajari tentang cara menyebarkan Azure SQL Database untuk mendukung persyaratan keandalan solusi Anda, dan bagaimana keandalan memengaruhi aspek arsitektur Anda lainnya, lihat Praktik terbaik arsitektur untuk Azure SQL Database di Azure Well-Architected Framework.

Gambaran umum arsitektur keandalan

SQL Database berjalan pada mesin Database SQL Server stabil terbaru dari sistem operasi Windows, termasuk semua patch yang berlaku.

SQL Database mencapai redundansi dengan menyimpan tiga salinan data Anda dalam satu pusat data di wilayah utama secara default. Pendekatan ini melindungi data Anda jika kegagalan yang dilokalkan terjadi, seperti kegagalan jaringan skala kecil atau kegagalan daya, dan juga selama peristiwa berikut:

  • Operasi manajemen yang dimulai pelanggan yang mengakibatkan waktu henti singkat

  • Operasi pemeliharaan layanan

  • Masalah dan pemadaman pusat data, di mana pusat data memiliki komponen berikut:

    • Rak, tempat mesin yang mendukung layanan Anda berjalan

    • Komputer fisik yang menghosting komputer virtual (VM) yang menjalankan mesin SQL Database

  • Masalah lain dengan mesin SQL Database

  • Potensi pemadaman lokal lainnya yang tidak dienkripsi

SQL Database menggunakan Azure Service Fabric untuk mengelola replikasi database Anda.

Redundansi diimplementasikan dengan cara yang berbeda untuk berbagai tingkat layanan SQL Database. Untuk informasi selengkapnya, lihat Ketersediaan melalui redundansi - SQL Database.

Kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

SQL Database secara otomatis menangani tugas layanan penting, seperti patching, cadangan, Windows, dan peningkatan mesin SQL Database. Ini juga secara otomatis menangani peristiwa yang tidak terduga seperti kegagalan perangkat keras, perangkat lunak, atau jaringan yang mendasar. SQL Database dirancang untuk pulih dengan cepat dari kegagalan kritis, yang memastikan bahwa data Anda selalu tersedia. Sebagian besar pengguna tidak melihat bahwa peningkatan dilakukan terus menerus.

Saat database di-patch atau gagal, waktu henti tidak mengganggu jika Anda menggunakan logika coba lagi di aplikasi Anda.

Anda dapat menguji ketahanan aplikasi Anda terhadap kesalahan sementara dengan mengikuti panduan dalam Menguji ketahanan kesalahan aplikasi.

Dukungan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Anda dapat membuat database tunggal atau kumpulan elastis zona-redundan . Redundansi zona memastikan bahwa database Anda tahan terhadap serangkaian kegagalan besar, termasuk pemadaman pusat data bencana, tanpa perubahan apa pun pada logika aplikasi.

Untuk tingkat layanan Tujuan Umum, redundansi zona memastikan bahwa komponen komputasi tanpa status dan komponen penyimpanan data stateful SQL Database tahan terhadap pemadaman zona ketersediaan.

Untuk tingkat layanan Premium, Business Critical, dan Hyperscale, redundansi zona menempatkan replika database SQL Anda di beberapa zona ketersediaan Azure di wilayah utama Anda. Untuk menghilangkan satu titik kegagalan (SPOF), cincin kontrol juga diduplikasi di beberapa zona ketersediaan.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Persyaratan

Tingkat layanan Dasar dan Standar tidak mendukung redundansi zona.

Redundansi zona tersedia untuk database di tingkat layanan Business Critical, General Purpose, dan Hyperscale dari model pembelian berbasis vCore, dan hanya tingkat layanan Premium dari model pembelian berbasis DTU.

Untuk tingkat layanan Tujuan Umum:

  • Konfigurasi zona-redundan hanya tersedia ketika perangkat keras seri standar (Gen5) dipilih.

  • Saat Anda menggunakan database SQL zona-redundan, hanya wilayah tertentu yang mendukung jendela pemeliharaan kustom. Untuk informasi selengkapnya, lihat Dukungan wilayah SQL Database untuk jendela pemeliharaan.

Untuk tingkat layanan Premium dan Bisnis Penting:

Untuk tingkat layanan Hyperscale:

Wilayah yang didukung

Untuk tingkat layanan Premium, Tujuan Umum, dan Bisnis Penting, redundansi zona tersedia di semua wilayah Azure yang mendukung zona ketersediaan.

Untuk tingkat layanan Hyperscale, redundansi zona tersedia di semua wilayah Azure yang mendukung zona ketersediaan. Namun, dukungan redundansi zona untuk perangkat keras hyperscale seri premium dan memori seri premium yang dioptimalkan tersedia di wilayah Azure tertentu.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Pertimbangan

  • Latency: Database zona-redundan memiliki replika di pusat data terpisah. Latensi jaringan yang ditambahkan dapat meningkatkan waktu penerapan transaksi dan berpotensi memengaruhi performa beban kerja pemrosesan transaksi online (OLTP) tertentu. Sebagian besar aplikasi tidak sensitif terhadap latensi tambahan ini.

  • master database: Ketika database dengan konfigurasi zona-redundan dibuat di server logis, master database yang terkait dengan server juga secara otomatis dibuat zona redundan. Untuk informasi selengkapnya tentang cara memeriksa apakah database Anda master redundan zona, lihat Ketersediaan redundan zona database.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Biaya

Untuk tingkat layanan Tujuan Umum, ada biaya tambahan untuk mengaktifkan redundansi zona untuk SQL Database. Untuk informasi selengkapnya, lihat Harga - SQL Database.

Tingkat layanan Premium dan Business Critical menyediakan beberapa replika database Anda. Saat Anda mengaktifkan redundansi zona, replika didistribusikan di antara zona ketersediaan. Distribusi ini berarti bahwa tidak ada biaya tambahan yang terkait dengan mengaktifkan redundansi zona pada database SQL Anda saat berada di tingkat layanan Premium atau Business Critical.

Jika Anda mengaktifkan beberapa replika database tingkat layanan Hyperscale, Anda dapat mengaktifkan redundansi zona. Saat Anda mengaktifkan redundansi zona, replika didistribusikan di antara zona ketersediaan. Distribusi ini berarti bahwa tidak ada biaya tambahan yang terkait dengan mengaktifkan redundansi zona pada database SQL Anda saat berada di tingkat layanan Hyperscale, dengan asumsi bahwa Anda memiliki beberapa replika.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Mengonfigurasi dukungan zona ketersediaan

Untuk tingkat layanan Tujuan Umum, Premium, dan Bisnis Penting:

  • Sumber daya baru: Anda dapat mengonfigurasi database menjadi zona redundan saat membuatnya. Untuk informasi selengkapnya, lihat Mulai Cepat: Membuat database tunggal - SQL Database.

  • Sumber daya yang ada: Anda dapat mengonfigurasi ulang database yang ada menjadi zona redundan. Untuk informasi selengkapnya, lihat Mengaktifkan redundansi zona - SQL Database.

    Semua operasi penskalaan SQL Database, termasuk mengaktifkan redundansi zona, adalah operasi online dan memerlukan waktu henti minimal hingga tanpa waktu henti. Untuk informasi selengkapnya, lihat Menskalakan sumber daya database secara dinamis dengan waktu henti minimal.

  • Nonaktifkan redundansi zona: Anda dapat menonaktifkan redundansi zona. Proses ini adalah operasi online yang mirip dengan peningkatan tujuan tingkat layanan reguler. Di akhir proses, sebuah database dimigrasikan dari cincin yang redundan zona ke cincin zona tunggal.

Untuk tingkat layanan Hyperscale:

  • Sumber daya baru: Untuk database Hyperscale dan kumpulan elastis, redundansi zona harus dikonfigurasi saat database dibuat. Untuk informasi selengkapnya, lihat Membuat database Hyperscale dengan redundansi zona.

  • Migrasi atau nonaktifkan redundansi zona: Untuk mengaktifkan atau menonaktifkan redundansi zona pada database Hyperscale atau kumpulan elastis yang ada, Anda perlu menyebarkannya kembali. Proses ini menambahkan replika sekunder untuk ketersediaan tinggi dan menempatkannya ke zona ketersediaan yang berbeda.

    Untuk informasi selengkapnya, lihat Menyebarkan ulang database Hyperscale zona-redundan - SQL Database

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Operasi normal

Bagian ini menjelaskan apa yang diharapkan ketika database dikonfigurasi untuk redundansi zona dan semua zona ketersediaan beroperasi.

Untuk tingkat layanan Tujuan Umum:

  • Perutean lalu lintas antar zona: Permintaan dirutekan ke simpul yang menjalankan lapisan komputasi database SQL Anda. Ketika redundansi zona diaktifkan, simpul ini mungkin terletak di zona ketersediaan apa pun.

  • Replikasi data antar zona: File data dan log direplikasi secara sinkron di seluruh zona ketersediaan dengan menggunakan ZRS. Operasi tulis tidak dianggap selesai sampai data berhasil direplikasi di semua zona ketersediaan. Replikasi sinkron ini memastikan konsistensi yang kuat dan kehilangan data nol selama kegagalan zona. Namun, hal ini dapat mengakibatkan latensi tulis yang sedikit lebih tinggi dibandingkan dengan penyimpanan redundan lokal (LRS).

Untuk tingkat layanan Premium dan Bisnis Penting:

  • Perutean lalu lintas antar zona: Replika didistribusikan di seluruh zona ketersediaan, dan salah satu replika tersebut ditetapkan sebagai replika utama . Permintaan dirutekan ke replika utama database Anda.

  • Replikasi data antar zona: Replika utama terus mendorong perubahan pada replika sekunder secara berurutan untuk memastikan bahwa data bertahan pada jumlah replika sekunder yang memadai sebelum melakukan setiap transaksi. Proses ini menjamin bahwa jika replika utama atau replika sekunder yang dapat dibaca menjadi tidak tersedia karena alasan apa pun, replika yang sepenuhnya disinkronkan selalu tersedia untuk failover. Ketika redundansi zona diaktifkan, replika tersebut terletak di zona ketersediaan yang berbeda. Namun, proses ini dapat mengakibatkan latensi tulis yang sedikit lebih tinggi karena latensi jaringan di zona melintas.

Untuk tingkat layanan Hyperscale:

  • Perutean lalu lintas antar zona: Replika database didistribusikan di seluruh zona ketersediaan, dan salah satu replika tersebut ditetapkan sebagai replika utama . Permintaan dirutekan ke replika utama database Anda.

  • Replikasi data antar zona: Replika database utama mendorong perubahan melalui layanan log zona-redundan, yang mereplikasi semua perubahan secara sinkron di seluruh zona ketersediaan. Server halaman terletak di setiap zona ketersediaan dan menyimpan status database. Proses ini menjamin bahwa jika replika utama atau replika sekunder yang dapat dibaca menjadi tidak tersedia karena alasan apa pun, replika yang sepenuhnya disinkronkan selalu tersedia untuk failover. Namun, proses ini dapat mengakibatkan latensi tulis yang sedikit lebih tinggi dibandingkan dengan LRS.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Pengalaman penutupan zona

Bagian ini menjelaskan apa yang diharapkan ketika database dikonfigurasi untuk redundansi wilayah dan terjadi pemadaman di zona ketersediaan.

  • Deteksi dan respons: SQL Database bertanggung jawab untuk mendeteksi dan merespons kegagalan di zona ketersediaan. Anda tidak perlu melakukan apa pun untuk memulai failover zona.

  • Permintaan aktif: Ketika zona ketersediaan offline, setiap permintaan yang sedang diproses di zona ketersediaan yang rusak dihentikan dan harus dicoba kembali. Untuk informasi selengkapnya tentang cara membuat aplikasi Anda tahan terhadap jenis masalah ini, lihat panduan penanganan kesalahan sementara.

  • Pengalihan lalu lintas: Untuk tingkat layanan Tujuan Umum, SQL Database memindahkan mesin database ke simpul komputasi stateless lain yang berada di zona ketersediaan yang berbeda dan memiliki kapasitas bebas yang memadai. Setelah failover selesai, koneksi baru secara otomatis dialihkan ke simpul komputasi utama baru.

    Untuk informasi selengkapnya, lihat Tingkat layanan Tujuan Umum.

  • Pengalihan lalu lintas: Untuk tingkat layanan Premium dan Bisnis Penting, SQL Database memilih replika di zona ketersediaan lain untuk menjadi replika utama. Setelah replika sekunder menjadi replika utama baru, replika sekunder lainnya dibuat untuk memastikan bahwa kluster memiliki jumlah replika yang memadai untuk mempertahankan kuorum. Setelah failover selesai, koneksi baru secara otomatis dialihkan ke replika utama baru (atau replika sekunder yang dapat dibaca berdasarkan string koneksi).

    Untuk informasi selengkapnya, lihat Tingkat layanan Premium dan Bisnis Penting.

  • Pengalihan lalu lintas: Untuk tingkat layanan Hyperscale, jika replika utama hilang karena pemadaman zona, SQL Database mempromosikan salah satu replika ketersediaan tinggi di zona lain untuk menjadi replika utama baru.

    Untuk informasi selengkapnya, lihat Tingkat layanan Hyperscale.

  • Waktu henti yang diharapkan: Mungkin ada sedikit waktu henti selama failover zona ketersediaan. Waktu henti biasanya kurang dari 30 detik, yang harus ditoleransi aplikasi Anda jika mengikuti panduan penanganan kesalahan sementara.

  • Kehilangan data yang diharapkan: Tidak ada kehilangan data yang diharapkan selama failover zona ketersediaan.

Untuk melihat informasi tentang dukungan zona ketersediaan untuk tingkat layanan lain, pastikan untuk memilih tingkat layanan yang sesuai di awal halaman ini.

Pemulihan zona

Saat zona ketersediaan pulih, Azure Service Fabric secara otomatis membuat replika database di zona ketersediaan yang dipulihkan, menghapus replika sementara yang dibuat di zona ketersediaan lain, dan melanjutkan perutean lalu lintas normal ke database Anda. Untuk menghindari gangguan, replika utama tidak secara otomatis mengembalikan zona asli setelah pemulihan zona.

Pengujian kegagalan zona

Platform SQL Database mengelola prosedur perutean lalu lintas, failover, dan pemulihan zona untuk database zona-redundan. Karena fitur ini dikelola sepenuhnya, Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan. Namun, Anda dapat memvalidasi penanganan kegagalan dan failover aplikasi Anda dengan mengikuti proses yang dijelaskan dalam Menguji ketahanan kesalahan aplikasi.

Dukungan multi-wilayah

Bagian ini memberikan gambaran umum tentang dua fitur terkait tetapi terpisah yang dapat digunakan untuk replikasi geografis multi-wilayah SQL Database:

Replikasi geografis aktif membuat database sekunder yang dapat dibaca yang terus disinkronkan (yang kadang-kadang dikenal sebagai geo-sekunder atau geo-replika) di wilayah mana pun untuk satu database utama. Replikasi geografis aktif dapat membuat database sekunder di wilayah yang sama, tetapi konfigurasi ini tidak memberikan perlindungan terhadap pemadaman wilayah. Saat Anda menggunakan replikasi geografis aktif untuk mencapai geo-redundansi, Anda menemukan database sekunder di wilayah yang berbeda dengan database utama.

Dukungan wilayah

Replikasi geografis aktif dapat diaktifkan di semua wilayah Azure dan tidak mengharuskan Anda menggunakan pasangan wilayah Azure.

Petunjuk / Saran

SQL Database mengikuti praktik penyebaran yang aman di mana Azure berusaha untuk tidak menyebarkan pembaruan ke wilayah yang dipasangkan secara bersamaan. Jika Anda mengonfigurasi replikasi geografis aktif untuk menggunakan wilayah yang tidak berpasangan, atur jendela pemeliharaan yang berbeda untuk server di setiap wilayah. Pendekatan ini membantu mengurangi kemungkinan kedua wilayah mengalami masalah konektivitas yang disebabkan oleh pemeliharaan yang terjadi pada saat yang sama.

Persyaratan

Saat Anda menggunakan replikasi geografis aktif, pertimbangkan persyaratan berikut:

  • Primer dan geo-sekunder harus memiliki tingkat layanan yang sama dan harus memiliki tingkat komputasi, ukuran komputasi, dan redundansi penyimpanan cadangan yang sama.

  • Baik primer dan geo-sekunder harus memiliki aturan firewall alamat IP yang sama.

Replikasi geografis aktif didukung untuk database di berbagai langganan Azure.

Pertimbangan

  • Replikasi geografis aktif dirancang untuk memungkinkan failover pada satu database. Jika Anda perlu melakukan failover pada beberapa database, pertimbangkan untuk menggunakan grup failover sebagai gantinya.

  • Karena replikasi geografis tidak sinkron, kehilangan data dimungkinkan ketika failover terjadi. Jika Anda perlu menghilangkan kehilangan data dari replikasi asinkron selama failover, konfigurasikan aplikasi Anda untuk memblokir utas panggilan hingga transaksi terakhir yang dilakukan dikirimkan dan diperkeras dalam log transaksi database sekunder. Pendekatan ini memerlukan pengembangan kustom dan mengurangi performa aplikasi Anda. Untuk informasi selengkapnya, lihat Mencegah hilangnya data penting.

  • Untuk informasi selengkapnya, lihat Replikasi geografis aktif.

Biaya

Database sekunder dikenakan biaya sebagai database yang terpisah.

Jika Anda tidak menggunakan database sekunder untuk beban kerja baca atau tulis apa pun, pertimbangkan apakah Anda dapat menunjuknya sebagai replika siaga untuk mengurangi biaya Anda.

Mengonfigurasi dukungan multiregional

Operasi normal

Bagian ini menjelaskan apa yang diharapkan ketika database dikonfigurasi untuk menggunakan replikasi geografis aktif dan semua wilayah beroperasi.

  • Perutean lalu lintas antar wilayah: Aplikasi Anda harus dikonfigurasi untuk mengirim permintaan baca-tulis ke database utama. Anda dapat secara opsional mengirim permintaan baca-saja ke database sekunder, yang membantu mengurangi dampak beban kerja baca-saja pada database utama Anda.

  • Replikasi data antar wilayah: Replikasi antara database utama dan sekunder terjadi secara asinkron, yang berarti bahwa mungkin ada penundaan antara saat perubahan diterapkan ke database utama dan ketika direplikasi ke database sekunder.

    Saat Anda melakukan failover, Anda memutuskan cara menangani kemungkinan kehilangan data.

Pengalaman wilayah yang mengalami gangguan

Bagian ini menjelaskan apa yang diharapkan ketika database dikonfigurasi untuk menggunakan replikasi geografis aktif dan ada pemadaman di wilayah utama Anda:

  • Deteksi dan respons: Anda bertanggung jawab untuk mendeteksi pemadaman database atau wilayah dan untuk memicu failover.

  • Permintaan aktif: Setiap permintaan aktif selama failover dihentikan dan harus dicoba kembali.

  • Kehilangan data yang diharapkan: Jika database utama Anda tersedia, Anda dapat secara opsional melakukan failover tanpa kehilangan data. Proses failover menyinkronkan data antara database utama dan sekunder sebelum beralih peran.

    Jika database utama Anda tidak tersedia, Anda mungkin perlu melakukan failover paksa, yang mengacu pada kehilangan data. Anda dapat memperkirakan jumlah kehilangan data dengan memantau jeda replikasi. Untuk informasi selengkapnya, lihat Memantau SQL Database dengan metrik dan pemberitahuan.

  • Waktu henti yang diharapkan: Biasanya ada waktu henti hingga 60 detik selama failover. Pastikan aplikasi Anda menangani kesalahan sementara sehingga dapat pulih dari waktu henti dalam waktu singkat. Selain itu, seberapa cepat Anda mengonfigurasi ulang aplikasi untuk menyambungkan ke database utama baru memengaruhi waktu henti yang Anda alami.

  • Pengalihan lalu lintas: Anda bertanggung jawab untuk mengonfigurasi ulang aplikasi Anda untuk mengirim permintaan ke database utama baru. Jika Anda perlu memiliki failover transparan, pertimbangkan untuk menggunakan grup failover.

Pemulihan wilayah

Setelah wilayah utama pulih, Anda dapat melakukan failback secara manual ke wilayah utama dengan melakukan failover lain.

Pengujian untuk kegagalan di dalam wilayah

Anda dapat mensimulasikan pemadaman wilayah dengan memicu failover manual kapan saja. Anda dapat memicu failover (tidak ada kehilangan data) atau failover paksa.

Backups

Ambil cadangan database Anda untuk melindungi dari berbagai risiko, termasuk hilangnya data. Cadangan dapat dipulihkan untuk pulih dari kehilangan data yang tidak disengaja, kerusakan, atau masalah lainnya. Pencadangan berbeda dari redundansi zona, replikasi geografis aktif, atau grup failover, dan memiliki tujuan yang berbeda. Untuk informasi selengkapnya, lihat Redundansi, replikasi, dan pencadangan.

SQL Database menyediakan pencadangan otomatis database Anda. Untuk informasi selengkapnya tentang frekuensi pencadangan, yang dapat memengaruhi jumlah kehilangan data jika Anda perlu memulihkan dari cadangan, lihat Pencadangan otomatis di SQL Database.

Penyimpanan cadangan

Anda dapat memilih untuk menyimpan cadangan otomatis Anda di LRS atau ZRS. Jika Anda menggunakan wilayah yang dipasangkan, Anda dapat memilih untuk mereplikasi cadangan otomatis Anda ke wilayah yang dipasangkan dengan menggunakan penyimpanan geo-redundan. Kemampuan ini memungkinkan pemulihan geografis cadangan Anda ke wilayah yang dipasangkan. Untuk informasi selengkapnya, lihat Pencadangan otomatis di SQL Database.

Jika Anda menggunakan wilayah yang tidak berpasangan, atau jika Anda perlu mereplikasi cadangan ke wilayah selain wilayah yang dipasangkan, pertimbangkan untuk mengekspor database dan menyimpan file yang diekspor di akun penyimpanan yang menggunakan replikasi objek blob untuk mereplikasi ke akun penyimpanan di wilayah lain. Untuk informasi selengkapnya, lihat Mengekspor database.

Keandalan selama pemeliharaan layanan

Saat SQL Database melakukan pemeliharaan pada database dan kumpulan elastis Anda, database mungkin secara otomatis gagal atas database Anda untuk menggunakan replika sekunder. Aplikasi klien mungkin mengamati gangguan konektivitas singkat saat failover terjadi. Aplikasi klien Anda harus mengikuti panduan penanganan kesalahan sementara untuk meminimalkan efeknya.

SQL Database memungkinkan Anda menentukan jendela pemeliharaan yang biasanya digunakan untuk peningkatan layanan dan operasi pemeliharaan lainnya. Mengonfigurasi jendela pemeliharaan dapat membantu Anda meminimalkan efek samping apa pun, seperti failover otomatis, selama jam kerja Anda. Anda juga dapat menerima pemberitahuan terlebih dahulu tentang pemeliharaan terencana.

Platform ini secara otomatis mempertahankan gateway yang digunakan untuk memproses koneksi ke SQL Database. Peningkatan atau operasi pemeliharaan juga dapat menyebabkan gangguan konektivitas singkat yang dapat diulang oleh klien.

Untuk informasi selengkapnya, lihat Jendela pemeliharaan di SQL Database.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk SQL Database menjelaskan ketersediaan layanan yang diharapkan dan titik pemulihan dan waktu pemulihan yang diharapkan untuk replikasi geografis aktif. Ini juga menjelaskan kondisi yang harus dipenuhi untuk mencapai harapan tersebut. Untuk memahami kondisi tersebut, penting bagi Anda untuk meninjau SLA untuk layanan online.

Saat Anda menyebarkan database zona redundan atau kumpulan elastis dan menggunakan tingkat layanan yang didukung, waktu aktif SLA lebih tinggi.

Konten terkait

  • Last updated on