Bagikan melalui

Replikasi Geo Aktif

Aplikasi ke:Azure SQL Database

Artikel ini memberikan gambaran umum tentang fitur replikasi geografis aktif untuk Azure SQL Database, yang memungkinkan Anda terus mereplikasi data dari database utama ke database sekunder yang dapat dibaca. Database sekunder yang dapat dibaca mungkin berada di wilayah Azure yang sama dengan yang utama, atau, lebih umum, di wilayah yang berbeda. Database sekunder yang dapat dibaca semacam ini juga dikenal sebagai geo-sekunder atau geo-replika.

Replikasi geografis aktif diatur untuk setiap database. Untuk melakukan failover pada sekelompok database, atau jika aplikasi Anda memerlukan titik akhir koneksi yang stabil, pertimbangkan grup Failover sebagai gantinya.

Anda juga dapat memigrasikan database SQL dengan geo-replikasi aktif.

Gambaran Umum

Replikasi geografis aktif dirancang sebagai solusi kelangsungan bisnis. Replikasi geografis aktif memungkinkan Anda melakukan pemulihan bencana cepat database individual jika ada bencana regional atau pemadaman skala besar. Setelah replikasi geografis disiapkan, Anda dapat memulai geo-failover ke geo-sekunder di wilayah Azure yang berbeda. "Geo-failover" dimulai secara otomatis oleh aplikasi atau secara manual oleh pengguna.

Diagram berikut mengilustrasikan konfigurasi khas aplikasi cloud geo-redundan menggunakan Replikasi geo aktif.

Diagram replikasi geografis aktif.

Jika karena alasan apa pun database utama Anda gagal, Anda dapat memulai geo-failover ke salah satu database sekunder Anda. Ketika sekunder dipromosikan ke peran utama, semua sekunder lainnya secara otomatis ditautkan ke primer baru.

Anda dapat mengelola replikasi geografis dan memulai geo-failover menggunakan salah satu metode berikut:

Active geo-replication menggunakan teknologi Always On availability group untuk mereplikasi log transaksi yang dihasilkan pada replika utama secara asinkron ke semua replika geografis. Sementara pada titik tertentu, database sekunder mungkin sedikit di belakang database utama, data pada sekunder dijamin konsisten secara transaksional. Dengan kata lain, perubahan yang dilakukan oleh transaksi yang tidak dilakukan tidak terlihat.

Catatan

Replikasi geografis aktif mereplikasi perubahan dengan streaming log transaksi database dari replika primer ke replika sekunder. Ini tidak terkait dengan replikasi transaksional, yang mereplikasi perubahan dengan menjalankan perintah DML (INSERT, UPDATE, , DELETE) pada pelanggan.

Geo-replikasi menyediakan redundansi regional. Redundansi regional memungkinkan aplikasi untuk dengan cepat pulih dari kehilangan permanen seluruh wilayah Azure atau bagian dari suatu wilayah, yang disebabkan oleh bencana alam, kesalahan manusia yang mengerikan, atau tindakan jahat. Geo-replication RPO dapat ditemukan di Business continuity in Azure SQL Database.

Gambar berikut menunjukkan contoh replikasi geografis aktif yang dikonfigurasi dengan primer di wilayah US Barat 2 dan geo-sekunder di wilayah AS Timur.

Cuplikan layar Portal Azure menampilkan hubungan geo-replikasi SQL DB.

Selain sebagai pemulihan bencana, geo-replikasi aktif dapat digunakan dalam skenario berikut:

  • Migrasi database: Anda dapat menggunakan replikasi geografis aktif untuk memigrasikan database dari satu server ke server lain secara online dengan waktu henti minimum.
  • Peningkatan aplikasi: Anda dapat membuat salinan sekunder tambahan sebagai salinan pemulihan selama peningkatan aplikasi.

Untuk mencapai kelangsungan bisnis penuh, menambahkan redundansi regional database hanyalah bagian dari solusi. Memulihkan aplikasi (layanan) secara ujung-ke-ujung setelah kegagalan besar membutuhkan pemulihan semua komponen yang membentuk layanan dan layanan yang bergantung. Contoh komponen ini termasuk perangkat lunak klien (misalnya, browser dengan JavaScript khusus), front end web, penyimpanan, dan DNS. Sangat penting bahwa semua komponen tahan terhadap kegagalan yang sama dan tersedia dalam tujuan waktu pemulihan (RTO) aplikasi Anda. Oleh karena itu, Anda perlu mengidentifikasi semua layanan yang bergantung dan memahami jaminan dan kemampuan yang diberikan layanan tersebut. Kemudian, Anda harus mengambil langkah-langkah yang memadai untuk memastikan bahwa layanan Anda berfungsi selama failover layanan yang bergantung padanya. Untuk informasi selengkapnya tentang merancang solusi untuk pemulihan bencana, lihat Desain layanan yang tersedia secara global menggunakan Azure SQL Database.

Terminologi dan kemampuan

  • Replikasi asinkron otomatis: Anda hanya dapat membuat geo-sekunder untuk database yang ada. Geo-secondary dapat dibuat pada server logis mana pun, selain dari server dengan database utama. Setelah dibuat, replika geo-sekunder diisi dengan data database primer. Proses ini dikenal sebagai penyemaian. Setelah geo-sekunder telah dibuat dan diseeding, pembaruan pada database primer secara otomatis dan asinkron direplikasi ke replika geo-sekunder. Replikasi asinkron berarti bahwa transaksi dilakukan pada database utama sebelum direplikasi.

  • Replika geo-sekunder yang dapat dibaca: Aplikasi dapat mengakses replika geo-sekunder untuk menjalankan kueri baca-saja menggunakan prinsip keamanan yang sama atau berbeda yang digunakan untuk mengakses database utama. Untuk informasi lebih lanjut, lihat Menggunakan replika baca-saja untuk mengalihkan beban kerja kueri baca-saja.

Penting

Anda dapat menggunakan replikasi geo untuk membuat database sekunder di wilayah yang sama dengan database utama. Anda dapat menggunakan sekunder ini untuk memenuhi skenario baca peluasan skala di wilayah yang sama. Namun, replika sekunder di wilayah yang sama tidak memberikan ketahanan tambahan terhadap kegagalan bencana atau pemadaman skala besar, dan karena itu bukan target failover yang cocok untuk tujuan pemulihan bencana. Ini juga tidak akan menjamin isolasi zona ketersediaan. Gunakan tingkat layanan bisnis penting atau Premium dengan konfigurasi redundan zona atau konfigurasi redundan zona tingkat layanan Tujuan Umum untuk mencapai isolasi zona ketersediaan.

  • Failover (tidak ada kehilangan data): Ketika Failover (tidak ada kehilangan data) dimulai, langkah sinkronisasi data lengkap selesai sebelum mengalihkan peran database primer dan geo-sekunder. Ini memastikan tidak ada kehilangan data. Durasi failover tergantung pada ukuran log transaksi pada primer yang perlu disinkronkan ke geo-sekunder. Failover dirancang untuk skenario berikut:

    • Lakukan latihan DR dalam produksi saat kehilangan data tidak dapat diterima
    • Merelokasi database ke wilayah lain
    • Mengembalikan database ke wilayah utama setelah pemulihan dari pemadaman (dikenal sebagai failback).

  • Failover paksa (potensi kehilangan data): Failover paksa segera mengalihkan geo-sekunder ke peran utama tanpa menunggu sinkronisasi dengan primer. Semua transaksi yang dilakukan pada primer tetapi tidak direplikasi ke sekunder akan hilang. Operasi ini dirancang sebagai metode pemulihan selama pemadaman ketika primer tidak dapat diakses, tetapi ketersediaan database harus dipulihkan dengan cepat. Ketika primer asli kembali online, sistem tersebut secara otomatis terhubung kembali, disinkronkan ulang menggunakan data terkini dari primer, dan menjadi geo-sekunder baru.

Penting

Setelah failover atau failover paksa, endpoint koneksi untuk primary baru berubah karena primary baru kini terletak di server logis yang berbeda.

  • Beberapa geo-sekunder yang dapat dibaca: Hingga empat geo-sekunder dapat dibuat untuk primer. Jika hanya ada satu replika, dan jika itu gagal, aplikasi akan menghadapi risiko yang lebih besar sampai replika baru dibuat. Jika beberapa sekunder ada, aplikasi tetap dilindungi bahkan jika salah satu sekunder gagal. Server sekunder tambahan juga dapat digunakan untuk memperluas skala beban kerja untuk baca-saja.

Petunjuk / Saran

Jika Anda menggunakan replikasi geo aktif untuk membangun aplikasi yang didistribusikan secara global dan perlu menyediakan akses baca-saja ke data di lebih dari empat wilayah, Anda dapat membuat sekunder dari sekunder (proses yang dikenal sebagai perangkaian untuk membuat geo-replika tambahan). Lag replikasi pada replika geografis berantai mungkin lebih tinggi daripada pada replika geografis yang terhubung langsung ke primer. Menyiapkan topologi replikasi geografis berantai hanya didukung secara terprogram, dan bukan dari portal Azure.

  • Replikasi geografis database dalam kumpulan elastis: Setiap database sekunder secara geografis dapat menjadi database tunggal atau bagian dari kumpulan elastis. Pilihan kumpulan elastis untuk setiap database geo-sekunder terpisah dan tidak bergantung pada konfigurasi replika lain dalam topologi (baik primer atau sekunder). Setiap kumpulan elastis terkandung dalam satu server logis. Karena nama database pada server logis harus unik, beberapa geo-sekunder dari primer yang sama tidak pernah dapat berbagi kumpulan elastis.

  • Geo-failover dan failback yang dikontrol pengguna: Geo-sekunder yang telah menyelesaikan penyemaian awal dapat secara eksplisit dialihkan ke peran utama (failover) kapan saja oleh aplikasi atau pengguna. Selama pemadaman di mana primer tidak dapat diakses, hanya failover paksa yang dapat digunakan, yang segera mempromosikan geo-sekunder menjadi primer baru. Ketika pemadaman sistem berkurang, sistem secara otomatis mengubah primer yang telah pulih menjadi geo-sekunder, dan memperbaruinya dengan primer yang baru. Karena sifat replikasi geografis asinkron, transaksi terbaru mungkin hilang selama terjadinya failover paksa jika sistem utama gagal sebelum transaksi ini direplikasi ke sekunder geografis. Ketika primer dengan beberapa sekunder gagal, sistem secara otomatis mengonfigurasi ulang hubungan replikasi dan menghubungkan sekunder yang tersisa ke primer yang baru dipromosikan tanpa memerlukan intervensi pengguna. Setelah pemadaman yang menyebabkan geo-failover dimitigasi, sebaiknya mengembalikan server utama ke wilayah aslinya. Untuk melakukan itu, lakukan failover manual.

  • Replika siaga: Jika replika sekunder Anda hanya digunakan untuk pemulihan bencana (DR) dan tidak memiliki beban kerja baca atau tulis, Anda dapat menunjuk replika sebagai siaga untuk menghemat biaya lisensi.

Persiapkan untuk failover geografis

Untuk memastikan bahwa aplikasi Anda dapat langsung mengakses server utama baru setelah terjadi geo-failover, pastikan bahwa autentikasi dan akses jaringan untuk server sekunder Anda dikonfigurasi dengan benar. Untuk detailnya, lihat Konfigurasi dan kelola keamanan Azure SQL Database untuk pemulihan geografis atau failover. Juga memvalidasi bahwa kebijakan retensi cadangan pada database sekunder cocok dengan yang utama. Pengaturan ini bukan bagian dari database dan tidak direplikasi dari primer. Secara default, geo-sekunder dikonfigurasi dengan periode retensi PITR selama tujuh hari. Untuk informasi selengkapnya, lihat pencadangan otomatis di Azure SQL Database.

Penting

Jika basis data Anda adalah anggota grup failover, Anda tidak dapat memulai failover menggunakan perintah failover replikasi geo. Gunakan perintah failover untuk grup. Jika Anda perlu melakukan failover pada database individual, Anda harus menghapusnya terlebih dahulu dari grup failover. Lihat ikhtisar grup Failover & praktik terbaik (Azure SQL Database) untuk informasi lebih lanjut.

Mengonfigurasi geo-secondary

