Replikasi Geo Aktif

  • Artikel

Berlaku untuk:Azure SQL Database

Replikasi geografis aktif adalah fitur yang memungkinkan Anda membuat database sekunder yang dapat dibaca yang terus disinkronkan untuk database utama. 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, dan hanya mendukung failover manual. Untuk melakukan failover pada sekelompok database, atau jika aplikasi Anda memerlukan titik akhir koneksi yang stabil, pertimbangkan grup Failover sebagai gantinya.

Anda juga dapat menggunakan Migrasi SQL Database 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.

active geo-replication

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 geo-replikasi dapat ditemukan dalam Gambaran Kontinuitas Bisnis.

Gambar berikut menunjukkan contoh replikasi geografis aktif yang dikonfigurasi dengan primer di wilayah US Utara Tengah dan sekunder di wilayah US Selatan Tengah.

geo-replication relationship

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 mengetahui informasi selengkapnya tentang merancang solusi untuk pemulihan bencana, lihat Merancang Solusi Cloud untuk Pemulihan Bencana Menggunakan geo-replikasi aktif.

Terminologi dan kemampuan geo-replikasi aktif

  • 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 mengetahui detailnya, lihat Keamanan SQL Database setelah pemulihan bencana. 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 detailnya, lihat Pencadangan otomatis 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 laju log transaksi pada primer karena ukuran komputasi yang lebih rendah pada sekunder dilaporkan menggunakan jenis tunggu HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO, terlihat dalam tampilan database sys.dm_exec_requests dan sys.dm_os_wait_stats.

IO log transaksi pada primer mungkin dibatasi karena alasan yang tidak terkait dengan ukuran komputasi yang lebih rendah pada geo-sekunder. Pembatasan semacam ini mungkin terjadi bahkan jika geo-sekunder memiliki ukuran komputasi yang sama atau lebih tinggi daripada yang utama. Untuk detailnya, termasuk jenis tunggu untuk berbagai jenis throttling log rate, lihat Tata kelola laju log transaksi.

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

Gunakan Transact-SQL (T-SQL) buat geo-sekunder dalam langganan yang berbeda dari langganan utama (baik di bawah penyewa ID Microsoft Entra yang sama (sebelumnya Azure Active Directory) atau tidak). Tinjau Mengonfigurasi replikasi geografis aktif untuk mempelajari lebih lanjut.

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 Cara mengonfigurasi login dan pengguna.

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.

Catatan

Jika Anda membuat geo-sekunder sebagai bagian dari konfigurasi grup failover, tidak disarankan untuk menguranginya. Ini untuk memastikan tingkat data Anda memiliki kapasitas yang cukup untuk memproses beban kerja reguler Anda setelah failover diaktifkan.

Penting

Database utama dalam failover group tidak dapat menskalakan ke tingkat yang lebih tinggi kecuali database sekunder terlebih dahulu diskalakan ke tingkat yang lebih tinggi. Misalnya, jika Anda ingin meningkatkan yang utama dari Tujuan Umum ke Bisnis Kritis, Anda harus terlebih dahulu skala geo-sekunder untuk Bisnis Kritis. Jika Anda mencoba untuk skala primer atau geo-sekunder dengan cara yang melanggar aturan ini, Anda akan menerima kesalahan berikut:

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

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 lag adalah satu detik, itu berarti bahwa jika primer dipengaruhi oleh pemadaman pada saat ini dan geo-failover dimulai, transaksi yang dilakukan pada detik terakhir akan hilang.

Untuk mengukur jeda sehubungan dengan perubahan pada database utama yang telah diterapkan pada sekunder, yaitu tersedia untuk dibaca dari sekunder, bandingkan waktu last_commit pada database sekunder dengan nilai yang sama pada database utama.

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

Seperti yang dibahas sebelumnya, replikasi geografis aktif juga dapat dikelola secara terprogram menggunakan 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).

T-SQL: Kelola failover geografis database tunggal dan terkumpul

Penting

Perintah T-SQL ini hanya berlaku untuk replikasi geografis aktif dan tidak berlaku untuk grup failover. Dengan demikian, perintah tersebut juga tidak berlaku untuk SQL Managed Instance, yang hanya mendukung 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.

PowerShell: Mengelola failover geografis dari database tunggal dan terkumpul

Catatan

Artikel ini menggunakan modul Azure Az PowerShell, yang merupakan modul PowerShell yang direkomendasikan untuk berinteraksi dengan Azure. Untuk mulai menggunakan modul Az PowerShell, lihat Menginstal Azure PowerShell. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Penting

Modul PowerShell Azure Resource Manager masih didukung oleh Azure SQL Database, tetapi semua pengembangan di masa mendatang adalah untuk modul Az.Sql. Untuk cmdlet ini, lihat AzureRM.Sql. Argumen untuk perintah dalam modul Az dan dalam modul AzureRm secara substansial identik.

Cmdlet Deskripsi
Dapatkan-AzSqlDatabase Mendapatkan satu atau beberapa database.
New-AzSqlDatabaseSecondary Membuat database sekunder untuk database yang sudah ada dan memulai replikasi data.
Set-AzSqlDatabaseSecondary Mengubah database sekunder menjadi utama untuk memulai kegagalan.
Remove-AzSqlDatabaseSecondary Mengakhiri replikasi data antara SQL Database dan database sekunder yang ditentukan.
Get-AzSqlDatabaseReplicationLink Mendapatkan tautan geo-replikasi untuk database.

Tip

Untuk contoh skrip, lihat Mengonfigurasi dan kegagalan database tunggal menggunakan replikasi geografis aktif dan Mengonfigurasi dan kegagalan database kumpulan menggunakan replikasi geografis aktif.

REST API: Mengelola failover geografis database tunggal dan terkumpul

API Deskripsi
Membuat atau Memperbarui Database (createMode=Restore) Membuat, memperbarui, atau memulihkan database utama atau sekunder.
Mendapatkan Status Membuat atau Memperbarui Database Mengembalikan status selama operasi pembuatan.
Mengatur Database Sekunder sebagai Utama (Failover Terencana) Mengatur database sekunder mana yang utama dengan gagal dari database utama saat ini. Opsi ini tidak didukung untuk SQL Managed Instance.
Mengatur Database Sekunder sebagai Utama (Kegagalan Tidak Terencana) Mengatur database sekunder mana yang utama dengan gagal dari database utama saat ini. Operasi ini dapat mengakibatkan hilangnya data. Opsi ini tidak didukung untuk SQL Managed Instance.
Dapatkan Tautan Replikasi Mendapatkan tautan replikasi tertentu untuk database tertentu dalam kemitraan replikasi geografis. Ini mengambil informasi yang terlihat dalam tampilan katalog sys.geo_replication_links. Opsi ini tidak didukung untuk SQL Managed Instance.
Tautan Replikasi: Daftar Menurut Database Mendapatkan semua tautan replikasi untuk database tertentu dalam kemitraan replikasi geografis. Ini mengambil informasi yang terlihat dalam tampilan katalog sys.geo_replication_links.
Hapus Tautan Replikasi Menghapus tautan replikasi database. Tidak dapat dilakukan selama failover.

Langkah berikutnya