Bagikan melalui

Ceklist ketersediaan tinggi dan pemulihan bencana - Azure SQL Database

Berlaku untuk:Azure SQL Database

Layanan Azure SQL Database secara otomatis memastikan semua database online, sehat, dan terus berusaha untuk mencapai SLA yang diterbitkan.

Panduan ini menyediakan tinjauan terperinci tentang langkah-langkah proaktif yang dapat Anda ambil untuk memaksimalkan ketersediaan, memastikan pemulihan, dan mempersiapkan pemadaman Azure. Panduan ini berlaku untuk semua model pembelian dan tingkat layanan Azure SQL Database.

Daftar periksa ketersediaan

Berikut ini adalah konfigurasi yang direkomendasikan untuk memaksimalkan ketersediaan:

  • Masukkan logika coba lagi dalam aplikasi untuk menangani kesalahan sementara.
  • Gunakan waktu pemeliharaan agar peristiwa pemeliharaan yang berdampak lebih dapat diprediksi dan mengurangi gangguan.
  • Uji ketangguhan kesalahan aplikasi dengan memicu failover secara manual untuk melihat ketangguhan dalam praktik.

Daftar periksa ketersediaan tinggi

Berikut ini adalah konfigurasi yang direkomendasikan untuk mencapai ketersediaan tinggi:

  • Aktifkan redundansi zona di lokasi yang tersedia untuk database atau kumpulan elastis guna memastikan ketahanan terhadap kegagalan zona.

Daftar periksa pemulihan bencana

Meskipun Azure SQL Database secara otomatis menjaga ketersediaan, ada kasus ketika bahkan memiliki ketersediaan tinggi (redundansi zona) mungkin tidak menjamin ketahanan, karena pemadaman yang memengaruhi wilayah yang lebih luas. Pemadaman Azure SQL Database regional mungkin mengharuskan Anda memulai pemulihan bencana.

Untuk mempersiapkan pemulihan bencana dengan terbaik, ikuti rekomendasi berikut:

  • Aktifkan grup pemulihan otomatis untuk sekelompok database.
    • Gunakan titik akhir pendengar baca-tulis dan baca-saja pada string koneksi aplikasi Anda, sehingga aplikasi dapat terhubung secara otomatis ke server dan database manapun yang saat ini menjadi utama.
    • Atur kebijakan failover ke dikelola pelanggan.
  • Sebagai alternatif untuk grup failover, Anda dapat mengaktifkan replikasi geoaktif untuk memiliki database sekunder yang dapat dibaca di wilayah Azure yang berbeda.
  • Pastikan bahwa database geo-sekunder dibuat dengan tingkat layanan yang sama, tingkat komputasi (disediakan atau tanpa server) dan ukuran komputasi (DTU atau vCore) sebagai database utama.
  • Saat meningkatkan skala, tingkatkan geo-sekunder terlebih dahulu, lalu tingkatkan skala primer.
  • Saat mengecilkan skala, balikkan urutan: turunkan skala primer terlebih dahulu, kemudian turunkan skala sekunder.
  • Pemulihan bencana, secara alami, dirancang untuk menggunakan replikasi data asinkron antara wilayah primer dan sekunder. Untuk memprioritaskan ketersediaan data daripada latensi komit yang lebih tinggi, pertimbangkan untuk memanggil prosedur tersimpan sp_wait_for_database_copy_sync segera setelah menyelesaikan transaksi. Memanggil sp_wait_for_database_copy_sync akan memblokir utas panggilan hingga transaksi terakhir yang dilakukan telah dikirim ke database sekunder.
  • Pantau lag sehubungan dengan Tujuan Titik Pemulihan (RPO) menggunakan kolom replication_lag_sec dari tampilan manajemen dinamis (DMV) sys.dm_geo_replication_link_status pada database utama. DMV menunjukkan jeda dalam beberapa detik antara transaksi yang dilakukan pada primer dan dicatat permanen ke log transaksi pada sekunder. Misalnya, asumsikan jeda adalah satu detik pada satu titik waktu, jika sistem utama mengalami gangguan dan pemindahan operasi ke lokasi geografis lain dimulai pada saat itu, transaksi yang telah diselesaikan pada detik terakhir akan hilang.
  • Jika mengaktifkan grup failover atau replikasi geografis aktif tidak dimungkinkan, maka pertimbangkan untuk mengatur opsi redundansi penyimpanan cadangan ke penyimpanan cadangan geo-redundan untuk menggunakan pemulihan geo-restore untuk Azure SQL Database.
  • Sering merencanakan dan menjalankan latihan pemulihan bencana sehingga Anda lebih siap jika terjadi pemadaman nyata.

Menyiapkan sistem cadangan untuk pemadaman

Agar berhasil memulihkan ke wilayah data lain menggunakan replikasi geografis aktif, grup failover, atau pemulihan geografis, Anda perlu menyiapkan server logis Azure SQL Database sekunder di wilayah lain. Server sekunder ini dapat menjadi server utama baru jika diperlukan. Anda juga harus memiliki langkah-langkah yang terdefinisi dengan baik yang didokumenkan dan diuji untuk memastikan pemulihan yang lancar. Langkah-langkah persiapan ini meliputi:

  • Untuk pemulihan geografis, identifikasi server di wilayah lain untuk menjadi server utama baru. Jika wilayah utama Anda memiliki wilayah berpasangan, umumnya menggunakan wilayah berpasangan sebagai wilayah sekunder Anda. Dengan melakukan ini, Anda biasanya mengurangi latensi untuk operasi replikasi dan pemulihan geografis.
  • Tentukan bagaimana Anda akan mengalihkan pengguna ke server utama baru. Mengalihkan pengguna dapat dicapai dengan mengubah string koneksi aplikasi atau entri DNS secara manual. Jika Anda telah mengonfigurasi grup failover dan menggunakan listener baca-tulis dan baca-saja di string koneksi aplikasi, tidak ada tindakan lebih lanjut yang diperlukan - koneksi secara otomatis diarahkan ke primer baru setelah failover.
  • Identifikasi, dan tentukan secara opsional, aturan firewall yang diperlukan pengguna untuk mengakses database utama baru.
  • Identifikasi, dan buat secara opsional, login yang harus ada dalam master database di server utama baru, dan pastikan login ini memiliki izin yang sesuai dalam master database, jika ada. Untuk informasi selengkapnya, lihat Mengonfigurasi dan mengelola keamanan Azure SQL Database untuk pemulihan geografis atau failover.
  • Identifikasi aturan peringatan yang perlu diperbarui untuk menyesuaikan dengan primer yang baru.
  • Dokumentasikan konfigurasi audit pada server utama saat ini dan buat identik di server sekunder.

Konten terkait

  • Last updated on