Baik primer maupun geo-sekunder diperlukan untuk memiliki tingkat layanan yang sama. Sangat disarankan bahwa geo-sekunder juga dikonfigurasi dengan redundansi penyimpanan cadangan yang sama, lapisan komputasi yang sama (disediakan atau tanpa server) dan ukuran komputasi (DTU atau vCores) seperti konfigurasi utama. Jika primer mengalami beban kerja tulis yang berat, geo-sekunder dengan ukuran komputasi yang lebih rendah mungkin tidak dapat mengikuti. Hal tersebut menyebabkan lag replikasi pada server geo-sekunder, dan pada akhirnya dapat menyebabkan ketidaktersediaan server geo-sekunder. Untuk mengurangi risiko ini, replikasi geografis aktif membatasi kecepatan log transaksi utama jika diperlukan untuk memungkinkan server sekunder mengejar ketinggalan.

Konsekuensi lain dari konfigurasi geo-sekunder yang tidak seimbang adalah bahwa setelah failover, performa aplikasi dapat menderita karena kapasitas komputasi yang tidak mencukup dari primer baru. Dalam hal ini, perlu untuk meningkatkan database agar memiliki sumber daya yang memadai, yang mungkin memerlukan waktu yang cukup lama, dan memerlukan failover ketersediaan tinggi pada akhir proses peningkatan skala, yang dapat mengganggu beban kerja aplikasi.

Petunjuk / Saran

Untuk panduan pemecahan masalah terperinci tentang lag pada replikasi geografis, lihat Pemecahan masalah lag redo replikasi geografis.

Jika Anda memutuskan untuk membuat geo-sekunder dengan konfigurasi yang berbeda, Anda harus memantau laju I/O log pada primer dari waktu ke waktu. Ini memungkinkan Anda memperkirakan ukuran komputasi minimal geo-sekunder yang diperlukan untuk mempertahankan beban replikasi. Misalnya, jika database utama Anda adalah P6 (1000 DTU) dan I/O lognya dipertahankan pada 50%, geo-sekunder harus setidaknya P4 (500 DTU). Untuk mengambil data I/O log historis, gunakan tampilan sys.resource_stats . Untuk mengambil data I/O log terbaru dengan granularitas yang lebih tinggi yang lebih mencerminkan lonjakan jangka pendek, gunakan tampilan sys.dm_db_resource_stats .

Petunjuk / Saran

Pembatasan I/O log transaksi dapat terjadi dalam skenario berikut:

  • Jika geo-sekunder berada pada ukuran komputasi yang lebih rendah dari yang utama. Cari jenis tunggu HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO dalam tampilan database sys.dm_exec_requests dan sys.dm_os_wait_stats.
  • Pembatasan juga dapat terjadi karena alasan yang tidak terkait dengan ukuran komputasi, misalnya saat beban kerja berat untuk penyisipan massal, SELECT INTO, dan pembangunan indeks. Untuk informasi selengkapnya tentang jenis tunggu untuk berbagai jenis pembatasan I/O log, lihat Tata kelola laju log transaksi.

Secara default, redundansi penyimpanan cadangan sekunder sama dengan database utama. Anda dapat memilih untuk mengonfigurasi geo-sekunder dengan redundansi penyimpanan cadangan yang berbeda. Pencadangan selalu diambil pada database utama. Jika sekunder dikonfigurasi dengan redundansi penyimpanan cadangan yang berbeda, maka setelah geo-failover, ketika geo-sekunder dipromosikan ke primer, cadangan baru akan disimpan dan ditagih sesuai dengan jenis penyimpanan (RA-GRS, ZRS, LRS) yang dipilih pada primer baru (sekunder sebelumnya).

Menghemat biaya dengan replika siaga

Jika replika sekunder Anda hanya digunakan untuk pemulihan bencana (DR) dan tidak memiliki beban kerja baca atau tulis, Anda dapat menghemat biaya lisensi dengan menunjuk database untuk siaga saat Anda mengonfigurasi hubungan geo-replikasi aktif baru.

Tinjau replika cadangan bebas lisensi untuk mempelajari lebih lanjut.

