Bagikan melalui


Panduan pemulihan bencana - Azure SQL Database

Berlaku untuk: Azure SQL Database

Azure SQL Database menyediakan jaminan ketersediaan tinggi terkemuka di industri setidaknya 99,99% untuk mendukung berbagai aplikasi, termasuk misi penting, yang selalu perlu tersedia. Azure SQL Database juga memiliki kemampuan kelangsungan bisnis utama yang dapat Anda lakukan untuk pemulihan bencana cepat jika terjadi pemadaman regional. Artikel ini berisi informasi berharga untuk ditinjau sebelum penyebaran aplikasi.

Meskipun kami terus berusaha untuk memberikan ketersediaan tinggi, ada kalanya layanan Azure SQL Database menimbulkan pemadaman yang menyebabkan tidak tersedianya database Anda dan dengan demikian berdampak pada aplikasi Anda. Ketika pemantauan layanan kami mendeteksi masalah yang menyebabkan kesalahan konektivitas, kegagalan, atau masalah performa yang luas, layanan secara otomatis menyatakan pemadaman agar Anda mendapatkan informasi.

Pemadaman layanan

Jika terjadi pemadaman layanan Azure SQL Database, Anda dapat menemukan detail tambahan yang terkait dengan pemadaman di tempat-tempat berikut:

  • banner portal Azure

    Jika langganan Anda diidentifikasi terpengaruh, ada pemberitahuan pemadaman tentang Masalah Layanan di Pemberitahuan portal Azure Anda:

    Cuplikan layar dari portal Azure pemberitahuan masalah layanan Azure SQL Database.

  • Bantuan + dukungan atau Dukungan + pemecahan masalah

    Saat Anda membuat tiket dukungan dari Bantuan + dukungan atau Dukungan + pemecahan masalah, ada informasi tentang masalah apa pun yang memengaruhi sumber daya Anda. Pilih Tampilkan detail pemadaman untuk informasi selengkapnya dan ringkasan dampak. Ada juga pemberitahuan di halaman Permintaan dukungan baru.

    Cuplikan layar halaman Bantuan+Dukungan memperlihatkan pemberitahuan masalah kesehatan layanan aktif.

  • Kesehatan layanan

    Halaman Service Health di portal Azure berisi informasi tentang status pusat data Azure secara global. Cari 'kesehatan layanan'' di bilah pencarian di portal Azure, lalu lihat Masalah layanan dalam kategori Peristiwa aktif. Anda juga dapat melihat kesehatan sumber daya individual di halaman Kesehatan sumber daya dari sumber daya apa pun di bawah menu Bantuan . Berikut ini adalah cuplikan layar sampel halaman Service Health , dengan informasi tentang masalah layanan aktif di Asia Tenggara:

    Cuplikan layar halaman portal Azure Service Health selama masalah layanan di Asia Tenggara, memperlihatkan Masalah dan peta sumber daya yang terpengaruh.

  • Pemberitahuan email

    Jika Anda telah menyiapkan pemberitahuan, pemberitahuan email dikirim dari azure-noreply@microsoft.com saat pemadaman layanan memengaruhi langganan dan sumber daya Anda. Isi email biasanya dimulai dengan "Pemberitahuan log aktivitas ... dipicu oleh masalah layanan untuk langganan Azure...". Untuk informasi selengkapnya tentang pemberitahuan kesehatan layanan, lihat Menerima pemberitahuan log aktivitas di pemberitahuan layanan Azure menggunakan portal Azure.

  • Metrik ketersediaan

    Anda dapat memantau dan mengonfigurasi pemberitahuan metrik Ketersediaan Azure SQL Database di portal Azure.

Kapan memulai pemulihan bencana selama pemadaman

