Bagikan melalui

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

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 tidak terlalu mengganggu.
  • Uji ketahanan kesalahan aplikasi dengan memicu failover secara manual untuk melihat ketahanan dalam tindakan.

Daftar periksa ketersediaan yang tinggi

Berikut ini adalah konfigurasi yang direkomendasikan untuk mencapai ketersediaan tinggi:

  • Aktifkan redundansi zona jika tersedia pada instans terkelola SQL untuk memastikan ketahanan terhadap kegagalan zona.

Daftar periksa pemulihan bencana

Meskipun Azure SQL Managed Instance secara otomatis mempertahankan ketersediaan, ada kejadian ketika bahkan memiliki ketersediaan tinggi (redundansi zona) mungkin tidak menjamin ketahanan karena pemadaman yang mempengaruhi 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 sebuah instans.
    • Gunakan titik akhir listener baca-tulis dan baca-saja dalam string koneksi aplikasi Anda, sehingga aplikasi dapat secara otomatis terhubung ke instans mana pun yang menjadi 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.
  • Ketika mengecilkan skala, balikkan urutannya: kecilkan skala utama terlebih dahulu, kemudian kecilkan 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 transaksi dikomit. Memanggil sp_wait_for_database_copy_sync akan memblokir thread yang memanggil hingga transaksi terakhir yang dilakukan telah dikirim dan diperkuat dalam log transaksi di database sekunder.
  • Pantau lag sehubungan dengan Tujuan Titik Pemulihan (RPO) dengan 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 sistem primer dan dimasukkan ke dalam log transaksi pada sistem sekunder. Misalnya, asumsikan jeda adalah satu detik pada suatu saat, jika sistem utama terpengaruh oleh pemadaman dan geo-failover langsung dilakukan, transaksi yang diselesaikan dalam 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.

Mempersiapkan sistem cadangan 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. 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 dalam string koneksi aplikasi, tidak ada tindakan lebih lanjut yang diperlukan - koneksi secara otomatis diarahkan ke server 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 instans utama saat ini dan membuatnya identik dengan instans sekunder.

Konten terkait

Untuk mempelajari lebih lanjut, tinjau:

  • Last updated on