Tingkatkan Versi Database SQL Server - ApsaraDB RDS

Versi berbeda dari ApsaraDB RDS for SQL Server menawarkan kemampuan yang berbeda. Anda dapat meningkatkan instans ke versi atau edisi yang lebih tinggi untuk mendapatkan performa dan skalabilitas yang lebih baik. Sebagai contoh, Anda dapat melakukan peningkatan versi utama dari SQL Server 2019 Standard Edition ke 2022 Standard Edition, atau meningkatkan edisi instans dari Basic Edition ke High-availability Edition.

Informasi latar belakang

ApsaraDB RDS for SQL Server menyediakan tiga edisi instans. Setiap edisi memiliki fitur, keunggulan, dan kekurangan yang berbeda.

Basic Edition tidak memiliki node cadangan untuk cadangan panas. Hal ini menyebabkan periode tidak tersedia yang lama jika instans gagal secara tak terduga atau ketika Anda melakukan tugas seperti mengubah konfigurasi atau meningkatkan versi.
High-availability Edition menggunakan arsitektur ketersediaan tinggi (HA) klasik dengan node utama dan node cadangan. Data disinkronkan dari node utama ke node cadangan dalam mode semi-sinkron atau asinkron. Jika node utama gagal, sistem secara otomatis beralih ke node cadangan.
Cluster Edition didasarkan pada teknologi AlwaysOn asli dari SQL Server. Edisi ini menggunakan arsitektur komputasi-penyimpanan terpisah dan mendukung pembuatan satu atau lebih instans hanya baca untuk menerapkan pemisahan baca/tulis. Ini memenuhi persyaratan aplikasi yang melakukan banyak operasi baca database.

Perhatian

Peningkatan versi utama, edisi, dan tipe bersifat tidak dapat dibalik. Aturan peningkatan adalah sebagai berikut:

Aturan Peningkatan

Item Peningkatan	Aturan peningkatan
Tingkatkan versi utama database	Standard Edition → Enterprise Edition Standard Edition → Enterprise Cluster Edition Web Edition → Standard Edition Web Edition → Enterprise Edition Web Edition → Enterprise Cluster Edition Catatan Pertama, tingkatkan Web Edition ke Standard Edition. Kemudian, Anda dapat menaikkannya ke Enterprise Edition atau Enterprise Cluster Edition.
Tingkatkan edisi instans	Peningkatan ke edisi yang lebih tinggi didukung. Edisi diurutkan dari yang terendah hingga tertinggi: Basic Edition < High-availability Edition < Cluster Edition. Penurunan edisi tidak didukung.
Tingkatkan keluarga instans atau tipe	Anda dapat menaikkan ke keluarga instans yang sama atau lebih tinggi. Opsi yang tersedia ditampilkan di konsol. Keluarga instans diurutkan dari yang terendah hingga tertinggi: Shared < General-purpose < Dedicated. Penurunan tidak didukung. Catatan Anda tidak dapat langsung menaikkan tipe instans Shared dari High-availability Edition ke tipe instans Dedicated dari Cluster Edition. Jika keluarga instans tujuan tidak tersedia di konsol, Anda dapat membuat instans baru dari keluarga tujuan dan kemudian migrasi data dari instans asli ke yang baru.

Peringatan

Karena peningkatan bersifat tidak dapat dibalik, buat instans pay-as-you-go atau Serverless dari versi target untuk menguji kompatibilitas sebelum Anda menaikkan versi.
Selama peningkatan versi database, jangan lakukan operasi modifikasi metadata apa pun pada instans. Operasi ini dapat menyebabkan inkonsistensi data setelah peningkatan. Operasi modifikasi metadata termasuk menambahkan atau menghapus database, atau mengubah model pemulihan database.

Karena peningkatan melibatkan migrasi lintas host yang menghapus akun host dan program atau file apa pun (seperti SSIS, SSAS, dan SSRS) yang diterapkan pada host asli, Anda harus memigrasi atau mencadangkan data ini terlebih dahulu.
Penting
ApsaraDB RDS for SQL Server didasarkan pada kernel Microsoft SQL Server asli dan berfokus pada penyediaan layanan database terkelola yang stabil dan efisien. Jika bisnis Anda memerlukan fitur seperti SSIS, SSAS, atau SSRS, Anda memerlukan kemampuan O&M profesional untuk memastikan kelangsungan bisnis.

Batasan

Anda tidak dapat menaikkan versi database untuk instans yang memenuhi kondisi berikut:

Instans yang bergabung dengan domain AD.
Serverless instans.
Instans yang menggunakan tipe jaringan klasik.
Instans hanya baca dan instans Cluster Edition utama tempat instans hanya baca dilampirkan.

Dampak peningkatan

Proses peningkatan tidak dapat dibatalkan setelah dimulai, dan bersifat tidak dapat dibalik.
Pengaturan asli instans, seperti nama instans, port akses, tag, dan akun database, tetap tidak berubah setelah peningkatan.
Waktu yang diperlukan untuk peningkatan bergantung pada faktor-faktor seperti jumlah data dalam instans. Untuk informasi lebih lanjut, lihat bagian FAQ dalam topik ini.
Selama peningkatan, terjadi alih bencana jaringan. Instans tidak tersedia hingga 20 menit. Untuk informasi lebih lanjut, lihat bagian FAQ dalam topik ini. Pastikan aplikasi Anda memiliki mekanisme penyambungan otomatis.
Selama peningkatan, sumber daya dasar instans dimigrasi. Hal ini menyebabkan alamat IP virtual (VIP) berubah. Untuk memastikan stabilitas dan kelangsungan bisnis, Anda harus menggunakan titik akhir internal atau publik dari instans RDS di aplikasi Anda untuk terhubung ke instans. Jangan gunakan alamat IP yang diselesaikan. Titik akhir RDS adalah nama domain dinamis dengan fitur perutean otomatis yang beradaptasi dengan perubahan alamat IP backend.
Hapus cache DNS di klien. Untuk aplikasi yang menggunakan JVM, atur TTL dalam konfigurasi JVM menjadi 60 detik atau kurang. Ini memastikan bahwa ketika alamat VIP titik akhir berubah, aplikasi dapat meminta DNS lagi untuk mendapatkan dan menggunakan alamat VIP baru.
Catatan
Metode berikut dapat digunakan untuk mengatur TTL dalam JVM:
- Untuk mengatur TTL untuk semua aplikasi yang menggunakan JVM: Atur parameter networkaddress.cache.ttl dalam file $JAVA_HOME/jre/lib/security/java.security menjadi 60.
- Untuk mengatur TTL hanya untuk aplikasi lokal: Dalam kode inisialisasi aplikasi Anda, atur java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); sebelum panggilan pertama ke InetAddress.getByName() dan sebelum koneksi jaringan apa pun dibuat.
Jika tugas DTS sedang berjalan, Anda harus mengonfigurasi ulang dan memulai ulang tugas tersebut setelah peningkatan.

Penagihan

Untuk informasi tentang biaya peningkatan versi, lihat Ubah Spesifikasi Instans.

Prosedur

Buka halaman Instans. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Kemudian, temukan instans RDS dan klik ID instans tersebut.
Di halaman Basic Information, di bagian Configuration Information, klik Upgrade Version. Di kotak dialog yang muncul, klik Confirm.
Catatan
Jika Anda tidak dapat menemukan opsi ini, periksa apakah instans Anda memenuhi persyaratan peningkatan.

Di halaman Upgrade Engine Version, ubah konfigurasi. Parameter utama dijelaskan dalam tabel berikut. Untuk informasi tentang parameter lainnya, lihat bagian Prosedur.

Catatan

Beberapa instans mungkin memiliki batasan pada pilihan versi dan edisi selama peningkatan. Untuk informasi lebih lanjut, lihat bagian Perhatian dan Batasan dalam topik ini.

Parameter	Deskripsi
Upgrade To	Saat Anda memilih versi tujuan yang berbeda, opsi untuk Edition dan Instance Type juga berubah. Untuk informasi lebih lanjut, lihat Aturan peningkatan.
Edition	Pilih edisi tujuan: Basic Edition: Instans single-node dengan arsitektur komputasi-penyimpanan terpisah. High-availability Edition: Arsitektur HA klasik dengan node utama dan node cadangan yang memberikan performa seimbang. Cluster Edition: Arsitektur HA dengan satu node utama dan beberapa node cadangan. Instans cadangan dapat diakses.
Instance Type	Setiap tipe instans memiliki jumlah inti CPU, ukuran memori, jumlah maksimum koneksi, dan IOPS maksimum tertentu.
Switching Time	Switch Immediately After Data Migration: Migrasi dan alih bencana akan dimulai secara langsung. Switch Within Maintenance Window: Migrasi dimulai segera, dan alih bencana dilakukan dalam jendela pemeliharaan.

Klik Confirm Order dan kemudian klik Confirm di kotak dialog yang muncul.
Status instans asli berubah menjadi Upgrading > Upgrading Across Networks. Peningkatan selesai ketika status instans berubah menjadi Running. Durasi peningkatan bergantung pada jumlah data.

FAQ

Bisakah saya memodifikasi instans selama peningkatan versi utama? Misalnya, bisakah saya mengubah tipe instans?

Tidak, Anda tidak bisa. Anda hanya dapat melakukan operasi lain setelah peningkatan selesai.

Apakah peningkatan versi utama otomatis didukung?

Anda tidak dapat secara otomatis menaikkan versi utama database.

Berapa lama waktu yang dibutuhkan untuk peningkatan versi utama?

Estimasi waktu

Secara umum, estimasi waktu yang diperlukan untuk menaikkan versi utama instans adalah sebagai berikut. Perhatikan bahwa kecepatan pencadangan dan pemulihan berikut didasarkan pada ukuran data yang tidak dikompresi.

Catatan

Karena instans Web Edition tidak mendukung kompresi cadangan, efisiensi pencadangan terpengaruh. Kecepatan pencadangan dan pemulihan dapat turun menjadi kurang dari 100 GB/jam.

Operasi	Diperlukan	Estimasi waktu	Catatan
Buat dan konfigurasikan instans baru	Diperlukan	10 hingga 15 menit	Waktu yang diperlukan bergantung pada edisi dan tipe instans yang Anda pilih untuk peningkatan.
Lakukan pencadangan penuh instans	Opsional	200 GB/jam	Jika tidak ada pencadangan penuh yang dilakukan pada instans RDS dalam 36 jam terakhir, pencadangan penuh dilakukan selama proses peningkatan untuk menyeimbangkan waktu yang diperlukan untuk pemulihan data dari pencadangan log transaksi inkremental dan pencadangan penuh. Kebijakan pencadangan penuh memerlukan pencadangan penuh jika belum dilakukan dalam 36 jam terakhir. Jika demikian, proses peningkatan akan mencakup pencadangan penuh untuk menyeimbangkan waktu yang diperlukan untuk log transaksi. Untuk mengurangi total waktu peningkatan, lakukan pencadangan penuh secara manual pada waktu yang sesuai sebelum peningkatan. Sebagai alternatif, mulai tugas peningkatan dalam waktu 36 jam setelah pencadangan penuh otomatis selesai. Kecepatan pencadangan dapat bervariasi berdasarkan wilayah dan periode waktu. Untuk mendapatkan data performa pencadangan dan pemulihan yang lebih akurat, periksa volume data dan durasi pencadangan penuh terbaru.
Pulihkan pencadangan penuh ke instans tujuan	Diperlukan	200 GB/jam	Tidak ada
Lakukan pencadangan log transaksi inkremental pada instans sumber	Diperlukan	200 GB/jam	Dibutuhkan tambahan 2 menit sebelum dan sesudah pencadangan log inkremental untuk tugas seperti persiapan pencadangan, finalisasi, dan alokasi sumber daya.
Terapkan pencadangan log transaksi inkremental ke instans tujuan	Diperlukan	200 GB/jam	Dibutuhkan tambahan 2 menit sebelum dan sesudah menerapkan pencadangan log inkremental untuk tugas seperti verifikasi konsistensi pencadangan.
Membawa database online	Diperlukan	Kurang dari 2 menit	Konsumsi sumber daya: Menerapkan pencadangan log transaksi inkremental adalah operasi yang intensif sumber daya. Untuk instans berukuran kecil, seperti instans 2-core 4 GB, kecepatan pemulihan dapat menurun karena banyaknya log transaksi. Opsi Pemulihan Database Dipercepat: ApsaraDB RDS for SQL Server 2019 dan versi selanjutnya menyediakan opsi Pemulihan Database Dipercepat, yang dapat mengurangi waktu yang diperlukan untuk membawa database online. Evaluasi apakah akan mengaktifkan opsi ini berdasarkan dokumentasi resmi Microsoft.
Tunggu alih bencana jaringan dan migrasi koneksi	Diperlukan	10 menit	Tidak ada

Estimasi contoh

Instans uji: Instans 4-core 8 GB dengan 600 GB data.

Buat dan konfigurasikan instans baru: Estimasi waktu adalah 12 menit.
Lakukan pencadangan penuh (opsional): Estimasi waktu adalah 3 jam. (600 GB / 200 GB per jam)
Pulihkan pencadangan penuh ke instans target: Estimasi waktu adalah 3 jam. (600 GB / 200 GB per jam)
Lakukan pencadangan log transaksi inkremental pada instans sumber: Estimasi waktu adalah 5 menit. (10 GB / 200 GB per jam) + 2 menit overhead tambahan = 5 menit
Terapkan pencadangan log transaksi inkremental ke instans target: Estimasi waktu adalah 5 menit. (10 GB / 200 GB per jam) + 2 menit overhead tambahan = 5 menit
Membawa database online: Estimasi waktu adalah kurang dari 2 menit.
Alih bencana jaringan dan migrasi: Estimasi waktu adalah 10 menit.

Dalam contoh ini, jika pencadangan penuh belum dilakukan pada instans dalam 36 jam terakhir, total waktu yang diperlukan adalah sekitar 6 jam dan 34 menit. Jika tidak, total waktu yang diperlukan adalah sekitar 3 jam dan 34 menit.

Rekomendasi peningkatan

Perencanaan jendela pemeliharaan: Lakukan peningkatan selama periode beban sistem rendah untuk meminimalkan dampak pada bisnis Anda.
Transaksi jangka panjang: Selama proses peningkatan, hindari transaksi jangka panjang, seperti pembuatan indeks, pengindeksan ulang, atau pengarsipan data. Ini mencegah memperpanjang waktu yang diperlukan untuk langkah Membawa database online.

Dalam skenario lintas zona waktu, bagaimana cara saya menetapkan waktu alih bencana untuk peningkatan instans dengan benar?

Skema: Pengguna berada di wilayah Dubai. Instans ApsaraDB RDS for SQL Server pengguna berada di wilayah Singapura, tetapi zona waktunya disetel ke Waktu Standar India.
Tujuan: Pengguna berencana melakukan alih bencana peningkatan untuk instans RDS pada pukul 02:00 tanggal 11 Mei 2024, Waktu Standar India.
Solusi: Konversikan waktu alih bencana yang direncanakan dari zona waktu instans ApsaraDB RDS for SQL Server (Waktu Standar India) ke zona waktu browser Anda (waktu Dubai). Dalam skenario ini, Anda tidak perlu mempertimbangkan wilayah tempat instans RDS berada. Dalam contoh ini, jika pengguna berencana melakukan alih bencana peningkatan pada pukul 02:00 tanggal 11 Mei 2024, Waktu Standar India, pengguna harus masuk ke konsol RDS dan menetapkan waktu alih bencana pada pukul 00:30 tanggal 11 Mei 2024, waktu Dubai (waktu yang ditampilkan di browser).
Metode Konversi:
1. Konversikan Waktu Standar India (02:00 tanggal 11 Mei 2024) ke UTC: Waktu Standar India adalah 5 jam dan 30 menit mendahului UTC. Waktu UTC yang dikonversi adalah 20:30 tanggal 10 Mei 2024.
2. Konversikan UTC (20:30 tanggal 10 Mei 2024) ke waktu Dubai: UTC adalah 4 jam di belakang waktu Dubai. Waktu Dubai yang dikonversi adalah 00:30 tanggal 11 Mei 2024.

Operasi API terkait

Anda juga dapat menaikkan versi utama database dengan memanggil operasi API. Untuk informasi lebih lanjut, lihat ModifyDBInstanceSpec - Ubah Spesifikasi Instans ApsaraDB RDS.