Jika terjadi pemadaman layanan yang memengaruhi sumber daya aplikasi, pertimbangkan kursus tindakan berikut:

  • Tim Azure bekerja dengan rajin untuk memulihkan ketersediaan layanan secepat mungkin tetapi tergantung pada akar penyebabnya terkadang dapat memakan waktu berjam-jam. Jika aplikasi Anda dapat mentolerir waktu henti yang signifikan, Anda cukup menunggu pemulihan selesai. Dalam hal ini, Anda tidak perlu melakukan tindakan apa pun. Lihat kesehatan sumber daya individual di halaman Kesehatan sumber daya sumber daya apa pun di bawah menu Bantuan . Lihat halaman Kesehatan sumber daya untuk pembaruan dan informasi terbaru mengenai pemadaman. Setelah pemulihan wilayah tersebut, ketersediaan aplikasi Anda telah dipulihkan.

  • Pemulihan ke wilayah Azure lain dapat memerlukan perubahan string koneksi aplikasi atau menggunakan pengalihan DNS, dan mungkin mengakibatkan kehilangan data permanen. Oleh karena itu, pemulihan bencana harus dilakukan hanya ketika durasi pemadaman mendekati tujuan waktu pemulihan (RTO) aplikasi Anda. Ketika aplikasi disebarkan ke produksi, Anda harus melakukan pemantauan rutin kesehatan aplikasi dan menegaskan bahwa pemulihan hanya dijaga ketika ada kegagalan konektivitas yang berkepanjangan dari tingkat aplikasi ke database. Bergantung pada toleransi aplikasi Anda terhadap waktu henti dan kemungkinan tanggung jawab bisnis, Anda dapat memutuskan apakah Anda ingin menunggu layanan memulihkan atau memulai pemulihan bencana sendiri.

Panduan pemulihan pemadaman

Jika pemadaman Azure SQL Database di suatu wilayah belum dimitigasi untuk jangka waktu yang lama dan memengaruhi perjanjian tingkat layanan (SLA) aplikasi Anda, pertimbangkan langkah-langkah berikut:

Failover (tidak ada kehilangan data) ke server sekunder yang direplikasi secara geografis

Jika replikasi geografis aktif atau grup failover diaktifkan, periksa apakah status sumber daya database primer dan sekunder online di portal Azure. Jika demikian, bidang data untuk database primer dan sekunder sehat. Mulai failover grup replikasi geografis aktif atau failover ke wilayah sekunder dengan menggunakan portal Azure, T-SQL, PowerShell, atau Azure CLI.

Catatan

Failover memerlukan sinkronisasi data penuh sebelum beralih peran dan tidak mengakibatkan kehilangan data. Tergantung pada jenis pemadaman layanan tidak ada jaminan bahwa failover tanpa kehilangan data akan berhasil, tetapi ada baiknya mencoba sebagai opsi pemulihan pertama.

Untuk memulai failover, gunakan tautan berikut:

Teknologi Metode Langkah-langkah
Replikasi-Geo Aktif PowerShell Failover ke replikasi geografis sekunder melalui PowerShell
T-SQL Failover ke replikasi geografis sekunder melalui T-SQL
Grup kegagalan Azure CLI Failover ke server sekunder melalui Azure CLI
Portal Azure Failover ke server sekunder melalui portal Azure
PowerShell Failover ke server sekunder melalui PowerShell

Failover paksa (potensi kehilangan data) ke server sekunder yang direplikasi secara geografis

Jika failover tidak selesai dengan baik dan mengalami kesalahan, atau jika status database utama tidak Online, pertimbangkan failover paksa dengan potensi kehilangan data ke wilayah sekunder.

Untuk memulai failover paksa, gunakan tautan berikut:

Teknologi Metode Langkah-langkah
Replikasi-Geo Aktif Azure CLI Failover paksa ke replikasi geografis sekunder melalui Azure CLI
Portal Azure Failover paksa ke replikasi geografis sekunder melalui portal Azure
PowerShell Failover paksa ke replikasi geografis sekunder melalui PowerShell
T-SQL Failover paksa ke replikasi geografis sekunder melalui T-SQL
Grup kegagalan Portal Azure Failover paksa ke server sekunder melalui portal Azure tetapi pilih Failover Paksa.
Azure CLI Failover paksa ke server sekunder melalui Azure CLI tetapi gunakan --allow-data-loss
PowerShell Failover paksa ke server sekunder melalui PowerShell tetapi gunakan -AllowDataLoss