Replikasi geo lintas langganan

  • Anda dapat menggunakan portal Azure untuk menyiapkan replikasi geoaktif di seluruh langganan selama kedua langganan berada di penyewa Microsoft Entra yang sama.

    • Untuk membuat replika geo-sekunder dalam langganan yang berbeda dari langganan utama di penyewa Microsoft Entra yang berbeda, gunakan autentikasi SQL dan T-SQL. autentikasi Microsoft Entra untuk Azure SQL untuk replikasi geografis lintas langganan tidak didukung saat server logis berada di penyewa Azure yang berbeda
    • Operasi replikasi geografis lintas langganan, termasuk penyiapan dan geo-failover, juga didukung menggunakan Membuat atau Memperbarui Database-Database REST API.

  • Membuat geo-sekunder lintas-syarat berlangganan pada server logis di penyewa Microsoft Entra yang sama atau berbeda tidak didukung saat autentikasi Microsoft Entra-saja dengan Azure SQL diaktifkan di server logis primer atau sekunder dan pembuatan dicoba menggunakan pengguna Microsoft Entra ID.

Untuk metode dan instruksi langkah demi langkah, lihat Tutorial: Mengonfigurasi replikasi geografis aktif dan failover (Azure SQL Database).

Titik Akhir Privat

Menambahkan geo-sekunder menggunakan T-SQL tidak didukung ketika terhubung ke server utama melalui titik akhir privat.

Jika titik akhir privat dikonfigurasi tetapi akses jaringan publik diizinkan, penambahan lokasi sekunder secara geografis didukung ketika tersambung ke server utama dari alamat IP publik.

Setelah geo-sekunder ditambahkan, akses jaringan publik dapat ditolak.

Tetap sinkronkan info masuk dan aturan firewall

Saat menggunakan akses jaringan publik untuk terhubung ke database, kami sarankan menggunakan aturan firewall IP tingkat database untuk database yang direplikasi secara geografis. Aturan-aturan ini direplikasi dengan database, yang memastikan bahwa semua geo-sekunder memiliki aturan firewall IP yang sama dengan yang utama. Pendekatan ini menghilangkan kebutuhan pelanggan untuk mengonfigurasi dan memelihara aturan firewall secara manual pada server yang meng-hosting database primer dan sekunder. Demikian pula, menggunakan pengguna database yang terkandung untuk akses data memastikan database primer dan sekunder selalu memiliki kredensial autentikasi yang sama. Dengan cara ini, setelah geo-failover, tidak ada gangguan karena ketidakcocokan kredensial autentikasi. Jika Anda menggunakan login dan pengguna (bukan pengguna terkontain), Anda harus melakukan langkah tambahan untuk memastikan bahwa login yang sama ada di database sekunder Anda. Untuk detail konfigurasi, lihat Konfigurasi dan kelola keamanan Azure SQL Database untuk pemulihan geografis atau failover.

Menskalakan database utama

Anda dapat meningkatkan atau menurunkan basis data utama ke ukuran komputasi yang berbeda (dalam tingkat layanan yang sama) tanpa memutuskan geo-sekunder. Saat meningkatkan skala, kami sarankan Anda meningkatkan skala geo-sekunder lebih dulu, dan kemudian meningkatkan skala primer. Ketika mengurangi skala, lakukan dengan urutan terbalik: kurangi skala primer terlebih dahulu, dan kemudian kurangi skala sekunder.

Untuk informasi tentang grup failover, tinjau menskalakan replika dalam grup failover.

Mencegah hilangnya data penting

Dikarenakan latensi jaringan area luas yang tinggi, replikasi geo menggunakan mekanisme replikasi asinkron. Replikasi asinkron membuat kemungkinan kehilangan data tidak dapat dihindari jika primer gagal. Untuk melindungi transaksi kritis dari kehilangan data, pengembang aplikasi dapat 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 tercatat telah dikirim dan diperkuat dalam log transaksi database sekunder. Ini juga menunggu transaksi yang dikirimkan untuk diproses ulang (redone) pada sistem sekunder. Prosedur sistem yang disimpan sp_wait_for_database_copy_sync dibatasi pada tautan replikasi geografis tertentu. Setiap pengguna dengan hak koneksi ke database utama dapat memanggil prosedur ini.

Catatan

sp_wait_for_database_copy_sync mencegah kehilangan data setelah geo-failover untuk transaksi tertentu, tetapi tidak menjamin sinkronisasi penuh untuk akses baca. Keterlambatan yang disebabkan oleh panggilan sp_wait_for_database_copy_sync prosedur dapat menjadi signifikan dan bergantung pada ukuran log transaksi yang belum ditransmisikan di server utama pada saat panggilan.

