Bagikan melalui

Replikasi Geo Aktif

  • Artikel

Berlaku untuk: Azure SQL Database

Artikel ini menyediakan dan gambaran umum 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 database utama, atau, lebih umum, di wilayah yang berbeda. Database sekunder semacam ini juga dikenal sebagai geo-sekunder atau geo-replika.

Replikasi geografis aktif dikonfigurasi per 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 replikasi geografis 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 diatur, Anda dapat memulai geo-failover ke geo-sekunder di wilayah Azure yang berbeda. Geo-failover dimulai secara terprogram 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:

Replikasi geografis aktif menggunakan teknologi grup ketersediaan AlwaysOn 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).

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. RPO replikasi geografis dapat ditemukan di Gambaran Umum kelangsungan bisnis dengan 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 memperlihatkan hubungan replikasi geografis 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 sekunder tambahan sebagai salinan kembali yang gagal 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 Merancang 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-sekunder dapat dibuat pada server logis, selain 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 diunggulkan, 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 mengeksekusi kueri baca-saja menggunakan prinsip keamanan yang sama atau berbeda yang digunakan untuk mengakses basis data utama. Untuk detailnya, lihat Menggunakan replika baca-saja untuk memindahkan 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)

    Failover mengalihkan peran database primer dan geo-sekunder setelah menyelesaikan sinkronisasi data penuh sehingga 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 pemadaman dimitigasi (dikembalikan).

  • 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, primer tersebut secara otomatis terhubung kembali, disembunyikan ulang menggunakan data saat ini dari primer, dan menjadi geo-sekunder baru.

    Penting

    Setelah failover atau failover paksa, titik akhir koneksi untuk perubahan utama baru karena primer baru sekarang terletak di server logis yang berbeda.

  • Beberapa sekunder yang dapat dibaca

    Hingga empat geo-sekunder dapat dibuat untuk primer. Jika hanya ada satu sekunder, dan gagal, aplikasi terpapar risiko yang lebih tinggi sampai sekunder baru dibuat. Jika beberapa sekunder ada, aplikasi tetap dilindungi bahkan jika salah satu sekunder gagal. Sekunder tambahan juga dapat digunakan untuk memperluas skala beban kerja baca-saja

    Tip

    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 geo-replikasi yang dirangkai hanya didukung secara terprogram, dan bukan dari portal Azure.

  • Geo-replikasi database dalam kumpulan elastis

    Setiap geo-sekunder dapat berupa database tunggal atau database dalam 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

    Sebuah geo-sekunder yang telah selesai penyemaian awal dapat secara eksplisit beralih ke peran utama (gagal) setiap saat 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 dikurangi, sistem secara otomatis membuat primer pulih geo-sekunder, dan memperbaruinya dengan primer baru. Karena sifat replikasi geografis asinkron, transaksi terbaru mungkin hilang selama failover paksa jika primer gagal sebelum transaksi ini direplikasi ke geo-sekunder. 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, mungkin diinginkan untuk mengembalikan primer 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.

Bersiaplah untuk failover geografis

Untuk memastikan bahwa aplikasi Anda dapat segera mengakses primer baru setelah geo-failover, validasi bahwa autentikasi dan akses jaringan untuk server sekunder Anda dikonfigurasi dengan benar. Untuk detailnya, lihat Mengonfigurasi dan mengelola 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, sekunder akan dikonfigurasi dengan periode retensi PITR default selama tujuh hari. Untuk informasi selengkapnya, lihat Pencadangan otomatis di Azure SQL Database.

Penting

Jika database Anda adalah anggota grup kegagalan, Anda tidak dapat memulai kegagalan menggunakan perintah kegagalan replikasi geo. Gunakan perintah kegagalan untuk grup. Jika Anda perlu kegagalan database individual, Anda harus menghapusnya dari grup kegagalan terlebih dahulu. Lihat Grup failover untuk detailnya.

Mengonfigurasi geo-sekunder

Baik primer maupun geo-sekunder diperlukan untuk memiliki tingkat layanan yang sama. Sangat disarankan juga bahwa geo-sekunder dikonfigurasi dengan redundansi penyimpanan cadangan, tingkat komputasi yang sama (disediakan atau tanpa server) dan ukuran komputasi (DTU atau vCore) sebagai yang utama. Jika primer mengalami beban kerja tulis yang berat, geo-sekunder dengan ukuran komputasi yang lebih rendah mungkin tidak dapat mengikuti. Itu menyebabkan lag replikasi pada geo-sekunder, dan akhirnya dapat menyebabkan tidak tersedianya geo-sekunder. Untuk mengurangi risiko ini, replikasi geografis aktif mengurangi (pembatasan) laju log transaksi utama jika perlu untuk memungkinkan sekundernya 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 membutuhkan waktu yang signifikan, dan memerlukan failover ketersediaan tinggi di akhir proses peningkatan skala, yang dapat mengganggu beban kerja aplikasi.

