Bagikan melalui

Daftar periksa ketersediaan tinggi dan pemulihan bencana - Azure SQL Managed Instance

  • Artikel

Berlaku untuk: Azure SQL Managed Instance

Layanan Azure SQL Managed Instance 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 tingkat layanan Azure SQL Managed Instance.

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 instans terkelola SQL untuk memastikan ketahanan untuk kegagalan zona.

Daftar periksa pemulihan bencana

Meskipun Azure SQL Managed Instance 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 Managed Instance regional mungkin mengharuskan Anda memulai pemulihan bencana.

Untuk mempersiapkan pemulihan bencana dengan terbaik, ikuti rekomendasi berikut:

  • Aktifkan grup failover untuk instans .
    • Gunakan titik akhir listener baca-tulis dan baca-saja di aplikasi Anda string koneksi sehingga aplikasi secara otomatis terhubung ke instans mana pun yang utama.
    • Atur kebijakan failover ke yang dikelola pelanggan.
  • Pastikan instans geo-sekunder dibuat dengan tingkat layanan, pembuatan perangkat keras, dan ukuran komputasi yang sama dengan instans 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 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

Agar berhasil memulihkan ke wilayah data lain menggunakan grup failover, atau pemulihan geografis, Anda perlu menyiapkan Azure SQL Managed Instance sekunder di wilayah lain. Instans sekunder ini dapat menjadi instans 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 instans di wilayah lain untuk menjadi instans utama baru. Ini umumnya adalah instans di wilayah yang dipasangkan untuk wilayah tempat instans utama Anda berada. Menggunakan instans di wilayah yang dipasangkan ke wilayah utama 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 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, konfigurasi NSG dan tabel rute yang diperlukan pengguna untuk mengakses database utama baru pada primer 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.
  • Dokumentasikan konfigurasi audit pada primer saat ini dan buat identik pada instans sekunder.

Konten terkait

Untuk mempelajari lebih lanjut, tinjau: