Daftar periksa ketersediaan tinggi dan pemulihan bencana Azure SQL Database

  • Artikel

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 jendela pemeliharaan untuk membuat peristiwa pemeliharaan yang berdampak dapat diprediksi dan kurang mengganggu.
  • Uji ketahanan kesalahan aplikasi dengan memicu failover secara manual untuk melihat ketahanan dalam tindakan.

Daftar periksa ketersediaan tinggi

Berikut ini adalah konfigurasi yang direkomendasikan untuk mencapai ketersediaan tinggi:

  • Aktifkan redundansi zona jika tersedia untuk database atau kumpulan elastis untuk memastikan ketahanan terhadap kegagalan zona.

Daftar periksa pemulihan bencana

Meskipun Azure SQL Database secara otomatis mempertahankan ketersediaan, ada instans ketika bahkan memiliki ketersediaan tinggi (redundansi zona) mungkin tidak menjamin ketahanan karena pemadaman yang berdampak mencakup seluruh wilayah. Pemadaman Azure SQL Database regional mungkin mengharuskan Anda memulai pemulihan bencana.

Untuk mempersiapkan pemulihan bencana dengan terbaik, ikuti rekomendasi berikut:

  • Aktifkan grup failover untuk sekelompok database.
    • Gunakan titik akhir listener baca-tulis dan baca-saja di aplikasi Anda string koneksi sehingga aplikasi secara otomatis terhubung ke server dan database mana pun yang utama.
    • Atur kebijakan failover ke yang dikelola pelanggan.
  • Atau untuk grup failover, Anda dapat mengaktifkan replikasi geografis aktif 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 menskalakan, balikkan urutan: skala bawah primer pertama, dan kemudian skala bawah sekunder.
  • Pemulihan bencana, secara alami, dirancang untuk menggunakan replikasi data asinkron antara wilayah primer dan sekunder. Untuk memprioritaskan ketersediaan data daripada latensi penerapan yang lebih tinggi, pertimbangkan untuk memanggil prosedur tersimpan sp_wait_for_database_copy_sync segera setelah melakukan 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) dengan menggunakan replication_lag_sec kolom tampilan manajemen dinamis (DMV) sys.dm_geo_replication_link_status pada database utama. DMV menunjukkan lag dalam hitungan detik antara transaksi yang dilakukan pada primer dan diperkeras ke log transaksi pada sekunder. Misalnya, asumsikan jeda adalah satu detik pada satu titik waktu, jika primer terpengaruh oleh pemadaman dan geo-failover dimulai pada saat itu, transaksi yang dilakukan 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 kemampuan pemulihan geografis.
  • Sering merencanakan dan menjalankan latihan pemulihan bencana sehingga Anda lebih siap jika terjadi pemadaman nyata.

Menyiapkan sekunder untuk pemadaman

Untuk pemulihan yang berhasil 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. Ini umumnya adalah server di wilayah yang dipasangkan untuk wilayah tempat database utama Anda berada. Menggunakan server di wilayah yang sama menghilangkan biaya lalu lintas tambahan selama operasi 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 pendengar baca-tulis dan baca-saja dalam 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 Keamanan Azure SQL Database setelah pemulihan bencana.
  • Identifikasi aturan pemberitahuan yang perlu diperbarui untuk memetakan ke primer baru.
  • Dokumentasikan konfigurasi audit pada primer saat ini.

Konten terkait