Jika Anda memutuskan untuk membuat geo-sekunder dengan konfigurasi yang berbeda, Anda harus memantau laju IO 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 log IO-nya dipertahankan sebanyak 50%, geo-sekunder harus minimal P4 (500 DTU). Untuk mengambil data IO log historis, gunakan tampilan sys.resource_stats. Untuk mengambil data tulis log terbaru dengan granularitas yang lebih tinggi yang lebih mencerminkan lonjakan jangka pendek dalam laju log, gunakan tampilan sys.dm_db_resource_stats.

Tip

Pembatasan IO log transaksi dapat terjadi:

Secara default, redundansi penyimpanan cadangan sekunder sama dengan database utama. Anda dapat memilih untuk mengonfigurasi 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 siaga bebas lisensi untuk mempelajari lebih lanjut.

Replikasi geo lintas langganan

  • Anda dapat menggunakan portal Azure untuk menyiapkan replikasi geo aktif 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 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 Database Buat atau Perbarui REST API.

  • Membuat geo-sekunder lintas langganan di server logis di penyewa Microsoft Entra yang sama atau berbeda tidak didukung saat autentikasi khusus Microsoft Entra diaktifkan di server logika primer atau sekunder dan pembuatan dicoba menggunakan pengguna ID Microsoft Entra.

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 saat tersambung ke server utama melalui titik akhir privat.

  • Jika titik akhir privat dikonfigurasi tetapi akses jaringan publik diizinkan, penambahan geo-sekunder ketika tersambung ke server utama dari alamat IP publik didukung.
  • 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 mandiri), Anda harus mengambil langkah tambahan untuk memastikan bahwa login yang sama ada untuk database sekunder Anda. Untuk detail konfigurasi, lihat Mengonfigurasi dan mengelola keamanan Azure SQL Database untuk pemulihan geografis atau failover.

Skala 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, kami sarankan Anda meningkatkan geo-sekunder terlebih dahulu, dan kemudian meningkatkan primer. Saat menskalakan, balikkan urutan: skala bawah primer pertama, dan kemudian skala bawah sekunder.

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

Mencegah hilangnya data penting

Dikarenakan latensi jaringan area luas yang tinggi, salinan berkelanjutan menggunakan mekanisme replikasi asinkron. Replikasi asinkron membuat kemungkinan kehilangan data tidak dapat dihindari jika primer gagal. Untuk melindungi pembaruan penting ini, pengembang aplikasi dapat memanggil prosedur sistem 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. Namun, tidak menunggu transaksi yang dikirimkan diputar ulang (redone) pada sekunder. sp_wait_for_database_copy_sync dicakup ke tautan geo-replikasi 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 pada saat panggilan.

Memantau lag replikasi geo

Untuk memantau lag sehubungan dengan RPO, gunakan kolom replication_lag_sec dari sys.dm_geo_replication_link_status di database utama. Ini menunjukkan jeda dalam hitungan detik antara transaksi yang dilakukan pada primer, dan mengeras 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 lag sehubungan dengan perubahan pada database utama yang telah diperkuat pada geo-sekunder, bandingkan last_commit waktu pada geo-sekunder dengan nilai yang sama pada primer.

Tip

Terkadang replication_lag_sec pada database utama memiliki nilai NULL, yang berarti bahwa primer saat ini tidak tahu seberapa jauh sekunder. Ini biasanya terjadi setelah proses dimulai ulang dan harus menjadi kondisi sementara. Pertimbangkan untuk memberi tahu aplikasi 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 waktu last_commit pada sekunder dan pada database utama menjadi besar. jika komit dilakukan pada primer setelah periode panjang tanpa perubahan, perbedaannya akan melompat ke nilai besar sebelum dengan cepat kembali ke 0. 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 geo aktif mencakup set API Azure Resource Manager untuk pengelolaan, termasuk REST API Azure SQL Database dan cmdlet Azure PowerShell. API ini mendukung Kontrol akses berbasis peran Azure (Azure RBAC). Untuk informasi selengkapnya tentang cara menerapkan peran akses, lihat Kontrol akses berbasis peran Azure (Azure RBAC).

Penting

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

Perintah Deskripsi
ALTER DATABASE Gunakan argumen ADD SECONDARY ON SERVER untuk membuat database sekunder untuk database yang sudah ada dan memulai replikasi data
ALTER DATABASE Gunakan FAILOVER atau FORCE_FAILOVER_ALLOW_DATA_LOSS untuk mengalihkan database sekunder menjadi primer untuk memulai failover
ALTER DATABASE Gunakan REMOVE SECONDARY ON SERVER untuk mengakhiri replikasi data antara Database SQL 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 Menyebabkan aplikasi menunggu sampai semua transaksi yang dilakukan mengeras ke log transaksi geo-sekunder.

Konten terkait

Mengonfigurasi replikasi geografis aktif:

Konten kelangsungan bisnis lainnya: