ApsaraDB RDS:Tingkatkan versi database

Pilih metode peningkatan

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

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

  Catatan

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

  Edisi Kluster (ESSD dan disk performa premium)

  • Pembatasan replikasi grup: Anda tidak dapat meningkatkan instans Edisi Kluster yang menggunakan MySQL Group Replication (MGR).

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

  • Pembatasan status instans: Status instans harus Running, dan node primer serta sekunder harus dalam kondisi sehat tanpa latensi replikasi.

  • Pembatasan engine: Database dan semua tabelnya harus menggunakan Mesin penyimpanan InnoDB.

  • Instans tidak boleh menggunakan tipe instans yang telah dihentikan.

  Edisi Ketersediaan Tinggi (ESSD dan disk performa premium)

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

  • Batasan status Instans: Status instans harus Running, dan node utama dan sekunder harus sehat dan tidak memiliki latensi replikasi.

  • Pembatasan engine: Database dan semua tabelnya harus menggunakan Mesin penyimpanan InnoDB.

  • Instans tidak boleh menggunakan tipe instans yang telah dihentikan.

  Edisi Ketersediaan Tinggi (disk lokal performa premium)

  • Pembatasan enkripsi: Fitur Enkripsi Data Transparan (TDE) harus dinonaktifkan. Setelah TDE diaktifkan, fitur tersebut tidak dapat dinonaktifkan. Jika TDE diaktifkan pada instans Anda, Anda harus menggunakan Metode 2: Tingkatkan versi database menggunakan DTS.

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

  • Pembatasan status instans: Status instans harus Running, dan node primer serta sekunder harus dalam kondisi sehat tanpa latensi replikasi.

  • Pembatasan jumlah tabel: Jumlah tabel tidak boleh melebihi 1 juta.

  • Pembatasan engine: Database dan semua tabelnya harus menggunakan Mesin penyimpanan InnoDB.

  • Pembatasan tipe instans: Versi database setelah peningkatan harus mendukung tipe instans asli dari instans primer dan instans hanya baca. Instans tidak boleh menggunakan tipe instans yang telah dihentikan. Untuk informasi selengkapnya, lihat Tipe instans primer ApsaraDB RDS untuk MySQL.

  Edisi Dasar (ESSD dan disk performa premium)

  • Pembatasan status instans: Status instans harus Running.

  • Pembatasan engine: Database dan semua tabelnya harus menggunakan Mesin penyimpanan InnoDB.

  • Instans tidak boleh menggunakan tipe instans yang telah dihentikan.

• 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, lalu menggunakan Metode 1: Langsung tingkatkan versi database di Konsol atau Metode 2: Tingkatkan versi database menggunakan DTS.

  Masalah	Solusi
  Status instans bukan Running; misalnya, berstatus 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 tidak diperlukan sebelum peningkatan.
  Beberapa database atau tabel tidak menggunakan engine InnoDB.	Jalankan perintah ALTER TABLE <table_name> engine=InnoDB; untuk beralih ke engine InnoDB.
  Instans menggunakan tipe instans yang telah dihentikan.	Tingkatkan tipe instans sebelum meningkatkan versi database. Untuk informasi selengkapnya, lihat Ubah konfigurasi.
  Versi minor proksi database tidak memenuhi persyaratan.	Tingkatkan versi minor proksi database ke 1.13.41 atau lebih baru. Untuk informasi selengkapnya, lihat Tingkatkan versi minor engine proksi database.
  Tipe penyimpanan instans adalah SSD standar.	Pertama-tama, tingkatkan SSD standar menjadi enterprise SSD (ESSD), lalu tingkatkan versi database.

Untuk meningkatkan versi utama database engine lainnya, lihat topik berikut:

• Tingkatkan versi utama database instans ApsaraDB RDS untuk PostgreSQL

• Tingkatkan versi utama database instans ApsaraDB RDS untuk SQL Server

Metode 1: Langsung tingkatkan versi database di Konsol

Metode 2: Tingkatkan versi database menggunakan DTS

Untuk instans yang tidak mendukung peningkatan langsung dari Konsol, Anda dapat membuat instans baru dengan versi database lebih baru, lalu menggunakan tugas migrasi data DTS untuk memigrasikan data dari instans asli ke instans baru—proses ini secara tidak langsung meningkatkan versi database. Proses ini mencakup langkah-langkah berikut:

1. Buat instans baru

2. Migrasikan data ke instans baru

3. Lepaskan instans asli

Contoh: Anda memiliki instans MySQL 5.7 dengan TDE diaktifkan, yang tidak dapat ditingkatkan langsung dari Konsol. Dalam kasus ini, Anda dapat membuat instans baru yang menjalankan MySQL 8.0, memigrasikan data dari instans asli ke instans baru, dan akhirnya melepas instans asli—hal ini secara tidak langsung meningkatkan versi database.

Lampiran 1: Manfaat peningkatan dari MySQL 5.7 ke MySQL 8.0

• Meningkatkan keamanan dan memberikan fleksibilitas lebih besar dalam manajemen akun.

• Mendukung pembuatan dan manajemen kelompok sumber daya.

• Menyempurnakan fitur Mesin penyimpanan InnoDB.

• Menambah dukungan untuk set karakter baru, tipe data, sintaksis, kunci pencadangan baru, dan flag optimizer_switch.

• Menyempurnakan fungsionalitas JSON dan XML.

• Menyempurnakan fitur pengoptimal.

• Meningkatkan kinerja replikasi.

• Mendukung pembuatan indeks multi-nilai dan optimasi penurunan kondisi turunan.

• Mendukung pembacaan tabel grant MySQL.

• Mendukung kontrol alokasi sumber daya.

Lampiran 2: Manfaat peningkatan dari MySQL 5.6 ke MySQL 5.7

• Menambah fitur seperti manajemen password, penguncian akun, dan koneksi terenkripsi untuk meningkatkan keamanan database.

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

• Meningkatkan skalabilitas engine InnoDB dan kinerja tabel temporary untuk pemuatan data lebih cepat.

• Mendukung 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, dan kinerja database.

• Memperluas rentang set karakter yang didukung, termasuk set karakter GB18030 yang ditentukan oleh standar nasional Tiongkok.

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

• Mengoptimalkan thread dump sumber untuk mengurangi kontensi kunci dan meningkatkan throughput sumber.

• Mengurangi latensi replikasi secara signifikan.

• Menambah database sistem sys, yang menyediakan berbagai metrik dan mengurangi penggunaan penyimpanan, sehingga meningkatkan kegunaan database secara signifikan.

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

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

  J: Untuk memastikan stabilitas layanan, instans dengan disk lokal performa premium ditingkatkan dengan terlebih dahulu meningkatkan node sekunder lalu melakukan alih bencana. Instans dengan ESSD ditingkatkan dengan membuat node baru lalu melakukan alih bencana. Tidak ada risiko serius lainnya. Untuk informasi selengkapnya tentang dampak failover primer/sekunder, lihat Dampak failover primer/sekunder.

• P: Apakah node primer dan sekunder ditingkatkan secara bersamaan?

  J: Saat Anda meningkatkan disk lokal berkinerja-tinggi, instans sekunder ditingkatkan terlebih dahulu, diikuti oleh instans primer.

• P: Bagaimana cara meningkatkan instans Edisi Dasar yang menjalankan MySQL 5.7 dengan SSD standar?

  J: Anda tidak dapat langsung meningkatkan jenis instans ini. Untuk meningkatkan instans Edisi Dasar yang menjalankan MySQL 5.7 dengan SSD standar, Anda harus terlebih dahulu mengubah tipe penyimpanan dari SSD standar menjadi ESSD, lalu meningkatkan versi database.

• P: Apakah template parameter dipertahankan setelah versi database ditingkatkan?

  J: Tergantung. Jika instans menggunakan template parameter sistem sebelum peningkatan, template tersebut secara otomatis dialihkan ke template parameter sistem yang sesuai untuk versi baru. Misalnya, instans yang menggunakan template parameter MySQL_InnoDB_5.7_High-availability_Performance dialihkan 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 dipertahankan setelah peningkatan.

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

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

• P: Apakah versi database mendukung peningkatan otomatis?

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

• P: Dapatkah saya menurunkan versi database?

  J: Tidak, Anda tidak dapat menurunkan versi secara langsung dari Konsol. Untuk menurunkan versi, Anda dapat membeli instans dengan versi sebelumnya dan menggunakan DTS untuk memigrasikan data dari instans dengan versi lebih baru ke instans baru tersebut. Setelah migrasi selesai, Anda dapat melepas instans dengan versi lebih baru. Untuk informasi selengkapnya, lihat Migrasi data antar instans RDS.

• P: Saat saya meningkatkan instans RDS for MySQL dari 5.6 ke 5.7 atau dari 5.7 ke 8.0, peningkatan gagal. Muncul pesan "Instans saat ini memiliki indeks teks penuh dan versi minornya sebelum 20221130. Harap tingkatkan versi minor sebelum menghapus dan membangun ulang indeks teks penuh" atau "Instans saat ini berisi indeks teks penuh yang dibangun di ruang tabel sistem. Harap hapus dan bangun ulang indeks teks penuh yang sesuai sebelum melanjutkan peningkatan." Apa penyebab dan solusinya?

  J: Penyebab dan solusinya adalah sebagai berikut:

  • Penyebab

    Karena masalah historis di MySQL, saat Anda membuat indeks teks penuh pada versi awal MySQL 5.6, indeks tersebut dibangun di ruang tabel sistem. Saat Anda meningkatkan ke versi 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 ketidakaksesan.

    Catatan

    Masalah ini telah diperbaiki di RDS for MySQL 5.6 versi 20221130. Indeks teks penuh kini dibangun 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 versi yang Anda tingkatkan adalah RDS for MySQL 5.6 20221130 atau lebih baru sebelum meningkatkan ke RDS for MySQL 5.7. Jika Anda menggunakan versi sebelumnya, tingkatkan terlebih dahulu ke versi terbaru RDS for MySQL 5.6.

    1. Berdasarkan nama tabel dalam prompt, hapus indeks teks penuh yang dibangun 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 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 dibangun 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 dibangun 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);

• P: Saat saya meningkatkan instans RDS for MySQL dari 5.7 ke 8.0, muncul error 267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='. Bagaimana cara menanganinya?

  J: 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 lalu meningkatkan 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, sehingga menghasilkan error.

• P: Apakah waktu koneksi sementara untuk peningkatan versi utama selalu 15 detik, terlepas dari apakah instans hanya baca ada atau tidak?

  J: Ya, demikian. Kami menyarankan agar Anda melakukan peningkatan selama jam sepi.

Operasi API terkait