Tingkatkan versi database SQL Server - ApsaraDB RDS - Alibaba Cloud Documentation Center

Kemampuan instans ApsaraDB RDS untuk SQL Server bervariasi tergantung pada versi mesin utama (versi SQL Server) dan edisi RDS instans tersebut. Untuk kinerja dan skalabilitas yang lebih baik, Anda dapat meningkatkan instans ke versi dan edisi yang lebih tinggi. Misalnya, Anda dapat meningkatkan versi utama instans dari SQL Server 2019 Standard Edition ke SQL Server 2022 Standard Edition atau meningkatkan edisi instans dari Basic Edition ke High-availability Edition.

Informasi latar belakang

RDS untuk SQL Server menyediakan instans dalam tiga edisi, masing-masing dengan fitur dan keunggulan berbeda.

Instans Basic Edition tidak memiliki instans secondary untuk hot standby. Hal ini dapat menyebabkan downtime yang lama jika instans mengalami kegagalan atau selama tugas seperti perubahan spesifikasi atau peningkatan versi.
Instans High-availability Edition menggunakan arsitektur ketersediaan tinggi klasik dengan instans primary dan instans secondary. Data dari instans primary disinkronkan ke instans secondary secara semi-sinkron atau asinkron. Jika instans primary gagal, sistem secara otomatis melakukan failover ke instans secondary.
Instans Cluster Edition didasarkan pada teknologi Always On SQL Server, yang memisahkan komputasi dari penyimpanan. Edisi ini memungkinkan Anda membuat satu atau beberapa read-only instances untuk menerapkan read/write splitting, ideal untuk volume baca yang tinggi.

Catatan penggunaan

Peningkatan versi mesin utama, edisi, dan tipe instans bersifat ireversibel. Aturan peningkatan adalah sebagai berikut:

Aturan peningkatan

Tingkatkan item	Aturan peningkatan
Tingkatkan versi mesin utama database (SQL Server)	Standard Edition → Enterprise Edition Standard Edition → Enterprise Cluster Edition Web Edition → Standard Edition Web Edition → Enterprise Edition Web Edition → Enterprise Cluster Edition Catatan Untuk meningkatkan dari Web Edition ke Enterprise Edition atau Enterprise Cluster Edition, Anda harus terlebih dahulu meningkatkan ke Standard Edition.
Tingkatkan edisi RDS	Anda hanya dapat meningkatkan ke edisi yang lebih tinggi. Urutan edisi dari terendah ke tertinggi adalah: Basic Edition < High-availability Edition < Cluster Edition. Penurunan edisi tidak didukung.
Tingkatkan instance family atau tipe instans	Anda dapat meningkatkan ke instance family yang sama atau lebih tinggi. Periksa konsol untuk opsi yang tersedia. Urutan instance family dari terendah ke tertinggi adalah: Shared < General-purpose < Dedicated. Penurunan ke instance family yang lebih rendah tidak didukung. Catatan Anda tidak dapat langsung meningkatkan instans dari tipe instans shared di High-availability Edition ke tipe instans dedicated di Cluster Edition. Jika instance family target tidak tersedia di konsol, buat instans baru dalam instance family target, lalu migrasi data dari instans asli ke instans baru.

Peringatan

Karena peningkatan tidak dapat dibatalkan, kami merekomendasikan agar Anda terlebih dahulu membuat Instans target bayar sesuai penggunaan atau arsitektur tanpa server untuk menguji kompatibilitas.
Selama peningkatan, jangan mengubah metadata instans. Hal ini dapat menyebabkan inkonsistensi data setelah peningkatan. Operasi modifikasi metadata mencakup, tetapi tidak terbatas pada, penambahan atau penghapusan database atau perubahan model pemulihan database.

Peningkatan akan melibatkan migrasi cross-host, yang akan menghapus host account dan program atau file apa pun, seperti SSIS, SSAS, dan SSRS, pada host asli. Anda harus memigrasi atau backup data Anda terlebih dahulu.
Penting
Dalam kebanyakan kasus, pembaruan versi mesin minor tidak menyebabkan masalah kompatibilitas. Namun, pembaruan tersebut dapat menyebabkan perubahan fungsionalitas. Kami menyarankan agar Anda memeriksa cumulative updates (CUs) SQL Server yang dirilis Microsoft untuk memverifikasi apakah kernel SQL Server diperbarui.

Batasan

Instans berikut tidak mendukung peningkatan versi database:

Instans yang bergabung dengan domain Direktori Aktif (AD).
Serverless Instans.
Instansi hanya baca dan instans utama Cluster Edition yang tersambung dengan instansi hanya baca.
Instans primary Cluster Edition dengan read-only endpoint untuk instans secondary yang diaktifkan.

Dampak

Setelah dimulai, proses peningkatan tidak dapat dibatalkan dan tidak dapat dikembalikan setelah selesai.
Pengaturan yang ada, seperti nama instans, port, tag, dan akun database, tetap tidak berubah setelah peningkatan.
Durasi peningkatan tergantung pada faktor-faktor seperti volume data instans Anda. Untuk informasi lebih lanjut, lihat bagian FAQ dalam topik ini.
Peningkatan melibatkan switchover jaringan, yang menyebabkan gangguan layanan hingga 20 menit. Untuk informasi lebih lanjut, lihat bagian FAQ dalam topik ini. Pastikan aplikasi Anda memiliki mekanisme rekoneksi otomatis.
Selama peningkatan, proses ini memigrasi sumber daya dasar instans, yang menyebabkan alamat IP virtual (VIP) berubah. Untuk memastikan stabilitas dan kelangsungan bisnis, Anda harus menggunakan endpoint internal atau publik instans RDS untuk menghubungkan ke aplikasi Anda. Jangan gunakan alamat IP hasil resolusi. Endpoint RDS adalah nama domain dinamis dengan kemampuan routing otomatis yang secara mulus menyesuaikan perubahan IP backend.
Jika Anda memilih untuk melakukan switch dalam maintenance window, backup instans reguler dinonaktifkan sejak Anda mengirimkan tugas peningkatan hingga migrasi selesai.
Bersihkan cache DNS pada client Anda. Jika client Anda adalah aplikasi berbasis JVM, kami menyarankan mengatur TTL dalam konfigurasi JVM menjadi 60 detik atau kurang. Hal ini memastikan bahwa ketika alamat VIP endpoint berubah, aplikasi dapat memperoleh alamat VIP baru dengan melakukan kueri ulang DNS.
Catatan
Metode berikut untuk mengatur TTL dalam JVM hanya sebagai referensi:
- Untuk mengatur TTL untuk semua aplikasi berbasis JVM, atur parameter networkaddress.cache.ttl dalam file $JAVA_HOME/jre/lib/security/java.security menjadi 60.
- Untuk mengatur TTL hanya untuk aplikasi lokal, atur java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); dalam kode inisialisasi aplikasi sebelum koneksi jaringan apa pun dibuat, khususnya sebelum panggilan pertama ke InetAddress.getByName().
Jika Anda memiliki tugas Data Transmission Service (DTS) yang sedang berjalan, Anda harus mengonfigurasi ulang dan menjalankan ulang tugas tersebut setelah peningkatan.

Penagihan

Untuk informasi tentang biaya peningkatan versi, lihat ubah spesifikasi.

Prosedur

Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Lalu, temukan instans RDS dan klik ID instans tersebut.
Di halaman Basic Information, pada bagian Configuration Information, klik Upgrade Version. Di kotak dialog yang muncul, klik OK.
Catatan
Jika tombol Upgrade Version tidak ditampilkan, periksa apakah instans Anda memenuhi persyaratan peningkatan.

Di halaman Upgrade Engine Version, ubah konfigurasi. Tabel berikut menjelaskan parameter kunci. Untuk informasi selengkapnya mengenai parameter lainnya, lihat Prosedur.

Catatan

Beberapa instans mungkin memiliki batasan pada versi dan edisi yang tersedia selama peningkatan. Untuk informasi lebih lanjut, lihat bagian Catatan Penggunaan dan Batasan dalam topik ini.

