Panduan pemulihan bencana - Azure SQL Database

  • Artikel

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 Anda lakukan 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:

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • 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.

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • 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:

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • 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.

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 mungkin memerlukan perubahan string koneksi aplikasi atau menggunakan pengalihan DNS, dan dapat 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 tidakOnline, 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 failover 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 dari 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 dikonfigurasikan di server dan di database cocok dengan yang dikonfigurasikan pada server utama dan database utama. Untuk informasi selengkapnya, lihat Cara mengonfigurasi pengaturan firewall (Azure SQL Database).

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 Azure SQL Database 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 pengauditan diperlukan untuk mengakses database Anda, Anda perlu mengaktifkan Pengauditan setelah pemulihan database. Untuk informasi selengkapnya, lihat Audit Azure SQL untuk Azure SQL Database.

Langkah berikutnya