Peningkatan dan Pembaruan Server Grup Ketersediaan dengan Waktu Henti Minimal dan Kehilangan Data
Saat memperbarui atau meningkatkan instans server dari SQL Server 2012 ke paket layanan atau versi yang lebih baru, Anda dapat mengurangi waktu henti untuk grup ketersediaan menjadi hanya satu failover manual dengan melakukan pembaruan atau peningkatan berurutan. Untuk meningkatkan versi SQL Server, ini dikenal sebagai peningkatan bergulir; untuk memperbarui versi SQL Server saat ini dengan perbaikan atau paket layanan, ini dikenal sebagai pembaruan bergulir.
Topik ini membatasi diskusi hanya untuk SQL Server peningkatan/pembaruan. Untuk peningkatan/pembaruan terkait sistem operasi yang dijalankan instans SQL Server dengan ketersediaan tinggi, lihat Migrasi Lintas Kluster Grup Ketersediaan AlwaysOn untuk Peningkatan Sistem Operasi
Peningkatan Bergulir/Perbarui Praktik Terbaik untuk Grup Ketersediaan AlwaysOn
Praktik terbaik berikut harus diamati saat melakukan peningkatan/pembaruan server untuk meminimalkan waktu henti dan kehilangan data untuk grup ketersediaan Anda:
Sebelum memulai peningkatan/pembaruan bergulir,
Lakukan praktik failover manual pada setidaknya salah satu replika penerapan sinkron Anda
Lindungi data Anda dengan melakukan pencadangan database lengkap pada setiap database ketersediaan
Menjalankan DBCC CHECKDB pada setiap database ketersediaan
Selalu tingkatkan/perbarui simpul replika sekunder jarak jauh terlebih dahulu, lalu simpul replika sekunder lokal berikutnya, dan simpul replika utama terakhir.
Pencadangan tidak dapat terjadi pada database yang sedang dalam proses dimutakhirkan. Sebelum meningkatkan replika sekunder, konfigurasikan preferensi pencadangan otomatis untuk menjalankan pencadangan hanya pada replika utama. Sebelum memutakhirkan replika utama, ubah pengaturan ini untuk menjalankan pencadangan hanya pada replika sekunder.
Untuk mencegah grup ketersediaan dari failover yang tidak diinginkan selama proses peningkatan/pembaruan, hapus failover ketersediaan dari semua replika penerapan sinkron sebelum Anda mulai.
Jangan tingkatkan node replika utama sebelum melakukan failover pada grup ketersediaan ke node yang ditingkatkan dengan replika sekunder terlebih dahulu. Jika tidak, aplikasi klien dapat mengalami waktu henti yang diperpanjang selama peningkatan/pembaruan pada replika utama.
Selalu gagal atas grup ketersediaan ke simpul replika sekunder synchronous-commit. Jika Anda gagal ke replika sekunder penerapan asinkron, database akan mengalami kehilangan data, dan pergerakan data secara otomatis ditangguhkan sampai Anda melanjutkan pergerakan data secara manual.
Jangan meningkatkan/memperbarui simpul replika utama sebelum meningkatkan/memperbarui simpul replika sekunder lainnya. Replika utama yang ditingkatkan tidak dapat lagi mengirim log ke replika sekunder apa pun yang belum ditingkatkan ke versi yang sama. Ketika pergerakan data ke replika sekunder ditangguhkan, tidak ada failover otomatis yang dapat terjadi untuk replika tersebut, dan database ketersediaan Anda rentan terhadap kehilangan data.
Sebelum mengalihkan grup ketersediaan, verifikasi bahwa status sinkronisasi target failover DISINKRONKAN.
Proses Peningkatan/Pembaruan Bergulir
Dalam praktiknya, proses yang tepat akan bergantung pada faktor-faktor seperti topologi penyebaran grup ketersediaan Anda dan mode penerapan setiap replika. Tetapi dalam skenario paling sederhana, peningkatan/pembaruan bergulir adalah proses multi-tahap yang dalam bentuk paling sederhana melibatkan langkah-langkah berikut:
Menghapus failover otomatis pada semua replika penerapan sinkron
Meningkatkan/memperbarui semua instans server jarak jauh yang menjalankan replika sekunder penerapan asinkron
Meningkatkan/memperbarui semua instans server lokal yang saat ini tidak menjalankan replika utama
Failover grup ketersediaan secara manual ke replika sekunder synchronous-commit
Meningkatkan/memperbarui instans server yang sebelumnya menghosting replika utama
Mengonfigurasi mitra failover otomatis sesuai keinginan
Jika perlu, Anda dapat melakukan failover manual tambahan untuk mengembalikan grup ketersediaan ke konfigurasi aslinya.
Grup Ketersediaan dengan Satu Replika Sekunder Jarak Jauh
Jika Anda telah menyebarkan grup ketersediaan hanya untuk pemulihan bencana, Anda mungkin perlu mengalihkan grup ketersediaan ke replika sekunder penerapan asinkron. Konfigurasi tersebut diilustrasikan oleh gambar berikut:
Dalam situasi ini, Anda harus mengalihkan grup ketersediaan ke replika sekunder penerapan asinkron selama peningkatan/pembaruan bergulir. Untuk mencegah kehilangan data, ubah mode penerapan menjadi penerapan sinkron dan tunggu replika sekunder disinkronkan sebelum Anda melakukan failover pada grup ketersediaan. Oleh karena itu, proses peningkatan/pembaruan bergulir mungkin terlihat sebagai berikut:
Meningkatkan/memperbarui server jarak jauh
Mengubah mode penerapan menjadi penerapan sinkron
Tunggu hingga status sinkronisasi DISINKRONKAN
Gagal atas grup ketersediaan ke situs jarak jauh
Memutakhirkan/memperbarui server lokal (situs utama)
Gagal atas grup ketersediaan ke situs utama
Mengubah mode penerapan menjadi penerapan asinkron
Karena mode penerapan sinkron bukanlah pengaturan yang disarankan untuk sinkronisasi data ke situs jarak jauh, aplikasi klien mungkin melihat peningkatan latensi database segera setelah pengaturan berubah. Selain itu, melakukan failover akan menyebabkan semua pesan log yang tidak diakui dibuang. Jumlah pesan log yang dibuang bisa sangat besar karena tingginya latensi jaringan antara kedua situs, menyebabkan klien mengalami volume kegagalan transaksi yang tinggi. Anda dapat meminimalkan dampak pada aplikasi klien dengan melakukan hal berikut:
Pilih jendela pemeliharaan dengan hati-hati selama lalu lintas klien rendah
Saat memutakhirkan/memperbarui SQL Server di situs utama, ubah kembali mode ketersediaan ke penerapan asinkron, lalu kembali ke penerapan sinkron ketika Anda siap untuk melakukan failover ke situs utama lagi
Grup Ketersediaan dengan Node Instans Kluster Failover
Jika grup ketersediaan berisi node instans kluster failover (FCI), Anda harus meningkatkan/memperbarui simpul yang tidak aktif sebelum meningkatkan/memperbarui simpul aktif. Gambar di bawah ini menggambarkan skenario grup ketersediaan umum dengan FCI untuk ketersediaan tinggi lokal dan penerapan asinkron antara FCI untuk pemulihan bencana jarak jauh, dan urutan peningkatan.
Meningkatkan/memperbarui REMOTE2
Failover FCI2 ke REMOTE2
Meningkatkan/memperbarui REMOTE1
Meningkatkan/memperbarui PRIMARY2
Failover FCI1 ke PRIMARY2
Meningkatkan/memperbarui PRIMARY1
Meningkatkan/Memperbarui Instans SQL Server dengan Beberapa Grup Ketersediaan
Jika Anda menjalankan beberapa grup ketersediaan dengan replika utama pada simpul server terpisah (konfigurasi Aktif/Aktif), jalur peningkatan/pembaruan melibatkan lebih banyak langkah failover untuk mempertahankan ketersediaan tinggi dalam prosesnya. Misalkan Anda menjalankan tiga grup ketersediaan pada tiga simpul server seperti yang ditunjukkan dalam tabel berikut, dan semua replika sekunder berjalan dalam mode penerapan sinkron.
| Grup Ketersediaan | Node1 | Node2 | Node3 |
|---|---|---|---|
| AG1 | Primer | ||
| AG2 | Primer | ||
| AG3 | Primer |
Mungkin sesuai dalam situasi Anda untuk melakukan peningkatan/pembaruan bergulir yang seimbang dalam urutan berikut:
Failover AG2 ke Node3 (untuk membebaskan Node2)
Meningkatkan/memperbarui Node2
Failover AG1 ke Node2 (untuk membebaskan Node1)
Meningkatkan/memperbarui Node1
Failover AG2 dan AG3 ke Node1 (untuk membebaskan Node3)
Meningkatkan/memperbarui Node3
Failover AG3 ke Node3
Urutan peningkatan/pembaruan ini memiliki waktu henti rata-rata kurang dari dua failover per grup ketersediaan. Konfigurasi yang dihasilkan ditampilkan dalam tabel di bawah ini.
| Grup Ketersediaan | Node1 | Node2 | Node3 |
|---|---|---|---|
| AG1 | Primer | ||
| AG2 | Primer | ||
| AG3 | Primer |
Berdasarkan implementasi spesifik Anda, jalur peningkatan/pembaruan Anda dapat bervariasi, dan waktu henti yang dialami aplikasi klien juga dapat bervariasi.