Perbedaan antara mode ketersediaan untuk grup ketersediaan AlwaysOn
Berlaku untuk:
SQL Server
Dalam grup ketersediaan AlwaysOn, mode ketersediaan adalah properti replika yang menentukan apakah replika ketersediaan tertentu dapat berjalan dalam mode penerapan sinkron. Untuk setiap replika ketersediaan, mode ketersediaan harus dikonfigurasi untuk mode penerapan sinkron, penerapan asinkron, atau mode konfigurasi saja. Jika replika utama dikonfigurasi untuk mode penerapan asinkron, replika sekunder tidak menunggu replika masuk menulis rekaman log masuk ke disk (untuk memperkuat log). Jika replika sekunder tertentu dikonfigurasi untuk mode penerapan asinkron, replika utama tidak menunggu replika sekunder tersebut mengeraskan log. Jika replika utama dan replika sekunder tertentu keduanya dikonfigurasi untuk mode penerapan sinkron, replika utama menunggu replika sekunder untuk mengonfirmasi bahwa replika tersebut telah mengeraskan log (kecuali replika sekunder gagal melakukan ping replika utama dalam periode batas waktu sesi utama).
Catatan
Jika periode waktu habis sesi utama terlampaui oleh replika sekunder, replika utama untuk sementara beralih ke mode penerapan asinkron untuk replika sekunder tersebut. Ketika replika sekunder terhubung kembali dengan replika utama, replika tersebut melanjutkan mode penerapan sinkron.
Mode Ketersediaan yang Didukung
Grup ketersediaan AlwaysOn mendukung tiga mode ketersediaan-mode-asinkron-commit mode, mode synchronous-commit, dan mode konfigurasi saja sebagai berikut:
Mode penerapan asinkron adalah solusi pemulihan bencana yang berfungsi dengan baik ketika replika ketersediaan didistribusikan melalui jarak yang cukup jauh. Jika setiap replika sekunder berjalan dalam mode penerapan asinkron, replika utama tidak menunggu replika sekunder mengeraskan log. Sebaliknya, segera setelah menulis catatan log ke file log lokal, replika utama mengirimkan konfirmasi transaksi ke klien. Replika utama berjalan dengan latensi transaksi minimum sehubungan dengan replika sekunder yang dikonfigurasi untuk mode penerapan asinkron. Jika primer saat ini dikonfigurasi untuk mode ketersediaan penerapan asinkron, ia akan melakukan transaksi secara asinkron untuk semua replika sekunder terlepas dari pengaturan mode ketersediaan individual mereka.
Untuk informasi selengkapnya, lihat Mode Ketersediaan Penerapan Asinkron, nanti dalam topik ini.
Mode penerapan sinkron menekankan ketersediaan tinggi atas performa, dengan biaya peningkatan latensi transaksi. Di bawah mode penerapan sinkron, transaksi menunggu untuk mengirim konfirmasi transaksi ke klien sampai replika sekunder telah mengeraskan log ke disk. Ketika sinkronisasi data dimulai pada database sekunder, replika sekunder mulai menerapkan rekaman log masuk dari database utama yang sesuai. Segera setelah setiap rekaman log diperkeras, database sekunder memasuki status DISINKRONKAN. Setelah itu, setiap transaksi baru diperkuat oleh replika sekunder sebelum rekaman log ditulis ke file log lokal. Ketika semua database sekunder dari replika sekunder tertentu disinkronkan, mode penerapan sinkron mendukung failover manual dan, secara opsional, failover otomatis.
Untuk informasi selengkapnya, lihat Mode Ketersediaan Penerapan Sinkron, nanti dalam topik ini.
Mode konfigurasi saja berlaku untuk grup ketersediaan yang tidak ada di Kluster Failover Windows Server. Replika dalam mode konfigurasi saja tidak berisi data pengguna. Dalam mode konfigurasi saja, database master replika menyimpan metadata konfigurasi grup ketersediaan. Untuk informasi selengkapnya lihat Grup ketersediaan dengan replika konfigurasi saja.
Ilustrasi berikut menunjukkan grup ketersediaan dengan lima replika ketersediaan. Replika utama dan satu replika sekunder dikonfigurasi untuk mode penerapan sinkron dengan failover otomatis. Replika sekunder lainnya dikonfigurasi untuk mode synchronous-commit hanya dengan failover manual yang direncanakan, dan dua replika sekunder dikonfigurasi untuk mode penerapan asinkron, yang hanya mendukung failover manual paksa (biasanya disebut failover paksa).
Perilaku sinkronisasi dan failover antara dua replika ketersediaan tergantung pada mode ketersediaan kedua replika. Misalnya, agar penerapan sinkron terjadi, replika utama saat ini dan replika sekunder yang dimaksud harus dikonfigurasi untuk penerapan sinkron. Demikian juga, agar failover otomatis terjadi, kedua replika perlu dikonfigurasi untuk failover otomatis. Oleh karena itu, perilaku untuk skenario penyebaran yang diilustrasikan di atas dapat dirangkum dalam tabel berikut, yang mengeksplorasi perilaku dengan setiap replika utama potensial:
| Replika Utama Saat Ini | Target Failover Otomatis | Perilaku Mode Synchronous-Commit Dengan | Perilaku Mode Asynchronous-Commit Dengan | Failover otomatis dimungkinkan |
|---|---|---|---|---|
| 01 | 02 | 02 dan 03 | 04 | Ya |
| 02 | 01 | 01 dan 03 | 04 | Ya |
| 03 | 01 dan 02 | 04 | Tidak | |
| 04 | 01, 02, dan 03 | Tidak |
Biasanya, Node 04 sebagai replika penerapan asinkron, disebarkan di situs pemulihan bencana. Fakta bahwa Node 01, 02, dan 03 tetap pada mode penerapan asinkron setelah failover ke Node 04 membantu mencegah potensi penurunan performa dalam grup ketersediaan Anda karena latensi jaringan yang tinggi antara kedua situs.
Mode Ketersediaan Asynchronous-Commit
Di bawah mode penerapan asinkron, replika sekunder tidak pernah disinkronkan dengan replika utama. Meskipun database sekunder tertentu mungkin mengejar database utama yang sesuai, database sekunder apa pun dapat tertinggal kapan saja. Mode penerapan asinkron dapat berguna dalam skenario pemulihan bencana di mana replika utama dan replika sekunder dipisahkan oleh jarak yang signifikan dan di mana Anda tidak ingin kesalahan kecil berdampak pada replika utama atau dalam situasi di mana performa lebih penting daripada perlindungan data yang disinkronkan. Selain itu, karena replika utama tidak menunggu pengakuan dari replika sekunder, masalah pada replika sekunder tidak pernah berdampak pada replika utama.
Replika sekunder penerapan asinkron mencoba mengikuti catatan log yang diterima dari replika utama. Tetapi database sekunder penerapan asinkron selalu tetap tidak disinkronkan dan cenderung tertinggal agak di belakang database utama yang sesuai. Biasanya kesenjangan antara database sekunder penerapan asinkron dan database utama yang sesuai kecil. Tetapi kesenjangan dapat menjadi substansial jika server yang menghosting replika sekunder terlalu dimuat atau jaringan lambat.
Satu-satunya bentuk failover yang didukung oleh mode penerapan asinkron adalah failover paksa (dengan kemungkinan kehilangan data). Memaksa failover adalah upaya terakhir yang hanya ditujukan untuk situasi di mana replika utama saat ini akan tetap tidak tersedia untuk jangka waktu yang lama dan ketersediaan langsung database utama lebih penting daripada risiko kemungkinan kehilangan data. Target failover harus berupa replika yang perannya dalam status SEKUNDER atau PENYELESAIAN. Target failover beralih ke peran utama, dan salinan databasenya menjadi database utama. Database sekunder yang tersisa, bersama dengan database utama sebelumnya, setelah tersedia, ditangguhkan hingga Anda melanjutkannya secara manual satu per satu. Dalam mode penerapan asinkron, log transaksi apa pun yang belum dikirim replika utama asli ke replika sekunder sebelumnya hilang. Ini berarti bahwa beberapa atau semua database utama baru mungkin kurang melakukan transaksi baru-baru ini. Untuk informasi selengkapnya tentang cara kerja failover paksa dan pada praktik terbaik untuk menggunakannya, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).
Mode Ketersediaan Synchronous-Commit
Di bawah mode ketersediaan penerapan sinkron (mode penerapan sinkron), setelah bergabung ke grup ketersediaan, database sekunder mengejar database utama yang sesuai dan memasuki status DISINKRONKAN. Database sekunder tetap DISINKRONKAN selama sinkronisasi data berlanjut. Ini menjamin bahwa setiap transaksi yang dilakukan pada database utama tertentu juga telah dilakukan pada database sekunder yang sesuai. Ketika setiap database sekunder pada replika sekunder tertentu disinkronkan, status sinkronisasi-kesehatan replika sekunder secara keseluruhan adalah SEHAT.
Di bagian ini:
Faktor-faktor yang Mengganggu Sinkronisasi Data
Setelah semua databasenya disinkronkan, replika sekunder memasuki status SEHAT. Replika sekunder yang disinkronkan akan tetap sehat kecuali salah satu hal berikut ini terjadi:
Penundaan atau kesalahan jaringan atau komputer menyebabkan sesi antara replika sekunder dan replika utama kehabisan waktu.
Catatan
Untuk informasi tentang properti waktu sesi replika ketersediaan, lihat Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server).
Anda menangguhkan database sekunder pada replika sekunder. Replika sekunder berhenti disinkronkan, dan status sinkronisasi-kesehatannya ditandai sebagai NOT_HEALTHY. Replika sekunder tidak dapat menjadi sehat lagi sampai database sekunder yang ditangguhkan dilanjutkan dan disinkronkan ulang atau dihapus dari grup ketersediaan.
Anda menambahkan database utama grup ketersediaan. Replika sekunder yang sebelumnya disinkronkan memasuki status sinkronisasi-kesehatan NOT_HEALTHY. Status ini menunjukkan bahwa setidaknya satu database berada dalam status sinkronisasi NOT SYNCHRONIZING. Replika sekunder yang diberikan tidak dapat SEHAT lagi sampai database sekunder yang sesuai telah disiapkan pada replika, telah bergabung ke grup ketersediaan, dan telah disinkronkan dengan database utama baru.
Anda mengubah replika utama atau replika sekunder menjadi mode ketersediaan penerapan asinkron. Setelah berubah menjadi mode penerapan asinkron, replika sekunder akan tetap dalam status sinkronisasi-kesehatan SEHAT selama sinkronisasi data berlanjut. Namun, jika hanya replika utama yang diubah ke mode penerapan asinkron, replika sekunder penerapan sinkron akan memasuki status sinkronisasi-kesehatan PARTIALLY_HEALTHY. Status ini menunjukkan bahwa setidaknya satu database berada dalam status sinkronisasi SYNCHRONIZING, tetapi tidak ada database yang berada dalam status NOT SYNCHRONIZING.
Anda mengubah replika sekunder apa pun menjadi mode ketersediaan penerapan sinkron. Hal ini menyebabkan replika sekunder ditandai sebagai dalam status sinkronisasi-kesehatan PARTIALLY_HEALTHY sampai semua databasenya berada dalam status sinkronisasi YANG DISINKRONKAN.
Tip
Untuk menampilkan kesehatan sinkronisasi grup ketersediaan, replika ketersediaan, atau database ketersediaan, kueri kolom synchronization_health atau synchronization_health_descsys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, atau sys.dm_hadr_database_replica_states.
Cara Kerja Sinkronisasi pada Replika Sekunder
Di bawah mode penerapan sinkron, setelah replika sekunder bergabung dengan grup ketersediaan dan membuat sesi dengan replika utama, replika sekunder menulis rekaman log masuk ke disk (mengeraskan log) dan mengirim pesan konfirmasi ke replika utama. Setelah log yang diperkeras pada database sekunder telah menyusul akhir log pada database utama, status database sekunder diatur ke SYNCHRONIZED. Waktu yang diperlukan untuk sinkronisasi pada dasarnya tergantung pada seberapa jauh database sekunder berada di belakang database utama pada awal sesi (diukur dengan jumlah rekaman log yang awalnya diterima dari replika utama), beban kerja pada database utama, dan kecepatan komputer instans server yang menghosting replika sekunder.
Operasi sinkron dipertahankan dengan cara berikut:
Saat menerima transaksi dari klien, replika utama menulis log untuk transaksi ke log transaksi dan secara bersamaan mengirim catatan log ke replika sekunder.
Setelah rekaman log ditulis ke log transaksi database utama, transaksi hanya dapat dibatalkan jika ada failover pada saat ini ke sekunder yang tidak menerima log. Replika utama menunggu konfirmasi dari replika sekunder synchronous-commit.
Replika sekunder mengeraskan log dan mengembalikan pengakuan ke replika utama.
Saat menerima konfirmasi dari replika sekunder, replika utama menyelesaikan pemrosesan penerapan dan mengirim pesan konfirmasi kepada klien.
Catatan
Jika replika sekunder penerapan sinkron kehabisan waktu tanpa mengonfirmasi bahwa replika tersebut telah mengeraskan log, replika sekunder tersebut akan ditandai sebagai gagal. Status terhubung dari replika sekunder berubah menjadi TERPUTUS, dan replika utama berhenti menunggu konfirmasi dari replika sekunder. Perilaku ini memastikan bahwa replika sekunder synchronous-commit yang gagal tidak mencegah pengerasan log transaksi pada replika utama.
Mode penerapan sinkron melindungi data Anda dengan mengharuskan data disinkronkan antara dua tempat, dengan biaya yang agak meningkatkan latensi transaksi.
Mode Synchronous-Commit hanya dengan Failover Manual
Ketika replika ini tersambung dan database disinkronkan, failover manual didukung. Jika replika sekunder turun, replika utama tidak terpengaruh. Replika utama berjalan terekspos jika tidak ada replika YANG DISINKRONKAN (yaitu, tanpa mengirim data ke replika sekunder). Jika replika utama hilang, replika sekunder memasuki status RESOLVING, tetapi pemilik database dapat memaksa failover ke replika sekunder (dengan kemungkinan kehilangan data). Untuk informasi selengkapnya, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).
Mode Synchronous-Commit dengan Failover Otomatis
Failover otomatis memberikan ketersediaan tinggi dengan memastikan bahwa database dengan cepat tersedia lagi setelah hilangnya replika utama. Untuk mengonfigurasi grup ketersediaan untuk failover otomatis, Anda perlu mengatur replika utama saat ini dan setidaknya satu replika sekunder ke mode penerapan sinkron dengan failover otomatis. SQL Server 2019 (15.x) meningkatkan jumlah maksimum replika sinkron menjadi 5, naik dari 3 dalam SQL Server 2017 (14.x). Anda dapat mengonfigurasi grup yang terdiri dari lima replika ini untuk memiliki failover otomatis dalam grup. Ada satu replika utama, ditambah empat replika sekunder sinkron.
Selain itu, agar failover otomatis dimungkinkan pada waktu tertentu, replika sekunder ini harus disinkronkan dengan replika utama (yaitu, database sekunder semuanya disinkronkan), dan kluster Windows Server Failover Clustering (WSFC) harus memiliki kuorum. Jika replika utama menjadi tidak tersedia dalam kondisi ini, failover otomatis terjadi. Replika sekunder beralih ke peran utama, dan menawarkan databasenya sebagai database utama. Untuk informasi selengkapnya, lihat bagian "Failover Otomatis" dari topik Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).
Catatan
Untuk informasi tentang kuorum WSFC dan grup ketersediaan AlwaysOn, lihat Untuk informasi selengkapnya, lihat Mode Kuorum WSFC dan Konfigurasi Pemungutan Suara (SQL Server).
Latensi data pada replika sekunder
Menerapkan akses baca-saja ke replika sekunder berguna jika beban kerja baca-saja Anda dapat mentolerir beberapa latensi data. Dalam situasi di mana latensi data tidak dapat diterima, pertimbangkan untuk menjalankan beban kerja baca-saja terhadap replika utama.
Replika utama mengirimkan catatan log perubahan pada database utama ke replika sekunder. Pada setiap database sekunder, utas pengulangan khusus menerapkan catatan log. Pada database sekunder akses baca, perubahan data tertentu tidak muncul dalam hasil kueri hingga rekaman log yang berisi perubahan telah diterapkan ke database sekunder dan transaksi telah dilakukan pada database utama.
Ini berarti bahwa ada beberapa latensi, biasanya hanya hitungan detik, antara replika primer dan sekunder. Namun, dalam kasus yang tidak biasa, misalnya jika masalah jaringan mengurangi throughput, latensi dapat menjadi signifikan. Latensi meningkat ketika penyempitan I/O terjadi dan ketika pergerakan data ditangguhkan. Untuk memantau pergerakan data yang ditangguhkan, Anda dapat menggunakan Dasbor AlwaysOn atau tampilan manajemen dinamis sys.dm_hadr_database_replica_states.
Untuk informasi selengkapnya tentang menyelidiki latensi fase pengulangan pada replika sekunder, silakan lihat Memecahkan masalah perubahan utama yang tidak tercermin pada replika sekunder.
Tugas Terkait
Untuk mengubah mode ketersediaan dan mode failover
Untuk menyesuaikan suara kuorum
Untuk melakukan failover manual
Melakukan Failover Manual Terencana dari Grup Ketersediaan (SQL Server)
Melakukan Failover Manual Paksa dari Grup Ketersediaan (SQL Server)
Gunakan Wizard Grup Ketersediaan Fail Over (SQL Server Management Studio)
Untuk melihat grup ketersediaan, replika ketersediaan, dan status database
Konten terkait
Panduan Solusi Microsoft SQL Server Always On untuk Ketersediaan Tinggi dan Pemulihan Bencana
SQL Server Blog Always On Team: Blog resmi SQL Server Always On Team
Lihat juga
Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Mode Failover dan Failover (Grup Ketersediaan AlwaysOn)
Pengklusteran Failover Windows Server (WSFC) dengan SQL Server
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk