ApsaraDB RDS：Peningkatan Versi Utama Database

Pilih metode peningkatan

Kedua Metode 1: Tingkatkan versi database langsung di Konsol dan Metode 2: Tingkatkan versi database menggunakan DTS didukung untuk semua versi utama MySQL, termasuk peningkatan dari MySQL 5.5 ke 5.6, 5.6 ke 5.7, dan 5.7 ke 8.0. Sebelum meningkatkan database, pilih metode yang sesuai berdasarkan informasi berikut:

• Jika instans Anda termasuk dalam salah satu dari empat kategori berikut dan konfigurasinya memenuhi persyaratan, gunakan Metode 1: Tingkatkan versi database langsung di Konsol.

  Catatan

  Instans tanpa server tidak mendukung peningkatan langsung dari Konsol. Anda harus menggunakan Metode 2: Tingkatkan versi database menggunakan DTS.

  Edisi Kluster (ESSD dan disk performa premium)

  • Batasan Replikasi Grup: Anda tidak dapat meningkatkan instans Edisi Kluster yang menggunakan Replikasi Grup MySQL (MGR).

  • Batasan Proksi Database (jika berlaku): Versi minor proksi database harus 1.13.41 atau lebih baru.

  • Batasan Status Instans: Instans harus dalam status Running. Node primer dan sekunder harus sehat dan tidak memiliki latensi replikasi.

  • Batasan Mesin: Database dan semua tabelnya harus menggunakan mesin penyimpanan InnoDB.

  • Instans tidak boleh menggunakan tipe instans yang dihentikan.

  Edisi Ketersediaan Tinggi (ESSD dan disk performa premium)

  • Batasan Proksi Database (jika berlaku): Versi minor proksi database harus 1.13.41 atau lebih baru.

  • Batasan Status Instans: Instans harus dalam status Running. Node primer dan sekunder harus sehat dan tidak memiliki latensi replikasi.

  • Batasan Mesin: Database dan semua tabelnya harus menggunakan mesin penyimpanan InnoDB.

  • Instans tersebut tidak boleh menggunakan tipe instans yang sudah ditinggalkan.

  Edisi Ketersediaan Tinggi (disk lokal performa premium)

  • Batasan Enkripsi: Fitur Enkripsi Data Transparan (TDE) harus dinonaktifkan. Jika TDE diaktifkan pada instans Anda, Anda harus menggunakan Metode 2: Tingkatkan versi database menggunakan DTS.

  • Batasan Proksi Database (jika berlaku): Versi minor proksi database harus 1.13.41 atau lebih baru.

  • Batasan Status Instans: Instans harus dalam status Running. Node primer dan sekunder harus sehat dan tidak memiliki latensi replikasi.

  • Batasan Jumlah Tabel: Jumlah tabel tidak boleh melebihi 1 juta.

  • Batasan Mesin: Database dan semua tabelnya harus menggunakan mesin penyimpanan InnoDB.

  • Batasan Tipe Instans: Versi database setelah peningkatan harus mendukung tipe instans asli dari instans primer dan instans hanya baca. Instans tersebut tidak boleh menggunakan tipe instans yang sudah ditinggalkan. Untuk informasi lebih lanjut, lihat Tipe Instans ApsaraDB RDS untuk MySQL Primer.

  Edisi Dasar (ESSD dan disk performa premium)

  • Batasan Status Instans: Instans harus dalam status Running.

  • Batasan Mesin: Database dan semua tabelnya harus menggunakan mesin penyimpanan InnoDB.

  • Instans tidak boleh menggunakan tipe instans usang.

• Jika instans Anda tidak termasuk dalam salah satu dari empat kategori sebelumnya atau jika TDE diaktifkan, gunakan Metode 2: Tingkatkan versi database menggunakan DTS.

• Jika instans Anda termasuk dalam salah satu dari empat kategori sebelumnya tetapi konfigurasinya tidak memenuhi persyaratan, Anda dapat memodifikasi konfigurasi seperti yang dijelaskan dalam tabel berikut. Kemudian, Anda dapat menggunakan Metode 1: Tingkatkan versi database langsung di Konsol atau Metode 2: Tingkatkan versi database menggunakan DTS.

  Masalah	Solusi
  Instans berada dalam status selain Running, seperti Restarting.	Tunggu hingga tugas saat ini selesai sebelum meningkatkan versi database.
  Jumlah tabel pada instans Edisi Ketersediaan Tinggi dengan disk lokal performa premium melebihi 1 juta.	Hapus tabel yang berlebihan sebelum peningkatan.
  Beberapa database atau tabel tidak menggunakan mesin InnoDB.	Jalankan perintah ALTER TABLE <table_name> engine=InnoDB; untuk beralih ke mesin InnoDB.
  Instans menggunakan tipe instans yang sudah ditinggalkan.	Tingkatkan tipe instans sebelum meningkatkan versi database. Untuk informasi lebih lanjut, lihat Ubah Konfigurasi Instans.
  Versi minor proksi database tidak memenuhi persyaratan.	Tingkatkan versi minor proksi database ke 1.13.41 atau lebih baru. Untuk informasi lebih lanjut, lihat Tingkatkan Versi Minor Mesin Proksi Database.
  Tipe penyimpanan instans adalah SSD standar.	Pertama, tingkatkan SSD standar ke SSD Perusahaan (ESSD), lalu tingkatkan versi database.

Untuk meningkatkan versi utama database dari mesin database lainnya, lihat topik-topik berikut:

• Tingkatkan versi utama database dari instans ApsaraDB RDS untuk PostgreSQL

• Tingkatkan versi utama database dari instans ApsaraDB RDS untuk SQL Server

Metode 1: Tingkatkan versi database secara langsung di konsol

Metode 2: Tingkatkan versi database menggunakan DTS

Untuk instans yang tidak mendukung peningkatan langsung melalui Konsol, Anda dapat membuat instans baru dengan versi database yang lebih baru. Selanjutnya, gunakan tugas migrasi data DTS untuk memigrasi data dari instans asli ke instans baru. Proses ini secara tidak langsung meningkatkan versi database dan mencakup langkah-langkah berikut:

1. Buat Instans Baru

2. Migrasikan Data ke Instans Baru

3. Lepaskan Instans Asli

Contoh: Misalkan Anda memiliki instans MySQL 5.7 dengan Enkripsi Data Transparan (TDE) diaktifkan, yang tidak dapat ditingkatkan langsung melalui Konsol. Dalam situasi ini, Anda dapat membuat instans baru yang menjalankan MySQL 8.0, migrasikan data dari instans asli ke instans baru, dan akhirnya lepaskan instans asli. Ini akan secara tidak langsung menaikkan versi database.

Lampiran 1: Manfaat peningkatan dari MySQL 5.7 ke MySQL 8.0

• Meningkatkan keamanan serta memberikan fleksibilitas lebih besar dalam pengelolaan akun.

• Menambahkan dukungan untuk pembuatan dan pengelolaan kelompok sumber daya.

• Memperkuat fitur mesin penyimpanan InnoDB.

• Menyediakan dukungan untuk set karakter baru, tipe data, sintaksis, kunci cadangan baru, dan flag optimizer_switch.

• Memperluas fungsionalitas JSON dan XML.

• Memperkuat kemampuan pengoptimal.

• Meningkatkan kinerja replikasi.

• Menambahkan dukungan untuk pembuatan indeks bernilai banyak dan optimasi penurunan kondisi turunan.

• Menyediakan dukungan untuk pembacaan tabel grant MySQL.

• Menambahkan kontrol terhadap alokasi sumber daya.

Lampiran 2: Manfaat peningkatan dari MySQL 5.6 ke MySQL 5.7

• Menambahkan fitur seperti manajemen kata sandi, penguncian akun, dan koneksi terenkripsi untuk meningkatkan keamanan database.

• Mendukung operasi Online DDL, termasuk mengganti nama indeks menggunakan RENAME INDEX.

• Meningkatkan skalabilitas engine InnoDB dan performa tabel sementara, sehingga mempercepat pemuatan data.

• Menyediakan dukungan untuk JSON.

• Mendukung Index Condition Pushdown (ICP) untuk tabel partisi dan indeks spasial InnoDB baru.

• Mengoptimalkan sebagian besar parser, pengoptimal, dan model biaya untuk meningkatkan kemampuan pemeliharaan, skalabilitas, serta performa database.

• Memperluas jangkauan set karakter yang didukung, termasuk set karakter GB18030 sesuai standar nasional Tiongkok.

• Menyediakan plugin parser teks lengkap ngram, yang mendukung bahasa Tiongkok, Jepang, dan Korea.

• Mengoptimalkan utas dump sumber untuk mengurangi konten kunci dan meningkatkan throughput sumber.

• Secara signifikan mengurangi latensi replikasi.

• Menambahkan sys system database, yang menyediakan berbagai metrik, mengurangi penggunaan penyimpanan, serta meningkatkan kegunaan database secara keseluruhan.

Lampiran 3: Perbedaan fitur antara MySQL 8.0 dan MySQL 5.7

Lampiran 4: Perbedaan fitur antara MySQL 5.7 dan MySQL 5.6

Lampiran 5: Perbedaan fitur antara MySQL 5.5 dan MySQL 5.6

FAQ

• Q: Mengapa terjadi failover pada instans selama peningkatan? Apakah ada risiko serius lainnya?

  A: Untuk memastikan stabilitas layanan, instans dengan disk lokal berperforma tinggi ditingkatkan dengan meningkatkan node sekunder terlebih dahulu, lalu melakukan failover. Instans dengan ESSD ditingkatkan dengan membuat node baru dan kemudian melakukan failover. Tidak ada risiko serius lainnya. Untuk informasi lebih lanjut tentang dampak dari failover utama/sekunder, lihat Dampak dari failover utama/sekunder.

• Q: Apakah node utama dan sekunder ditingkatkan pada saat yang sama?

  A: Saat Anda menaikkan versi disk lokal berkinerja-tinggi, instans sekunder ditingkatkan terlebih dahulu, diikuti oleh instans utama.

• Q: Bagaimana cara saya menaikkan versi instans Edisi Dasar yang menjalankan MySQL 5.7 dengan SSD standar?

  A: Anda tidak dapat langsung menaikkan versi jenis instans ini. Untuk menaikkan versi instans Edisi Dasar yang menjalankan MySQL 5.7 dengan SSD standar, Anda harus terlebih dahulu mengubah tipe penyimpanan dari SSD standar ke ESSD, dan kemudian meningkatkan versi database.

• Q: Apakah template parameter tetap ada setelah versi database ditingkatkan?

  A: Itu tergantung. Jika instans menggunakan template parameter sistem sebelum peningkatan, maka secara otomatis akan beralih ke template parameter sistem yang sesuai untuk versi baru. Sebagai contoh, instans yang menggunakan template parameter MySQL_InnoDB_5.7_High-availability_Performance akan beralih ke template parameter MySQL_InnoDB_8.0_High-availability_Performance setelah peningkatan dari MySQL 5.7 ke 8.0. Namun, jika instans menggunakan template parameter kustom, template parameter tersebut tidak akan dipertahankan setelah peningkatan.

• Q: Dapatkah saya memodifikasi instans selama peningkatan versi database?

  A: Tidak, Anda tidak bisa. Anda hanya dapat melakukan operasi lain pada instans setelah peningkatan selesai.

• Q: Apakah versi database mendukung peningkatan otomatis?

  A: Tidak, tidak mendukung. Peningkatan otomatis versi utama tidak didukung.

• Q: Dapatkah saya menurunkan spesifikasi versi database?

  A: Tidak, Anda tidak dapat langsung menurunkan versi dari Konsol. Untuk menurunkan versi, Anda dapat membeli instans dengan versi sebelumnya dan menggunakan DTS untuk memigrasikan data dari instans dengan versi terbaru ke instans baru. Setelah migrasi selesai, Anda dapat melepaskan instans dengan versi terbaru. Untuk informasi lebih lanjut, lihat Migrasi data antara instans RDS.

• Q: Ketika saya menaikkan versi instans RDS for MySQL dari 5.6 ke 5.7 atau dari 5.7 ke 8.0, peningkatan gagal. Pesan yang muncul adalah "Instans saat ini memiliki indeks teks penuh dan versi minornya lebih awal dari 20221130. Harap tingkatkan versi minor sebelum menghapus dan membangun ulang indeks teks penuh" atau "Instans saat ini berisi indeks teks penuh yang dibuat di ruang tabel sistem. Harap hapus dan bangun ulang indeks teks penuh yang sesuai sebelum melanjutkan dengan peningkatan." Apa penyebab dan solusinya?

  A: Penyebab dan solusinya adalah sebagai berikut:

  • Penyebab

    Karena masalah historis di MySQL, ketika Anda membuat indeks teks penuh pada versi awal MySQL 5.6, indeks tersebut dibuat di ruang tabel sistem. Saat Anda menaikkan versi ke 5.7 atau 8.0, indeks teks penuh di ruang tabel sistem dapat menyebabkan korupsi ruang tabel. Oleh karena itu, Anda harus menyelesaikan masalah ini sebelum peningkatan untuk mencegah korupsi data dan ketidakmampuan akses.

    Catatan

    Masalah ini telah diperbaiki di RDS for MySQL 5.6 versi 20221130. Indeks teks penuh sekarang dibuat di ruang tabel terpisah.

  • Solusi

    Penting

    Indeks teks penuh pada versi awal RDS for MySQL 5.6 dibuat di ruang tabel sistem. Oleh karena itu, pastikan bahwa versi yang Anda tingkatkan adalah RDS for MySQL 5.6 20221130 atau lebih baru sebelum Anda menaikkan versi ke RDS for MySQL 5.7. Jika Anda menggunakan versi lebih lama, tingkatkan terlebih dahulu ke versi terbaru RDS for MySQL 5.6.

    1. Berdasarkan nama tabel dalam prompt, hapus indeks teks penuh yang dibuat di ruang tabel sistem.

       # Hapus indeks teks penuh.
       ALTER TABLE $table_name DROP INDEX $fts_name;

    2. Buat ulang indeks teks penuh.

       # Buat ulang indeks teks penuh.
       ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;

    3. Setelah Anda membuat indeks, Anda dapat menjalankan pernyataan SQL berikut untuk memeriksa indeks teks penuh pada instans saat ini. Pernyataan ini mengembalikan indeks teks penuh apa pun yang dibuat di ruang tabel sistem. Jika kueri mengembalikan hasil kosong, peningkatan dari RDS for MySQL 5.6 ke RDS for MySQL 5.7 tidak akan gagal karena masalah ini.

       # Kueri untuk indeks teks penuh yang dibuat di ruang tabel sistem.
       SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);

• Q: Ketika saya menaikkan versi instans RDS for MySQL dari 5.7 ke 8.0, kesalahan 267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '=' dilaporkan. Bagaimana cara saya menanganinya?

  A: Periksa set karakter dan aturan pengurutan di MySQL. Jika Anda menggunakan utf8mb4_general_ci, jalankan pernyataan SQL berikut untuk mengubahnya menjadi utf8mb4_0900_ai_ci.

  # Ubah set karakter dan aturan pengurutan database.
  ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # Ubah set karakter dan aturan pengurutan tabel.
  ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
  # Ubah set karakter dan aturan pengurutan bidang.
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

  Jika Anda membuat tabel dengan aturan pengurutan utf8mb4_general_ci di MySQL 5.7 dan kemudian menaikkan versi ke MySQL 8.0, sistem menggunakan utf8mb4_0900_ai_ci sebagai aturan pengurutan default. Jika Anda menjalankan kueri yang membandingkan kolom yang menggunakan utf8mb4_general_ci dengan kolom yang menggunakan utf8mb4_0900_ai_ci, MySQL tidak dapat memproses dua aturan pengurutan yang berbeda, yang menghasilkan kesalahan.

• Q: Apakah waktu koneksi sementara selama peningkatan versi utama selalu 30 hingga 60 detik, terlepas dari apakah ada instans hanya baca?

  A: Ya, benar. Kami sarankan Anda melakukan peningkatan selama jam-jam sepi.

Operasi API terkait