Memantau keterlambatan replikasi geografis

Untuk memantau jeda sehubungan dengan RPO, gunakan replication_lag_sec kolom sys.dm_geo_replication_link_status pada database utama. Ini menunjukkan jeda dalam hitungan detik antara transaksi yang dikonfirmasi pada primer, dan ditulis ke log transaksi pada sekunder. Misalnya, jika jeda adalah satu detik, itu berarti bahwa jika primer dipengaruhi oleh pemadaman saat ini dan geo-failover dimulai, transaksi yang dilakukan pada detik terakhir akan hilang.

Untuk mengukur keterlambatan sehubungan dengan perubahan pada database utama yang telah diterapkan pada basis data sekunder geografis, bandingkan last_commit waktu pada basis data sekunder geografis dengan nilai yang sama pada database utama.

Petunjuk / Saran

Jika replication_lag_sec pada primer adalah NULL, berarti primer saat ini tidak tahu seberapa jauh di belakang geo-sekunder. Ini biasanya terjadi setelah proses dimulai ulang dan harus menjadi kondisi sementara. Pertimbangkan untuk mengirim pemberitahuan jika replication_lag_sec mengembalikan NULL untuk jangka waktu yang lama. Ini mungkin menunjukkan bahwa geo-sekunder tidak dapat berkomunikasi dengan primer karena kegagalan konektivitas.

Ada juga kondisi yang dapat menyebabkan perbedaan antara last_commit waktu pada geo-sekunder dan primer menjadi lebih besar. Sebagai contoh, jika commit dilakukan pada server utama setelah periode panjang tanpa perubahan, perbedaannya akan melonjak ke nilai besar sebelum dengan cepat kembali ke nol. Pertimbangkan untuk mengirim peringatan jika perbedaan antara kedua nilai ini tetap besar untuk waktu yang lama.

Secara terprogram mengelola replikasi geografis aktif

Replikasi geografis aktif juga dapat dikelola secara terprogram menggunakan T-SQL, Azure PowerShell, dan REST API. Tabel berikut ini menjelaskan kumpulan perintah yang tersedia. Replikasi geografis aktif mencakup sekumpulan API Azure Resource Manager untuk manajemen, termasuk Azure SQL Database REST API dan cmdlet Azure PowerShell. API ini mendukung Azure kontrol akses berbasis peran (Azure RBAC). Untuk informasi selengkapnya tentang cara menerapkan peran akses, lihat Azure kontrol akses berbasis peran (Azure RBAC).

Penting

Perintah T-SQL ini hanya berlaku untuk replikasi geografis aktif dan tidak berlaku untuk grup failover.

Perintah Deskripsi
UBAH DATABASE Gunakan ADD SECONDARY ON SERVER argumen untuk membuat database sekunder untuk database yang sudah ada dan memulai replikasi data
UBAH DATABASE Menggunakan FAILOVER atau FORCE_FAILOVER_ALLOW_DATA_LOSS untuk mengalihkan database sekunder menjadi primer untuk memulai failover
UBAH DATABASE Gunakan REMOVE SECONDARY ON SERVER untuk mengakhiri replikasi data antara SQL Database dan database sekunder yang ditentukan.
sys.geo_replication_links Mengembalikan informasi tentang semua link replikasi yang ada untuk setiap database di server.
sys.dm_geo_replication_link_status Mendapatkan waktu replikasi terakhir, jeda replikasi terakhir, dan informasi lain tentang tautan replikasi untuk database tertentu.
sys.dm_operation_status Memperlihatkan status untuk semua operasi database termasuk perubahan pada tautan replikasi.
sys.sp_wait_for_database_copy_sync Mengakibatkan aplikasi harus menunggu hingga semua transaksi yang sudah dikomit dipastikan tetap pada log transaksi geografis sekunder.

Troubleshooting

Untuk informasi selengkapnya tentang pemecahan masalah jeda geo-replika, lihat Memecahkan masalah jeda replikasi geografis.

Konten terkait

Mengonfigurasi replikasi geografis aktif:

Konten kelangsungan bisnis lainnya:

  • Last updated on