Bagikan melalui

Keandalan di Azure SQL Database

Azure SQL Database adalah mesin database platform as a service (PaaS) yang dikelola sepenuhnya yang menangani sebagian besar fungsi manajemen database seperti peningkatan, patching, pencadangan, dan pemantauan tanpa keterlibatan pengguna.

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.

Artikel ini menjelaskan cara membuat Azure SQL Database tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, dan pemadaman wilayah. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan untuk memulihkan dari jenis masalah lain, cara menangani pemeliharaan layanan, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) Azure SQL Database.

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 dilakukan oleh pelanggan yang mengakibatkan gangguan 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 tak terencana lainnya

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.

Ketahanan terhadap 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 diperbarui atau mengalami kegagalan, waktu henti tidak akan 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.

Ketahanan terhadap kegagalan 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 lapisan layanan General Purpose, redundansi zonasi memastikan bahwa komponen komputasi stateless dan komponen penyimpanan data stateful dari SQL Database tahan terhadap gangguan zonasi 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:

Untuk tingkat layanan Premium dan Bisnis Penting:

Untuk tingkat layanan Hyperscale:

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 yang berada di pusat data yang 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 redundan zona dibuat di server logis, database yang terkait dengan server juga dibuat secara otomatis menjadi redundan zona. Untuk informasi selengkapnya tentang memeriksa apakah database Anda master zona redundan, lihat Ketersediaan database yang zona redundan.

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.

Perilaku ketika semua zona sehat

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.

Perilaku selama kegagalan 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.
  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.
  • 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 Ketahanan terhadap 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 ketika terjadi failover pada zona ketersediaan. Waktu henti biasanya kurang dari 30 detik, yang harus ditoleransi aplikasi Anda jika mengikuti panduan Ketahanan terhadap 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.

Uji kegagalan zona

Platform Database SQL mengelola prosedur perutean lalu lintas, failover, dan prosedur 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.

Ketahanan terhadap kegagalan di seluruh wilayah

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

Replikasi Geo Aktif

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.

Persyaratan

Saat Anda menggunakan replikasi geografis aktif, pertimbangkan persyaratan berikut:

  • 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 menghindari untuk menyebarkan pembaruan ke region yang berpasangan 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.

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

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

  • Langganan Azure: 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 tentang batasan dan pertimbangan, 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

Perilaku ketika semua wilayah sehat

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.

Perilaku selama kegagalan wilayah

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.
  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • 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 dapat menyebabkan 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 mendeteksi kegagalan wilayah

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

Grup failover

Grup failover memanfaatkan replikasi geoaktif. Dengan grup failover, Anda dapat melakukan operasi berikut:

  • Replikasi sekumpulan database dari satu server logis di semua kombinasi wilayah Azure.

  • Lakukan failover pada database sebagai satu grup.

  • Gunakan titik akhir koneksi yang secara otomatis mengarahkan koneksi ke primer.

Persyaratan

  • Dukungan wilayah: Grup failover dapat dibuat di semua wilayah Azure dan tidak mengharuskan Anda menggunakan pasangan wilayah Azure.

    Petunjuk / Saran

    Jika Anda mengonfigurasi grup failover dengan wilayah yang tidak berpasangan, pertimbangkan untuk mengatur 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.

  • Konfigurasi: Database sekunder dalam grup failover harus memiliki tingkat layanan, tingkat komputasi, ukuran komputasi, aturan firewall alamat IP, dan redundansi penyimpanan cadangan yang sama dengan database utama.

Pertimbangan

  • Redundansi zona: Untuk tingkat layanan Hyperscale, jika database utama Anda mengaktifkan redundansi zona, database sekunder mengaktifkan redundansi zona secara otomatis.
  • Redundansi zona: Database sekunder tidak mengaktifkan redundansi zona secara default, tetapi Anda dapat mengaktifkannya nanti.

  • Kemungkinan kehilangan data: Karena replikasi geografis tidak sinkron, ada kemungkinan kehilangan data ketika failover terjadi. Jika Anda perlu menghilangkan kehilangan data dari replikasi asinkron selama failover, Anda dapat mengonfigurasi 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 lebih lanjut tentang batasan dan pertimbangan, lihat Kelompok failover.

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

  • Aktifkan grup failover: Anda mengonfigurasi grup failover di server logis. Anda bisa menambahkan semua database di server logis ke grup failover, atau Anda bisa memilih subset database yang akan ditambahkan.

    Saat membuat grup failover, Anda memilih kebijakan failover, yang menentukan siapa yang bertanggung jawab untuk mendeteksi pemadaman dan melakukan failover. Anda dapat mengonfigurasi failover yang dikelola oleh pelanggan, yang sangat direkomendasikan, atau failover yang dikelola oleh Microsoft.

    Penting

    Failover yang diinisiasi oleh Microsoft kemungkinan akan terjadi setelah penundaan yang signifikan dan dilakukan berdasarkan upaya terbaik. Failover database mungkin terjadi pada waktu yang berbeda dengan failover layanan Azure lainnya. Untuk informasi selengkapnya, lihat Mengonfigurasi grup failover untuk SQL Database.

    Setelah Anda mengonfigurasi grup failover, tahap inisialisasi awal dapat memakan waktu.

  • Nonaktifkan grup failover: Anda bisa menghapus database individual dari grup failover, menghapus seluruh grup failover, atau memindahkan database ke grup failover yang berbeda.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika database dikonfigurasi dalam grup failover dan semua wilayah beroperasi.

  • Perutean lalu lintas antar wilayah: Untuk beban kerja baca-tulis dan baca-saja, grup failover menyediakan dua titik akhir pendengar tempat Anda dapat menghubungkan aplikasi Anda. Gunakan titik akhir pendengar dari grup failover untuk meminimalkan waktu henti selama proses failover. Selama operasi normal, perilaku perutean berikut terjadi:

    • Titik akhir pendengar baca tulis merutekan semua permintaan ke database utama.

    • Titik akhir pendengar baca-saja merutekan semua permintaan ke database sekunder yang dapat dibaca.

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

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

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika database dikonfigurasi dalam grup failover dan ada pemadaman di wilayah utama Anda:

  • Deteksi dan respons tergantung pada kebijakan failover yang Anda gunakan.

    • Failover yang dimulai pelanggan: Anda bertanggung jawab untuk mendeteksi pemadaman database atau wilayah dan untuk memicu failover.

    • Failover yang diinisiasi oleh Microsoft: Microsoft menginisiasi failover untuk semua kelompok failover di wilayah yang terdampak. Microsoft mengharapkan untuk melakukan jenis failover ini hanya dalam situasi yang luar biasa. Jangan mengandalkan failover yang dikelola Microsoft untuk sebagian besar solusi. Untuk informasi selengkapnya, lihat Kebijakan failover - Dikelola Microsoft.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

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

  • Kehilangan data yang diharapkan: Kehilangan data tergantung pada kebijakan failover yang Anda gunakan.

    • Failover yang dipicu oleh pelanggan: Jika database utama Anda tersedia, Anda dapat memilih untuk 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 dapat menyebabkan kehilangan data. Anda dapat memperkirakan jumlah kehilangan data dengan memantau jeda replikasi. Untuk informasi selengkapnya, lihat Memantau SQL Database dengan metrik dan pemberitahuan.

    • Failover yang dimulai oleh Microsoft: Failover yang dikelola oleh Microsoft hanya terjadi dalam situasi-situasi yang tidak biasa. Failover yang dikelola Microsoft adalah failover paksa, yang berarti bahwa beberapa kehilangan data dapat terjadi. Anda tidak dapat mengontrol jumlah kehilangan data yang mungkin Anda alami.

  • Waktu henti yang diharapkan: Waktu henti tergantung pada kebijakan failover yang Anda gunakan.

    • Failover yang dimulai pelanggan: Biasanya ada downtime hingga 60 detik selama failover. Pastikan aplikasi Anda menangani kesalahan sementara sehingga dapat pulih dari waktu henti dalam waktu singkat.

    • Alih fungsi yang dimulai oleh Microsoft: Anda dapat menentukan masa tenggang yang menentukan berapa lama Microsoft harus menunggu sebelum memulai alih fungsi. Masa tenggang minimum adalah satu jam. Namun, waktu respons Microsoft kemungkinan akan menjadi beberapa jam setidaknya.

  • Pengalihan lalu lintas: Selama failover, SQL Database memperbarui titik akhir pendengar baca-tulis dan baca-saja untuk mengarahkan lalu lintas ke database utama dan sekunder baru sesuai kebutuhan.

    Jika database sekunder baru (sebelumnya database utama) tidak tersedia, titik akhir pendengar baca-saja tidak dapat tersambung hingga sekunder baru tersedia.

Pemulihan wilayah

Anda bertanggung jawab untuk gagal kembali ke wilayah utama jika Anda perlu melakukannya. Anda dapat melakukan failback secara manual ke wilayah utama dengan melakukan failover yang dikelola oleh pelanggan.

Bahkan jika Microsoft memulai failover asli, Anda masih bertanggung jawab untuk memulihkan kembali ke wilayah sebelumnya, jika Anda memilih untuk melakukannya.

Pengujian untuk mendeteksi kegagalan wilayah

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

Pencadangan dan pemulihan

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 basis data 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.

Ketahanan terhadap pemeliharaan layanan

Saat SQL Database melakukan pemeliharaan pada database dan elastic pool Anda, database mungkin secara otomatis mengalihkan ke replika sekunder. Aplikasi klien mungkin mengamati gangguan konektivitas singkat saat failover terjadi. Aplikasi klien Anda harus mengikuti panduan Ketahanan terhadap 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 layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Perjanjian tingkat layanan (SLA) untuk SQL Database menjelaskan ketersediaan layanan yang diharapkan dan titik pemulihan dan waktu pemulihan yang diharapkan untuk replikasi geografis aktif.

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