Parameter	Description
Upgrade To	Opsi yang tersedia untuk Edition dan Instance Type berubah berdasarkan versi target yang Anda pilih. Untuk informasi selengkapnya, lihat Upgrade rules.
Edition	Pilih edisi target: Basic Edition: Arsitektur satu node dengan komputasi dan penyimpanan yang terpisah. High-availability Edition: Arsitektur ketersediaan tinggi klasik dengan satu instans primary dan satu instans secondary, memberikan kinerja yang seimbang. Cluster Edition: Arsitektur ketersediaan tinggi dengan satu instans primary dan beberapa instans secondary. Instans secondary dapat diakses untuk operasi baca.
Instance Type	Setiap tipe instans memiliki jumlah vCPU, ukuran memori, jumlah maksimum koneksi, dan IOPS maksimum tertentu.
Switching Time	Switch Immediately After Data Migration: Migrasi dan alih bencana dimulai segera. Switch Within Maintenance Window: Migrasi dimulai segera, dan alih bencana dilakukan selama jendela pemeliharaan yang telah dikonfigurasi.

Klik Pay Now. Di kotak dialog yang muncul, klik OK.
Status instans berubah menjadi Upgrading/Downgrading > Upgrading Across Networks. Saat status instans berubah menjadi Running, peningkatan selesai. Waktu yang dibutuhkan tergantung pada jumlah data. Harap tunggu dengan sabar.

FAQ

Bisakah saya mengubah konfigurasi instans, seperti tipe instans, selama peningkatan versi utama?

Tidak, Anda tidak dapat mengubah konfigurasi instans selama peningkatan versi utama. Anda harus menunggu hingga peningkatan selesai untuk melakukan operasi lain.

Apakah peningkatan versi utama otomatis didukung?

Peningkatan versi utama otomatis tidak didukung.

Berapa lama waktu yang dibutuhkan untuk peningkatan versi utama?

Perkiraan waktu

Tabel berikut memberikan rentang waktu perkiraan untuk peningkatan versi utama instans. Perhatikan bahwa kecepatan backup dan restore didasarkan pada ukuran data yang tidak dikompresi.

Catatan

Karena instans yang menjalankan Web Edition tidak mendukung kompresi backup, efisiensi backup lebih rendah. Kecepatan backup dan restore dapat turun di bawah 100 GB/jam.

Operasi	Diperlukan	Perkiraan waktu	Catatan
Create and configure new instance	Yes	10–15 menit	Waktu yang dibutuhkan tergantung pada edisi dan tipe instans yang dipilih untuk peningkatan.
Perform a full backup of the instance	No	200 GB/jam	Berdasarkan kebijakan cadangan penuh, jika cadangan penuh belum dilakukan dalam 36 jam terakhir, sistem akan melakukannya selama peningkatan versi mesin utama untuk menyeimbangkan waktu yang dihabiskan untuk memulihkan cadangan penuh dan menerapkan log transaksi. Kami menyarankan agar Anda secara manual melakukan cadangan penuh sebelum peningkatan, atau memulai peningkatan dalam waktu 36 jam setelah cadangan penuh otomatis selesai. Hal ini mengurangi total waktu peningkatan. Kecepatan backup dapat bervariasi tergantung wilayah dan waktu hari. Untuk perkiraan yang lebih akurat mengenai kinerja backup dan restore, rujuk pada ukuran data dan durasi cadangan penuh terakhir Anda.
Restore the full backup on the target instance	Yes	200 GB/jam	None
Perform an incremental transaction log backup on the source instance	Yes	200 GB/jam	Diperlukan overhead tambahan 2 menit sebelum dan sesudah backup log inkremental untuk tugas seperti persiapan, finalisasi, dan alokasi sumber daya.
Apply the incremental transaction log backup on the target instance	Yes	200 GB/jam	Diperlukan overhead tambahan 2 menit sebelum dan sesudah menerapkan backup log inkremental untuk tugas seperti verifikasi konsistensi backup.
Database recovery	Yes	Umumnya dalam waktu 2 menit	Konsumsi sumber daya: Penerapan log transaksi inkremental merupakan operasi yang intensif sumber daya. Untuk tipe instans kecil (misalnya, 2 vCPU, memori 4 GB), volume log transaksi yang tinggi dapat memperlambat kecepatan pemulihan. Accelerated Database Recovery: RDS untuk SQL Server 2019 dan versi setelahnya menawarkan opsi Accelerated Database Recovery, yang dapat mengurangi waktu yang dibutuhkan untuk langkah ini. Evaluasi apakah akan mengaktifkan opsi ini berdasarkan dokumentasi resmi Microsoft.
Network switchover and connection migration	Yes	10 menit	None

Contoh perkiraan

Instans uji: 4 vCPU, memori 8 GB, dan data 600 GB.

Create and configure new instance: Sekitar 12 menit.
Full backup (opsional): Sekitar 3 jam (600 GB / 200 GB per jam).
Restore full backup ke instans target: Sekitar 3 jam (600 GB / 200 GB per jam).
Incremental transaction log backup pada instans sumber: Sekitar 5 menit ((10 GB / 200 GB per jam) + overhead 2 menit).
Terapkan incremental transaction log backup pada instans target: Sekitar 5 menit ((10 GB / 200 GB per jam) + overhead 2 menit).
Database recovery: Sekitar 2 menit.
Network switchover dan migrasi: Sekitar 10 menit.

Dalam contoh ini, jika cadangan penuh belum dilakukan dalam 36 jam terakhir, total perkiraan waktu adalah sekitar 6 jam 34 menit. Jika tidak, total waktu sekitar 3 jam 34 menit.

Saran peningkatan

Perencanaan maintenance window: Lakukan peningkatan selama periode beban sistem rendah untuk meminimalkan dampak bisnis.
Transaksi jangka panjang: Hindari transaksi jangka panjang, seperti membuat atau membangun ulang indeks dan mengarsipkan data, selama proses peningkatan. Hal ini membantu mencegah perpanjangan waktu database recovery.

Dalam skenario lintas zona waktu, bagaimana cara mengatur waktu switchover peningkatan instans dengan benar?

Skenario: Anda berada di wilayah Dubai, tetapi instans RDS untuk SQL Server Anda diatur ke India Standard Time (IST). Instans tersebut secara fisik berlokasi di wilayah Singapura. Dalam situasi lintas zona waktu yang kompleks ini, Anda perlu mengatur waktu switchover peningkatan dengan benar untuk menghindari gangguan bisnis.
Tujuan: Anda berencana melakukan switchover peningkatan pada pukul 02.00 tanggal 11 Mei 2024, IST (UTC+5:30).
Solusi: Konversikan waktu instans (IST) ke waktu lokal browser Anda (waktu Dubai, GST). Wilayah fisik instans tidak relevan dalam skenario ini. Jika Anda berencana melakukan switchover pada pukul 02.00 tanggal 11 Mei 2024, IST, Anda harus masuk ke konsol RDS dan mengatur waktu switchover pada waktu lokal Dubai Anda, yaitu pukul 00.30 tanggal 11 Mei 2024, GST (UTC+4).
Metode konversi:
1. Konversi IST ke UTC: 02.00 tanggal 11 Mei 2024, IST (UTC+5:30) adalah 20.30 tanggal 10 Mei 2024, UTC.
2. Konversi UTC ke GST: 20.30 tanggal 10 Mei 2024, UTC adalah 00.30 tanggal 11 Mei 2024, GST (UTC+4).

Setelah instans dengan database yang mengaktifkan CDC ditingkatkan, apakah data CDC yang ada dan penangkapan data selanjutnya terpengaruh?

Peningkatan instans mempertahankan data CDC yang ada dan secara otomatis memulai ulang pekerjaan CDC setelah migrasi selesai. Hal ini memastikan bahwa data yang baru dihasilkan terus ditangkap.

API Terkait

Anda juga dapat meningkatkan versi database utama dengan memanggil API. Untuk informasi lebih lanjut, lihat Modify an RDS instance.