Pemulihan Geo

Jika Anda belum mengaktifkan replikasi geografis aktif atau grup failover, maka sebagai upaya terakhir, Anda dapat menggunakan pemulihan geografis untuk memulihkan dari pemadaman. Pemulihan geografis menggunakan cadangan yang direplikasi secara geografis sebagai sumbernya. Anda dapat memulihkan database di server logis apa pun di wilayah Azure mana pun dari cadangan geo-replikasi terbaru. Anda dapat meminta pemulihan geografis meskipun pemadaman telah membuat database atau seluruh wilayah tidak dapat diakses.

Untuk informasi selengkapnya tentang pemulihan geografis melalui Azure CLI, portal Azure, PowerShell, atau REST API, lihat pemulihan geografis Azure SQL Database.

Konfigurasikan database Anda setelah pemulihan

Jika Anda menggunakan geo-failover atau pemulihan geografis untuk memulihkan dari pemadaman, Anda harus memastikan bahwa konektivitas ke database baru dikonfigurasi dengan benar sehingga fungsi aplikasi normal dapat dilanjutkan. Ini adalah daftar periksa tugas untuk menyiapkan produksi database Anda yang telah dipulihkan.

Penting

Disarankan untuk melakukan latihan berkala dari strategi pemulihan bencana Anda untuk memverifikasi toleransi aplikasi, serta semua aspek operasional prosedur pemulihan. Lapisan lain infrastruktur aplikasi Anda mungkin memerlukan konfigurasi ulang. Untuk informasi selengkapnya tentang langkah-langkah arsitektur tangguh, tinjau daftar periksa ketersediaan tinggi dan pemulihan bencana Azure SQL Database.

Perbarui string koneksi

  • Jika Anda menggunakan replikasi geografis aktif atau pemulihan geografis, Anda harus memastikan bahwa konektivitas ke database baru dikonfigurasi dengan benar sehingga fungsi aplikasi normal dapat dilanjutkan. Karena database Anda yang dipulihkan berada di server yang berbeda, Anda perlu memperbarui string koneksi aplikasi Anda untuk mengarahkan ke server tersebut. Untuk informasi selengkapnya tentang mengubah string koneksi, lihat bahasa komputer pengembangan yang sesuai untuk pustaka koneksi.
  • Jika Anda menggunakan grup failover untuk memulihkan dari pemadaman dan menggunakan pendengar baca-tulis dan baca-saja di string koneksi aplikasi Anda, maka tidak ada tindakan lebih lanjut yang diperlukan karena koneksi secara otomatis diarahkan ke primer baru.

Mengonfiguraskan aturan firewall

Anda perlu memastikan bahwa aturan firewall yang dikonfigurasi di server sekunder dan database cocok dengan yang dikonfigurasi di server utama dan database utama. Untuk informasi selengkapnya, lihat Cara: Mengonfigurasi Pengaturan Firewall.

Mengonfigurasi pengguna login dan database

Buat login yang harus ada di master database di server utama baru, dan pastikan login ini memiliki izin yang sesuai dalam master database, jika ada. Untuk informasi selengkapnya, lihat keamanan setelah pemulihan bencana.

Penyiapan pemberitahuan telemetri

Anda perlu memastikan pengaturan aturan pemberitahuan yang ada diperbarui untuk memetakan ke database utama baru dan server yang berbeda. Untuk informasi selengkapnya tentang aturan pemberitahuan database, lihat Menerima Pemberitahuan Peringatan dan Melacak Azure Service Health.

Mengaktifkan pengauditan

Jika Anda memiliki audit yang dikonfigurasi di server utama, buatlah identik di server sekunder. Untuk mengetahui informasi selengkapnya, lihat Pengauditan.

Untuk mempelajari lebih lanjut, tinjau: