Meningkatkan versi mayor klaster DB Amazon Aurora MySQL - Amazon Aurora
Upgrade dari Aurora MySQL versi 2 ke versi 3Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL Pra-pemeriksaan peningkatan versi mayor untuk Aurora MySQLJalur peningkatan versi mayor Aurora MySQLCara kerja peningkatan di tempat terhadap versi mayor Aurora MySQLDeployment Blue/GreenCara melakukan peningkatan di tempatBagaimana peningkatan di tempat memengaruhi grup parameter untuk klasterPerubahan pada properti klaster di antara versi Aurora MySQLPeningkatan besar di tempat untuk basis data globalBacktrack pertimbanganTutorial peningkatan di tempat Aurora MySQLMenemukan alasan kegagalan peningkatanPemecahan masalah untuk peningkatan di tempat Aurora MySQLPembersihan pasca-peningkatan untuk Aurora MySQL versi 3

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Meningkatkan versi mayor klaster DB Amazon Aurora MySQL

Dalam nomor versi MySQL Aurora seperti 2.12.1, 2 mewakili versi utama. Aurora MySQL versi 2 kompatibel dengan MySQL 5.7. Aurora MySQL versi 3 kompatibel dengan MySQL 8.0.

Peningkatan antarversi mayor memerlukan perencanaan dan pengujian yang lebih ekstensif daripada versi minor. Prosesnya bisa memakan waktu yang cukup lama. Setelah peningkatan selesai, Anda mungkin juga memiliki pekerjaan lanjutan yang harus dilakukan. Misalnya, ini mungkin terjadi karena perbedaan kompatibilitas SQL atau cara kerja fitur terkait MySQL tertentu. Atau, ini mungkin terjadi karena pengaturan parameter yang berbeda antara versi lama dan baru.

Upgrade dari Aurora MySQL versi 2 ke versi 3

Jika Anda memiliki klaster yang kompatibel dengan MySQL 5.7 dan ingin meningkatkan-nya ke klaster yang kompatibel dengan MySQL 8.0, Anda dapat melakukannya dengan menjalankan proses peningkatan pada klaster itu sendiri. Peningkatan semacam ini adalah peningkatan di tempat, berbeda dengan peningkatan yang Anda lakukan dengan membuat klaster baru. Teknik ini mempertahankan titik akhir dan karakteristik lain yang sama dari klaster. Peningkatan ini relatif cepat karena tidak memerlukan penyalinan semua data Anda ke volume klaster baru. Stabilitas ini membantu meminimalkan perubahan konfigurasi dalam aplikasi Anda. Hal ini juga membantu mengurangi jumlah pengujian untuk klaster yang ditingkatkan. Hal ini karena jumlah instans DB dan kelas instansnya semua tetap sama.

Mekanisme peningkatan di tempat mengharuskan klaster DB Anda dinonaktifkan saat operasi berlangsung. Aurora melakukan penonaktifan bersih dan menyelesaikan operasi yang tertunda seperti rollback transaksi dan pembersihan undo. Untuk informasi selengkapnya, lihat Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL.

Metode peningkatan di tempat ini praktis karena mudah dilakukan dan meminimalkan perubahan konfigurasi pada aplikasi terkait. Misalnya, tingkatkan di tempat mempertahankan titik akhir dan kumpulan instans DB untuk klaster Anda. Namun, waktu yang diperlukan untuk peningkatan di tempat dapat bervariasi tergantung pada properti skema Anda dan seberapa sibuk klasternya. Jadi, tergantung pada kebutuhan cluster Anda, Anda dapat memilih di antara teknik upgrade:

Untuk informasi umum tentang Aurora MySQL versi 3 dan fitur-fiturnya yang baru, lihat Aurora MySQL versi 3 yang kompatibel dengan MySQL 8.0.

Untuk detail tentang merencanakan peningkatan, lihat Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL dan Cara melakukan peningkatan di tempat.

Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL

Untuk membantu Anda memutuskan waktu dan pendekatan yang tepat untuk meningkatkan, Anda dapat mempelajari perbedaan antara Aurora MySQL versi 3 dan lingkungan Anda saat ini:

Anda juga dapat menemukan lebih banyak pertimbangan dan tips peningkatan khusus MySQL dalam Changes in MySQL 8.0 dalam Panduan Referensi MySQL. Misalnya, Anda dapat menggunakan perintah mysqlcheck --check-upgrade untuk menganalisis basis data Aurora MySQL yang ada dan mengidentifikasi potensi masalah peningkatan.

catatan

Sebaiknya gunakan kelas instans DB yang lebih besar saat meningkatkan ke Aurora MySQL versi 3 menggunakan teknik peningkatan atau pemulihan snapshot di tempat. Contohnya adalah db.r5.24xlarge dan db.r6g.16xlarge. Hal ini membantu menyelesaikan proses peningkatan lebih cepat dengan menggunakan sebagian besar kapasitas CPU yang tersedia pada instans DB. Anda dapat mengubah ke kelas instans DB yang Anda inginkan setelah peningkatan versi mayor selesai.

Setelah Anda menyelesaikan peningkatan itu sendiri, Anda dapat mengikuti prosedur pasca-peningkatan dalam Pembersihan pasca-peningkatan untuk Aurora MySQL versi 3. Terakhir, uji fungsionalitas dan performa aplikasi Anda.

Jika Anda mengonversi dari RDS dari MySQL atau MySQL komunitas, ikuti prosedur migrasi yang dijelaskan di. Memigrasikan data ke klaster DB Amazon Aurora MySQL Dalam beberapa kasus, Anda mungkin menggunakan replikasi log biner untuk menyinkronkan data Anda dengan klaster Aurora MySQL versi 3 sebagai bagian dari migrasi. Jika demikian, sistem sumber harus menjalankan versi yang kompatibel dengan cluster DB target Anda.

Untuk memastikan aplikasi dan prosedur administrasi Anda berjalan dengan lancar setelah meningkatkan klaster di antara versi mayor, lakukan beberapa perencanaan dan persiapan sebelumnya. Untuk melihat jenis kode manajemen apa yang akan diperbarui untuk AWS CLI skrip atau aplikasi berbasis API RDS, lihat. Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster Lihat juga Perubahan pada properti klaster di antara versi Aurora MySQL.

Untuk mempelajari masalah apa yang mungkin Anda temui selama peningkatan, lihatPemecahan masalah untuk peningkatan di tempat Aurora MySQL. Untuk masalah yang mungkin menyebabkan peningkatan memakan waktu lama, Anda dapat menguji kondisi tersebut terlebih dahulu dan memperbaikinya.

catatan

Upgrade di tempat melibatkan mematikan cluster DB Anda saat operasi berlangsung. Aurora MySQL melakukan shutdown bersih dan menyelesaikan operasi luar biasa seperti undo purge. Upgrade mungkin memakan waktu lama jika ada banyak catatan yang akan diurungkan untuk dibersihkan. Kami merekomendasikan melakukan peningkatan hanya setelah panjang daftar riwayat (HLL) rendah. Nilai yang dapat diterima secara umum untuk HLL adalah 100.000 atau kurang. Untuk informasi lebih lanjut, lihat posting blog ini.

Mensimulasikan peningkatan dengan mengkloning cluster DB Anda

Anda dapat memeriksa kompatibilitas aplikasi, performa, prosedur pemeliharaan, dan pertimbangan serupa untuk klaster yang ditingkatkan. Untuk melakukannya, Anda dapat melakukan simulasi peningkatan sebelum melakukan peningkatan yang sebenarnya. Teknik ini dapat sangat berguna untuk klaster produksi. Di sini, penting untuk meminimalkan waktu henti dan menyiapkan klaster yang telah ditingkatkan agar siap digunakan segera setelah peningkatan selesai.

Gunakan langkah-langkah berikut:

  1. Membuat klon dari klaster asli. Ikuti prosedur dalam Mengkloning volume untuk klaster DB Amazon Aurora.

  2. Siapkan satu set instans DB penulis dan pembaca yang serupa seperti di klaster asli.

  3. Melakukan peningkatan di tempat terhadap klaster yang dikloning. Ikuti prosedur dalam Cara melakukan peningkatan di tempat.

    Mulai peningkatan segera setelah membuat klon. Dengan demikian, volume klaster masih identik dengan status klaster aslinya. Jika klon dalam keadaan idle sebelum Anda melakukan peningkatan, Aurora akan melakukan proses pembersihan basis data di latar belakang. Dalam hal ini, tingkatkan klon bukanlah simulasi yang akurat untuk peningkatan klaster asli.

  4. Uji kompatibilitas aplikasi, performa, prosedur administrasi, dan sebagainya, menggunakan klaster yang dikloning.

  5. Jika Anda mengalami masalah apa pun, sesuaikan rencana peningkatan Anda untuk mengantisipasinya. Misalnya, sesuaikan kode aplikasi apa pun agar kompatibel dengan kumpulan fitur dari versi yang lebih tinggi. Perkirakan berapa lama waktu yang dibutuhkan untuk peningkatan berdasarkan jumlah data di klaster Anda. Anda juga dapat memilih untuk menjadwalkan peningkatan pada saat klaster tidak sibuk.

  6. Setelah Anda yakin bahwa aplikasi dan beban kerja Anda berfungsi dengan baik dengan klaster uji, Anda dapat melakukan peningkatan di tempat untuk klaster produksi Anda.

  7. Berusahalah untuk meminimalkan total waktu henti klaster Anda selama peningkatan versi mayor. Untuk melakukannya, pastikan bahwa beban kerja di klaster rendah atau nol pada saat peningkatan. Secara khusus, pastikan bahwa tidak ada transaksi berjalan lama yang sedang berlangsung saat Anda memulai peningkatan.

Menggunakan teknik upgrade biru-hijau

Anda juga dapat membuat penyebaran biru/hijau yang menjalankan cluster lama dan baru. side-by-side Di sini, Anda mereplikasi data dari klaster lama ke klaster baru hingga Anda siap untuk mengambil alih klaster baru. Untuk detailnya, lihat Menggunakan Deployment Blue/Green Amazon RDS untuk pembaruan basis data.

Pra-pemeriksaan peningkatan versi mayor untuk Aurora MySQL

MySQL 8.0 menyertakan sejumlah inkompatibilitas dengan MySQL 5.7. Inkompatibilitas ini dapat menyebabkan masalah selama peningkatan dari Aurora MySQL versi 2 ke versi 3. Beberapa persiapan mungkin diperlukan di basis data Anda agar peningkatan berhasil.

Saat Anda memulai peningkatan dari Aurora MySQL versi 2 ke versi 3, Amazon Aurora akan menjalankan pra-pemeriksaan secara otomatis untuk mendeteksi inkompatibilitas ini.

Pra-pemeriksaan ini wajib dilakukan. Anda tidak dapat memilih untuk melewatinya. Pra-pemeriksaan menyediakan manfaat berikut:

  • Hal ini memungkinkan Anda menghindari waktu henti yang tidak direncanakan selama peningkatan.

  • Jika ada inkompatibilitas, Amazon Aurora akan mencegah peningkatan dan menyediakan log bagi Anda untuk mempelajarinya. Kemudian, Anda dapat menggunakan log ini untuk menyiapkan basis data Anda untuk peningkatan ke versi 3 dengan mengurangi inkompatibilitas. Untuk informasi terperinci tentang cara mengatasi inkompatibilitas, lihat Preparing your installation for upgrade dalam dokumentasi MySQL dan Upgrading to MySQL 8.0? Inilah yang perlu Anda ketahui... di Blog MySQL Server.

    Untuk informasi tentang peningkatan ke MySQL 8.0, lihat Upgrading to MySQL 8.0 dalam dokumentasi MySQL.

Sebagian pra-pemeriksaan disertakan dengan MySQL dan sebagian lainnya dibuat secara khusus oleh tim Aurora. Untuk informasi tentang pra-pemeriksaan yang disediakan oleh MySQL, lihat Utilitas pemeriksaan peningkatan.

Pra-pemeriksaan berjalan sebelum instans DB dihentikan untuk peningkatan, sehingga instans tersebut tidak akan menyebabkan waktu henti ketika berjalan. Jika pra-pemeriksaan menemukan inkompatibilitas, Aurora secara otomatis membatalkan peningkatan sebelum instans DB dihentikan. Aurora juga menghasilkan peristiwa untuk inkompatibilitas. Untuk informasi selengkapnya tentang peristiwa Amazon Aurora, lihat Bekerja dengan pemberitahuan peristiwa Amazon RDS.

Aurora mencatat informasi terperinci tentang setiap inkompatibilitas dalam file log PrePatchCompatibility.log. Dalam kebanyakan kasus, entri log berisi tautan ke dokumentasi MySQL untuk mengoreksi inkompatibilitas. Untuk informasi selengkapnya tentang format file log, lihat Melihat dan mencantumkan file log basis data.

Karena sifatnya, pra-pemeriksaan akan menganalisis objek di basis data Anda. Analisis ini mengakibatkan konsumsi sumber daya dan menambah waktu penyelesaian peningkatan.

Pra-pemeriksaan peningkatan MySQL komunitas

Berikut ini adalah daftar umum inkompatibilitas antara MySQL 5.7 dan 8.0:

  • Klaster DB Anda yang kompatibel dengan MySQL 5.7 tidak boleh menggunakan fitur yang tidak didukung di MySQL 8.0.

    Untuk informasi selengkapnya, lihat Features removed in MySQL 8.0 dalam dokumentasi MySQL.

  • Tidak boleh ada pelanggaran terkait kata kunci atau kata yang digunakan sistem. Beberapa kata kunci mungkin dicadangkan di MySQL 8.0 yang sebelumnya tidak dicadangkan.

    Untuk informasi selengkapnya, lihat Keywords and reserved words dalam dokumentasi MySQL.

  • Untuk dukungan Unicode yang lebih baik, pertimbangkan untuk mengonversi objek yang menggunakan set karakter utf8mb3 untuk menggunakan set karakter utf8mb4. Set karakter utf8mb3 sudah tidak digunakan lagi. Selain itu, pertimbangkan untuk menggunakan utf8mb4 untuk referensi set karakter, bukan utf8, karena saat ini utf8 adalah alias untuk set karakter utf8mb3.

    Untuk informasi selengkapnya, lihat The utf8mb3 character set (3-byte UTF-8 unicode encoding) dalam dokumentasi MySQL.

  • Tidak boleh ada tabel InnoDB dengan format baris non-default.

  • Tidak boleh ada atribut jenis panjang ZEROFILL atau display.

  • Tidak boleh ada tabel partisi yang menggunakan mesin penyimpanan yang tidak memiliki dukungan partisi native.

  • Tidak boleh ada tabel di basis data sistem mysql MySQL 5.7 yang memiliki nama yang sama dengan tabel yang digunakan oleh kamus data MySQL 8.0.

  • Tidak boleh ada tabel yang menggunakan jenis atau fungsi data yang usang.

  • Tidak boleh ada nama pembatasan kunci asing yang lebih panjang dari 64 karakter.

  • Tidak boleh ada mode SQL usang yang ditentukan dalam pengaturan variabel sistem sql_mode.

  • Tidak boleh ada tabel atau prosedur tersimpan dengan elemen kolom ENUM atau SET individual dengan panjang melebihi 255 karakter.

  • Tidak boleh ada partisi tabel yang berada dalam ruang tabel InnoDB bersama.

  • Tidak boleh ada referensi sirkular di jalur file data ruang tabel.

  • Tidak boleh ada kueri dan definisi program tersimpan yang menggunakan pengualifikasi ASC atau DESC untuk klausa GROUP BY.

  • Tidak boleh ada variabel sistem yang dihapus, dan variabel sistem harus menggunakan nilai default baru untuk MySQL 8.0.

  • Tidak boleh ada nilai nol (0) untuk date, datetime, atau timestamp.

  • Tidak boleh ada inkonsistensi skema yang dihasilkan dari penghapusan atau kerusakan file.

  • Tidak boleh ada nama tabel yang berisi string karakter FTS.

  • Tidak boleh ada tabel InnoDB yang dimiliki oleh mesin yang berbeda.

  • Tidak boleh ada nama tabel atau skema yang tidak valid untuk MySQL 5.7.

Untuk informasi tentang peningkatan ke MySQL 8.0, lihat Upgrading to MySQL 8.0 dalam dokumentasi MySQL.

Pra-pemeriksaan peningkatan Aurora MySQL

Aurora MySQL memiliki persyaratan spesifiknya sendiri saat meningkatkan dari versi 2 ke versi 3:

  • Tidak boleh ada sintaks SQL yang sudah berhenti digunakan, seperti SQL_CACHE, SQL_NO_CACHE, dan QUERY_CACHE, dalam tampilan, rutinitas, pemicu, dan peristiwa.

  • Tidak boleh ada kolom FTS_DOC_ID yang ada di tabel apa pun tanpa indeks FTS.

  • Tidak boleh ada ketidakcocokan definisi kolom antara kamus data InnoDB dan definisi tabel yang sebenarnya.

  • Semua nama basis data dan tabel harus huruf kecil ketika parameter lower_case_table_names diatur ke 1.

  • Peristiwa dan pemicu tidak boleh memiliki pendefinisi yang hilang atau kosong atau konteks pembuatan yang tidak valid.

  • Semua nama pemicu dalam basis data harus unik.

  • Pemulihan DDL dan DDL cepat tidak didukung di Aurora MySQL versi 3. Tidak boleh ada artefak dalam basis data yang terkait dengan fitur-fitur ini.

  • Tabel dengan format baris COMPACT atau REDUNDANT tidak dapat memiliki indeks yang lebih besar dari 767 byte.

  • Panjang awalan indeks yang ditentukan pada kolom teks tiny tidak boleh melebihi 255 byte. Dengan set karakter utf8mb4, panjang awalan yang didukung dibatasi hingga 63 karakter.

    Panjang awalan yang lebih besar diizinkan di MySQL 5.7 menggunakan parameter innodb_large_prefix . Parameter ini tidak digunakan lagi di MySQL 8.0.

  • Tidak boleh ada inkonsistensi metadata InnoDB dalam tabel mysql.host.

  • Tidak boleh ada inkompatibilitas jenis data kolom dalam tabel sistem.

  • Tidak boleh ada transaksi XA dalam status prepared.

  • Nama kolom dalam tampilan tidak boleh lebih panjang dari 64 karakter.

  • Karakter khusus dalam prosedur tersimpan tidak boleh tidak konsisten.

  • Tabel tidak boleh memiliki inkonsistensi jalur file data.

Jalur peningkatan versi mayor Aurora MySQL

Tidak semua jenis atau versi klaster Aurora MySQL dapat menggunakan mekanisme peningkatan di tempat. Anda dapat mempelajari jalur peningkatan yang sesuai untuk setiap klaster Aurora MySQL dengan melihat tabel berikut.

Jenis klaster DB Aurora MySQL Apakah klaster dapat menggunakan peningkatan di tempat? Tindakan

Klaster yang disediakan Aurora MySQL 2.0 atau versi lebih tinggi

Ya

Peningkatan di tempat didukung untuk klaster yang kompatibel dengan Aurora MySQL 5.7.

Untuk informasi tentang peningkatan ke Aurora MySQL versi 3, lihat Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL dan Cara melakukan peningkatan di tempat.

Klaster yang disediakan Aurora MySQL 3.01.0 atau versi lebih tinggi

N/A

Gunakan prosedur peningkatan versi minor untuk peningkatan di antara Aurora MySQL versi 3.

Klaster Aurora Serverless v1

N/A

Saat ini, Aurora Serverless v1 didukung untuk Aurora MySQL hanya pada versi 2.

Klaster Aurora Serverless v2

N/A

 Saat ini, Aurora Serverless v2 didukung untuk Aurora MySQL hanya pada versi 3.

Klaster dalam basis data global Aurora

Ya

Untuk meningkatkan Aurora MySQL dari versi 2 ke versi 3, ikuti prosedur untuk melakukan peningkatan di tempat untuk klaster di basis data global Aurora. Lakukan peningkatan pada klaster global. Aurora meningkatkan klaster primer dan semua klaster sekunder dalam basis data global pada saat yang sama.

Jika Anda menggunakan API AWS CLI atau RDS, panggil modify-global-cluster perintah atau ModifyGlobalCluster operasi alih-alih modify-db-cluster atauModifyDBCluster.

Anda tidak dapat melakukan peningkatan di tempat dari Aurora MySQL versi 2 ke versi 3 jika parameter lower_case_table_names diaktifkan. Untuk informasi selengkapnya, lihat Peningkatan versi utama.

Klaster kueri paralel

Ya

Anda dapat melakukan peningkatan di tempat. Dalam hal ini, pilih 2.09.1 atau lebih tinggi untuk versi Aurora MySQL.

Klaster yang merupakan target replikasi log biner

Mungkin

Jika replikasi log biner berasal dari klaster Aurora MySQL, Anda dapat melakukan peningkatan di tempat. Anda tidak dapat melakukan peningkatan jika replikasi log biner berasal dari instans DB RDS for MySQL atau instans DB MySQL on-premise. Dalam hal ini, Anda dapat melakukan peningkatan menggunakan mekanisme pemulihan snapshot.

Klaster dengan nol instans DB

Tidak

Menggunakan AWS CLI atau RDS API, Anda dapat membuat cluster Aurora MySQL tanpa instans DB yang terpasang. Dengan cara yang sama, Anda juga dapat menghapus semua instans DB dari klaster Aurora MySQL, tetapi membiarkan data dalam volume klaster tetap utuh. Meskipun sebuah klaster tidak memiliki instans DB, Anda tidak dapat melakukan peningkatan di tempat.

Mekanisme peningkatan memerlukan instans penulis di klaster untuk melakukan konversi pada tabel sistem, file data, dan sebagainya. Dalam hal ini, gunakan AWS CLI atau RDS API untuk membuat instance penulis untuk cluster. Kemudian, Anda dapat melakukan peningkatan di tempat.

Klaster dengan pelacakan mundur diaktifkan

Ya

Anda dapat melakukan peningkatan di tempat untuk klaster Aurora MySQL yang menggunakan fitur pelacakan mundur. Namun, setelah peningkatan, Anda tidak dapat melacak mundur klaster ke waktu sebelum peningkatan.

Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL

Aurora MySQL melakukan peningkatan versi mayor sebagai proses multitahap. Anda dapat memeriksa status peningkatan saat ini. Beberapa langkah peningkatan juga memberikan informasi progres. Seiring setiap tahap dimulai, Aurora MySQL akan mencatat sebuah peristiwa. Anda dapat memeriksa peristiwa yang terjadi di halaman Peristiwa di konsol RDS. Untuk informasi selengkapnya tentang menggunakan peristiwa, lihat Bekerja dengan pemberitahuan peristiwa Amazon RDS.

penting

Setelah proses dimulai, proses ini berjalan sampai peningkatan berhasil atau gagal. Anda tidak dapat membatalkan peningkatan saat sedang berlangsung. Jika peningkatan gagal, Aurora akan mengembalikan semua perubahan dan klaster Anda akan memiliki versi mesin, metadata, dan karakteristik lainnya yang sama seperti sebelumnya.

Proses peningkatan terdiri dari tiga tahap:

  1. Aurora melakukan serangkaian pra-pemeriksaan sebelum memulai proses peningkatan. Klaster Anda terus berjalan saat Aurora melakukan pemeriksaan ini. Misalnya, klaster tidak dapat memiliki transaksi XA apa pun dalam status siap atau memproses pernyataan bahasa definisi data (DDL). Misalnya, Anda mungkin perlu menutup aplikasi yang mengirimkan jenis pernyataan SQL tertentu. Atau, Anda mungkin hanya perlu menunggu sampai pernyataan berjalan lama tertentu diselesaikan. Kemudian, coba mulai peningkatan lagi. Beberapa pemeriksaan akan menguji kondisi yang tidak mencegah peningkatan, tetapi mungkin akan membuat peningkatan memakan waktu lama.

    Jika Aurora mendeteksi bahwa kondisi yang diperlukan tidak terpenuhi, ubah kondisi yang diidentifikasi dalam detail peristiwa. Ikuti panduan dalam Pemecahan masalah untuk peningkatan di tempat Aurora MySQL. Jika Aurora mendeteksi kondisi yang mungkin menyebabkan peningkatan yang lambat, rencanakan untuk memantau peningkatan dalam waktu lama.

  2. Aurora akan membuat klaster Anda menjadi offline. Kemudian, Aurora melakukan serangkaian pengujian serupa seperti pada tahap sebelumnya untuk memastikan bahwa tidak ada masalah baru yang muncul selama proses penonaktifan. Jika Aurora mendeteksi kondisi apa pun pada saat ini yang akan mencegah peningkatan, Aurora akan membatalkan peningkatan dan membuat klaster kembali online. Dalam hal ini, konfirmasikan jika kondisi tidak lagi berlaku dan mulai peningkatan lagi.

  3. Aurora membuat snapshot dari volume klaster Anda. Misalkan Anda menemukan kompatibilitas atau jenis masalah lainnya setelah peningkatan selesai. Atau misalkan Anda ingin melakukan pengujian menggunakan klaster asli dan klaster yang ditingkatkan. Dalam kasus tersebut, Anda dapat memulihkan dari snapshot ini untuk membuat klaster baru dengan versi mesin asli dan data asli.

    Tip

    Snapshot ini adalah snapshot manual. Namun, Aurora dapat membuatnya dan melanjutkan proses peningkatan bahkan jika Anda telah mencapai kuota untuk snapshot manual. Snapshot ini tetap ada secara permanen (jika diperlukan) hingga Anda menghapusnya. Setelah Anda menyelesaikan semua pengujian pasca-peningkatan, Anda dapat menghapus snapshot ini untuk meminimalkan biaya penyimpanan.

  4. Aurora akan mengkloning volume klaster Anda. Kloning adalah operasi cepat yang tidak memerlukan penyalinan data tabel yang sebenarnya. Jika Aurora mengalami masalah selama peningkatan, ia kembali ke data asli dari volume klaster kloning dan membawa klaster kembali online. Volume yang dikloning sementara selama peningkatan tidak memiliki batas yang biasanya berlaku pada jumlah klon untuk satu volume klaster.

  5. Aurora melakukan penonaktifan bersih untuk instans DB penulis. Selama penonaktifan bersih, progres peristiwa dicatat setiap 15 menit untuk operasi berikut. Anda dapat memeriksa peristiwa yang terjadi di halaman Peristiwa di konsol RDS.

    • Aurora membersihkan catatan undo untuk baris versi lama.

    • Aurora mengembalikan setiap transaksi yang tidak dikomit.

  6. Aurora meningkatkan versi mesin pada instans DB penulis:

    • Aurora menginstal biner untuk versi mesin baru pada instans DB penulis.

    • Aurora menggunakan instans DB penulis untuk meningkatkan data Anda ke format yang kompatibel dengan MySQL 5.7. Selama tahap ini, Aurora memodifikasi tabel sistem dan melakukan konversi lain yang memengaruhi data dalam volume klaster Anda. Secara khusus, Aurora meningkatkan metadata partisi di tabel sistem agar kompatibel dengan format partisi MySQL 5.7. Tahap ini dapat memakan waktu lama jika tabel di klaster Anda memiliki sejumlah besar partisi.

      Jika terjadi kesalahan selama tahap ini, Anda dapat menemukan detailnya dalam log kesalahan MySQL. Setelah tahap ini dimulai, jika proses peningkatan gagal karena alasan apa pun, Aurora akan mengembalikan data asli dari volume klaster yang dikloning.

  7. Aurora meningkatkan versi mesin pada instans DB pembaca.

  8. Proses peningkatan selesai. Aurora mencatat peristiwa akhir untuk menunjukkan bahwa proses peningkatan berhasil selesai. Sekarang klaster DB Anda menjalankan versi mayor baru.

Deployment Blue/Green

Dalam situasi tertentu, prioritas utama Anda adalah melakukan switchover langsung dari klaster lama ke klaster yang ditingkatkan. Dalam situasi seperti itu, Anda dapat menggunakan proses multistep yang menjalankan cluster side-by-side lama dan baru. Di sini, Anda mereplikasi data dari klaster lama ke klaster baru hingga Anda siap untuk mengambil alih klaster baru. Untuk detailnya, lihat Menggunakan Deployment Blue/Green Amazon RDS untuk pembaruan basis data.

Cara melakukan peningkatan di tempat

Sebaiknya Anda meninjau materi latar belakang dalam Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL.

Lakukan perencanaan dan pengujian pra-upgrade, seperti yang dijelaskan dalamMerencanakan peningkatan versi mayor untuk klaster Aurora MySQL.

Contoh berikut meningkatkan cluster mydbcluster-cluster DB ke Aurora MySQL versi 3.04.1.

Untuk meningkatkan versi mayor klaster DB Aurora MySQL

  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Jika Anda menggunakan grup parameter kustom untuk klaster DB asli, buat grup parameter terkait yang kompatibel dengan versi mayor baru. Buat penyesuaian yang diperlukan untuk parameter konfigurasi di grup parameter baru tersebut. Untuk informasi selengkapnya, lihat Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster.

  3. Di panel navigasi, pilih Basis Data.

  4. Dalam daftar, pilih klaster DB yang ingin Anda ubah.

  5. Pilih Ubah.

  6. Untuk Versi, pilih versi mayor Aurora MySQL baru.

    Biasanya, kami merekomendasikan untuk menggunakan versi minor terbaru dari versi mayor. Di sini, kami memilih versi default saat ini.

    Peningkatan di tempat terhadap klaster DB Aurora MySQL dari versi 2 ke versi 3

  7. Pilih Lanjutkan.

  8. Di halaman berikutnya, tentukan kapan harus melakukan peningkatan. Pilih Selama jendela pemeliharaan terjadwal berikutnya atau Segera.

  9. (Opsional) Periksa secara berkala halaman Peristiwa di konsol RDS selama peningkatan. Tindakan ini akan membantu Anda memantau progres peningkatan dan identifikasi masalah apa pun. Jika peningkatan mengalami masalah apa pun, lihat Pemecahan masalah untuk peningkatan di tempat Aurora MySQL untuk langkah-langkah yang harus diambil.

  10. Jika Anda membuat grup parameter baru di awal prosedur ini, kaitkan grup parameter kustom dengan klaster yang ditingkatkan. Untuk informasi selengkapnya, lihat Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster.

    catatan

    Langkah ini mengharuskan Anda untuk memulai ulang klaster lagi untuk menerapkan grup parameter baru.

  11. (Opsional) Setelah Anda menyelesaikan setiap pengujian pasca-peningkatan, hapus snapshot manual yang dibuat Aurora pada awal peningkatan.

Untuk memutakhirkan versi utama cluster DB MySQL Aurora, gunakan perintah AWS CLI modify-db-cluster dengan parameter yang diperlukan berikut:

  • --db-cluster-identifier

  • --engine-version

  • --allow-major-version-upgrade

  • --apply-immediately atau --no-apply-immediately

Jika klaster Anda menggunakan grup parameter kustom, sertakan juga salah satu atau kedua opsi berikut ini:

  • --db-cluster-parameter-group-name, jika klaster menggunakan grup parameter klaster kustom

  • --db-instance-parameter-group-name, jika ada instans di klaster yang menggunakan grup parameter DB kustom

Contoh berikut meningkatkan cluster sample-cluster DB ke Aurora MySQL versi 3.04.1. Peningkatan akan segera terjadi, bukan menunggu periode pemeliharaan berikutnya.

contoh

Untuk Linux, macOS, atau Unix:

aws rds modify-db-cluster \
          --db-cluster-identifier sample-cluster \
          --engine-version 8.0.mysql_aurora.3.04.1 \
          --allow-major-version-upgrade \
          --apply-immediately

Untuk Windows:

aws rds modify-db-cluster ^
          --db-cluster-identifier sample-cluster ^
          --engine-version 8.0.mysql_aurora.3.04.1 ^
          --allow-major-version-upgrade ^
          --apply-immediately

Anda dapat menggabungkan perintah CLI lainnya modify-db-cluster untuk membuat end-to-end proses otomatis untuk melakukan dan memverifikasi peningkatan. Untuk informasi selengkapnya dan contoh tambahan, lihat Tutorial peningkatan di tempat Aurora MySQL.

catatan

Jika klaster Anda adalah bagian dari basis data global Aurora, prosedur peningkatan di tempat ini sedikit berbeda. Anda memanggil operasi perintah modify-global-cluster, bukannya modify-db-cluster. Untuk informasi selengkapnya, lihat Peningkatan besar di tempat untuk basis data global.

Untuk meningkatkan versi mayor klaster DB Aurora MySQL, gunakan perintah ModifyDBCluster API RDS dengan parameter wajib berikut:

  • DBClusterIdentifier

  • Engine

  • EngineVersion

  • AllowMajorVersionUpgrade

  • ApplyImmediately (atur ke true atau false)

catatan

Jika klaster Anda adalah bagian dari basis data global Aurora, prosedur peningkatan di tempat ini sedikit berbeda. Anda memanggil operasi ModifyGlobalCluster alih-alihModifyDBCluster. Untuk informasi selengkapnya, lihat Peningkatan besar di tempat untuk basis data global.

Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster

Grup parameter Aurora memiliki kumpulan pengaturan konfigurasi yang berbeda untuk klaster yang kompatibel dengan MySQL 5.7 atau 8.0. Saat Anda melakukan peningkatan di tempat, klaster yang ditingkatkan dan semua instans harus menggunakan grup parameter klaster dan instans yang sesuai:

Klaster dan instans Anda mungkin menggunakan grup parameter default yang kompatibel dengan 5.7. Jika demikian, klaster dan instans yang ditingkatkan akan dimulai dengan grup parameter default yang kompatibel dengan 8.0. Jika klaster dan instans Anda menggunakan grup parameter kustom apa pun, pastikan untuk membuat grup parameter yang sesuai atau yang kompatibel dengan 8.0. Pastikan juga untuk menentukannya selama proses peningkatan.

catatan

Untuk sebagian besar pengaturan parameter, Anda dapat memilih grup parameter kustom di dua titik. Titik ini adalah saat Anda membuat klaster atau mengaitkan grup parameter dengan klaster nanti.

Namun, jika Anda menggunakan pengaturan nondefault untuk parameter lower_case_table_names, Anda harus mengatur grup parameter kustom dengan pengaturan ini terlebih dahulu. Kemudian, tentukan grup parameter saat Anda melakukan pemulihan snapshot untuk membuat klaster. Setiap perubahan pada parameter lower_case_table_names tidak akan berpengaruh setelah klaster dibuat.

Kami menyarankan Anda menggunakan pengaturan yang sama untuk lower_case_table_names ketika Anda meningkatkan dari Aurora MySQL versi 2 ke versi 3.

Dengan basis data global Aurora berdasarkan Aurora MySQL, Anda tidak dapat melakukan peningkatan di tempat dari Aurora MySQL versi 2 ke versi 3 jika parameter lower_case_table_names diaktifkan. Untuk informasi selengkapnya tentang metode yang dapat Anda gunakan, lihat Peningkatan versi utama.

penting

Jika Anda menentukan grup parameter kustom apa pun selama proses peningkatan, pastikan untuk mem-boot ulang klaster secara manual setelah peningkatan selesai. Tindakan ini akan membuat klaster mulai menggunakan pengaturan parameter kustom Anda.

Perubahan pada properti klaster di antara versi Aurora MySQL

Saat Anda meningkatkan dari Aurora MySQL versi 2 ke versi 3, pastikan untuk memeriksa aplikasi atau skrip apa pun yang Anda gunakan untuk menyiapkan atau mengelola klaster dan instans DB Aurora MySQL.

Selain itu, ubah kode Anda yang memanipulasi grup parameter untuk memperhitungkan fakta bahwa nama grup parameter default berbeda untuk klaster yang kompatibel dengan 5.7 dan 8.0. Nama grup parameter default untuk klaster Aurora MySQL versi 2 dan 3 masing-masing adalah default.aurora-mysql5.7 dan default.aurora-mysql8.0.

Misalnya, Anda mungkin memiliki kode seperti berikut yang berlaku untuk klaster Anda sebelum peningkatan.

# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1

Setelah meningkatkan versi mayor klaster, ubah kode tersebut sebagai berikut.

# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1

Peningkatan besar di tempat untuk basis data global

Untuk basis data global Aurora, Anda meningkatkan klaster basis data global. Aurora secara otomatis meningkatkan semua klaster pada saat yang sama dan memastikan bahwa semua klaster ini menjalankan versi mesin yang sama. Persyaratan ini berlaku karena setiap perubahan pada tabel sistem, format file data, dan sebagainya akan secara otomatis direplikasi ke semua klaster sekunder.

Ikuti petunjuk dalam Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL. Saat Anda menentukan hal yang akan ditingkatkan, pastikan untuk memilih klaster basis data global, bukan salah satu klaster yang terdapat di dalamnya.

Jika Anda menggunakan AWS Management Console, pilih item dengan peran database Global.

Meningkatkan klaster basis data global

Jika Anda menggunakan AWS CLI atau RDS API, mulai proses upgrade dengan memanggil perintah modify-global-cluster atau operasi Cluster. ModifyGlobal Anda akan menggunakan salah satunya, bukan modify-db-cluster atau ModifyDBCluster.

catatan

Anda tidak dapat menentukan grup parameter kustom untuk klaster basis data global saat Anda melakukan peningkatan versi mayor basis data global Aurora tersebut. Buat grup parameter kustom Anda di setiap Wilayah klaster global. Kemudian, terapkan secara manual ke klaster Regional setelah peningkatan.

Untuk meng-upgrade versi utama dari cluster database global MySQL Aurora dengan menggunakan, gunakan perintah AWS CLImodify-global-cluster dengan parameter yang diperlukan berikut:

  • --global-cluster-identifier

  • --engine aurora-mysql

  • --engine-version

  • --allow-major-version-upgrade

Contoh berikut meningkatkan klaster basis data global ke Aurora MySQL versi 2.10.2.

contoh

Untuk Linux, macOS, atau Unix:

aws rds modify-global-cluster \
          --global-cluster-identifier global_cluster_identifier \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.10.2 \
          --allow-major-version-upgrade

Untuk Windows:

aws rds modify-global-cluster ^
          --global-cluster-identifier global_cluster_identifier ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.10.2 ^
          --allow-major-version-upgrade

Backtrack pertimbangan

Jika klaster yang Anda tingkatkan memiliki fitur Pelacakan Mundur diaktifkan, Anda tidak dapat melacak mundur klaster yang ditingkatkan ke waktu sebelum peningkatan.

Tutorial peningkatan di tempat Aurora MySQL

Contoh Linux berikut menunjukkan cara Anda dapat melakukan langkah-langkah umum untuk prosedur peningkatan di tempat menggunakan AWS CLI.

Contoh pertama ini membuat klaster DB Aurora yang menjalankan Aurora MySQL versi 2.x. Klaster ini mencakup instans DB penulis dan instans DB pembaca. Perintah wait db-instance-available dijeda hingga instans DB penulis tersedia. Pada saat itulah, klaster siap untuk ditingkatkan.

aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
  --db-cluster-version 5.7.mysql_aurora.2.10.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
  --db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

Versi Aurora MySQL 3.x yang dapat Anda tingkatkan cluster agar bergantung pada versi 2.x yang sedang dijalankan cluster dan di mana cluster berada. Wilayah AWS Perintah pertama, dengan --output text, hanya menunjukkan versi target yang tersedia. Perintah kedua menunjukkan output lengkap JSON dari respons. Dalam respons tersebut, Anda dapat melihat detail seperti nilai aurora-mysql yang Anda gunakan untuk parameter engine. Anda juga dapat melihat fakta bahwa peningkatan ke 3.02.0 merupakan peningkatan versi mayor.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]'
...
{
    "Engine": "aurora-mysql",
    "EngineVersion": "8.0.mysql_aurora.3.02.0",
    "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)",
    "AutoUpgrade": false,
    "IsMajorVersionUpgrade": true,
    "SupportedEngineModes": [
        "provisioned"
    ],
    "SupportsParallelQuery": true,
    "SupportsGlobalDatabases": true,
    "SupportsBabelfish": false
},
...

Contoh ini menunjukkan bahwa jika Anda memasukkan nomor versi target yang bukan merupakan target peningkatan yang valid untuk klaster, Aurora tidak akan melakukan peningkatan. Aurora juga tidak melakukan peningkatan versi mayor kecuali jika Anda menyertakan parameter --allow-major-version-upgrade. Dengan demikian, Anda tidak dapat tanpa disengaja melakukan peningkatan yang berpotensi akan memerlukan pengujian dan perubahan ekstensif terhadap kode aplikasi Anda.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.10.2 with requested version 5.7.mysql_aurora.2.09.2.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "mynewdbcluster",
  "Status": "available",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.2"
}

Dibutuhkan beberapa saat hingga status klaster dan instans DB terkait berubah menjadi upgrading. Nomor versi untuk klaster dan instans DB hanya berubah saat peningkatan selesai. Sekali lagi, Anda dapat menggunakan perintah wait db-instance-available untuk instans DB penulis untuk menunggu hingga peningkatan selesai sebelum melanjutkan. 

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.10.2

aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "mynewdbcluster-instance1",
    "DBInstanceStatus": "upgrading"
}

aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

Pada tahap ini, nomor versi untuk klaster akan cocok dengan nomor versi yang ditentukan untuk peningkatan. 

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[EngineVersion]' --output text

8.0.mysql_aurora.3.02.0

Contoh sebelumnya melakukan peningkatan langsung dengan menentukan parameter --apply-immediately. Agar peningkatan terjadi pada waktu yang tepat saat klaster diperkirakan tidak sibuk, Anda dapat menentukan parameter --no-apply-immediately. Tindakan ini akan membuat peningkatan dimulai selama periode pemeliharaan berikutnya untuk klaster. Periode pemeliharaan menentukan periode saat operasi pemeliharaan dapat dimulai. Operasi yang berjalan lama mungkin tidak selesai selama periode pemeliharaan. Dengan demikian, Anda tidak perlu menentukan periode pemeliharaan yang lebih panjang bahkan jika Anda memperkirakan bahwa peningkatan mungkin akan memakan waktu lama.

Contoh berikut meningkatkan klaster yang awalnya menjalankan Aurora MySQL versi 2.10.2. Dalam output describe-db-engine-versions, nilai False dan True merepresentasikan properti IsMajorVersionUpgrade. Dari versi 2.10.2, Anda dapat meningkatkan ke beberapa versi 2.* lainnya. Peningkatan tersebut tidak dianggap sebagai peningkatan versi mayor sehingga tidak memerlukan peningkatan di tempat. Peningkatan di tempat hanya tersedia untuk peningkatan ke versi 3.* yang ditampilkan dalam daftar.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text

5.7.mysql_aurora.2.10.3 False
5.7.mysql_aurora.2.11.0 False
5.7.mysql_aurora.2.11.1 False
8.0.mysql_aurora.3.01.1 True
8.0.mysql_aurora.3.02.0 True
8.0.mysql_aurora.3.02.2 True


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --no-apply-immediately --allow-major-version-upgrade
...

Ketika sebuah klaster dibuat tanpa periode pemeliharaan yang ditentukan, Aurora akan memilih hari acak dalam seminggu. Dalam hal ini, perintah modify-db-cluster dikirimkan pada hari Senin. Dengan demikian, kita mengubah periode pemeliharaan menjadi Selasa pagi. Semua waktu ditampilkan dalam zona waktu UTC. Periode tue:10:00-tue:10:30 sama dengan 02.00-02.30 waktu Pasifik. Perubahan periode pemeliharaan akan langsung berlaku.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

Contoh berikut menunjukkan cara mendapatkan laporan dari peristiwa yang dihasilkan oleh peningkatan. Argumen --duration merepresentasikan jumlah menit untuk mengambil informasi peristiwa. Argumen ini diperlukan, karena secara default describe-events hanya mengembalikan peristiwa dari jam terakhir.

aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2022-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        }
    ]
}

Menemukan alasan kegagalan peningkatan

Pada tutorial sebelumnya, upgrade dari Aurora MySQL versi 2 ke versi 3 berhasil. Tetapi jika upgrade gagal, Anda pasti ingin tahu mengapa.

Anda dapat mulai dengan menggunakan describe-events AWS CLI perintah untuk melihat peristiwa cluster DB. Contoh ini menunjukkan peristiwa mydbcluster selama 10 jam terakhir.

aws rds describe-events \
    --source-type db-cluster \
    --source-identifier mydbcluster \
    --duration 600

Dalam hal ini, kami mengalami kegagalan precheck upgrade.

{
    "Events": [
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster engine version upgrade started.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:22.846000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        },
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the  
             upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see 
             https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:24.373000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        }
    ]
}

Untuk mendiagnosis penyebab pasti masalah, periksa log database untuk instance DB penulis. Ketika upgrade ke Aurora MySQL versi 3 gagal, instance penulis berisi file log dengan nama. upgrade-prechecks.log Contoh ini menunjukkan cara mendeteksi keberadaan log tersebut lalu mengunduhnya ke file lokal untuk diperiksa.

aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
    --query '*[].[LogFileName]' --output text

error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log

aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
    --log-file-name upgrade-prechecks.log \
    --starting-token 0 \
    --output text >upgrade_prechecks.log

File upgrade-prechecks.log memiliki format JSON. Kita mengunduhnya menggunakan opsi --output text untuk menghindari pengenkodean output JSON dalam wrapper JSON lain. Untuk peningkatan Aurora MySQL versi 3, log ini selalu menyertakan pesan informasi dan peringatan tertentu. Log ini hanya berisi pesan kesalahan jika peningkatan gagal. Jika peningkatan berhasil, file log tidak dibuat sama sekali.

Untuk meringkas semua kesalahan dan menampilkan bidang objek dan deskripsi terkait, Anda dapat menjalankan perintah grep -A 2 '"level": "Error"' pada isi upgrade-prechecks.log file. Tindakan ini akan menampilkan setiap baris kesalahan dan dua baris setelahnya. Baris ini berisi nama objek basis data yang sesuai dan panduan tentang cara memperbaiki masalahnya.

$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'

"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

Dalam contoh ini, Anda dapat menjalankan perintah SQL berikut pada tabel yang menyinggung untuk mencoba memperbaiki masalah, atau Anda dapat membuat ulang tabel tanpa indeks menggantung.

OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;

Kemudian coba lagi upgrade.

Pemecahan masalah untuk peningkatan di tempat Aurora MySQL

Gunakan tips berikut untuk membantu memecahkan masalah terkait peningkatan di tempat Aurora MySQL. Tips ini tidak berlaku untuk klaster DB Aurora Serverless.

Alasan peningkatan di tempat dibatalkan atau lambat Efek Solusi untuk memungkinkan peningkatan di tempat selesai dalam periode pemeliharaan
Replika Lintas wilayah Aurora Terkait belum ditambal Aurora membatalkan peningkatan. Tingkatkan replika Aurora Cross-region dan coba lagi.
Klaster memiliki transaksi XA dalam status siap Aurora membatalkan peningkatan. Komit atau kembalikan semua transaksi XA yang disiapkan.
Klaster sedang memproses pernyataan bahasa definisi data (DDL) Aurora membatalkan peningkatan. Pertimbangkan untuk menunggu dan melakukan peningkatan setelah semua pernyataan DDL selesai.
Klaster memiliki perubahan yang tidak dikomit untuk banyak baris Peningkatan mungkin memerlukan waktu lama.

Proses peningkatan mengembalikan perubahan yang tidak dikomit. Indikator untuk kondisi ini adalah nilai TRX_ROWS_MODIFIED dalam tabel INFORMATION_SCHEMA.INNODB_TRX.

Pertimbangkan untuk melakukan peningkatan hanya setelah semua transaksi besar dilakukan atau dikembalikan.
Klaster memiliki jumlah catatan undo yang tinggi Peningkatan mungkin memerlukan waktu lama.

Bahkan jika transaksi yang tidak dikomit tidak memengaruhi sejumlah besar baris, transaksi ini mungkin berkaitan dengan volume besar data. Misalnya, Anda mungkin memasukkan BLOB besar. Aurora tidak akan secara otomatis mendeteksi atau menghasilkan peristiwa untuk jenis aktivitas transaksi ini. Indikator untuk kondisi ini adalah panjang daftar riwayat (HLL). Proses peningkatan mengembalikan perubahan yang tidak dikomit.

Anda dapat memeriksa HLL dalam output dari perintah SQL SHOW ENGINE INNODB STATUS, atau langsung dengan menggunakan kueri SQL berikut:

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

Anda juga dapat memantau RollbackSegmentHistoryListLength metrik di Amazon CloudWatch.

Pertimbangkan untuk melakukan peningkatan hanya setelah HLL menjadi lebih kecil.
Klaster sedang dalam proses melakukan komit transaksi log biner besar Peningkatan mungkin memerlukan waktu lama.

Proses peningkatan menunggu sampai perubahan log biner diterapkan. Transaksi atau pernyataan DDL lainnya dapat dimulai selama periode ini, sehingga akan makin memperlambat proses peningkatan.

Jadwalkan proses peningkatan saat klaster tidak sibuk menghasilkan perubahan replikasi log biner. Aurora tidak akan secara otomatis mendeteksi atau membuat peristiwa untuk kondisi ini.
Inkonsistensi skema yang dihasilkan dari penghapusan atau kerusakan file Aurora membatalkan peningkatan.

Ubah mesin penyimpanan default untuk tabel sementara dari MyISAM menjadi InnoDB. Lakukan langkah-langkah berikut ini:

  1. Ubah parameter DB default_tmp_storage_engine menjadi InnoDB.

  2. Boot ulang klaster DB.

  3. Setelah boot ulang, konfirmasikan bahwa parameter DB default_tmp_storage_engine diatur ke InnoDB. Gunakan perintah berikut ini.

    show global variables like 'default_tmp_storage_engine';

  4. Pastikan untuk tidak membuat tabel sementara yang menggunakan mesin penyimpanan MyISAM. Kami menyarankan agar Anda menjeda beban kerja basis data apa pun dan tidak membuat koneksi basis data baru karena Anda akan segera melakukan peningkatan.

  5. Coba lagi peningkatan di tempat.
Pengguna master dihapus Aurora membatalkan peningkatan.
penting

Jangan hapus pengguna master.

Namun, jika karena alasan tertentu Anda kebetulan menghapus pengguna master, kembalikan pengguna master menggunakan perintah SQL berikut:

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

Untuk detail selengkapnya tentang masalah pemecahan masalah yang menyebabkan precheck upgrade gagal, lihat blog berikut:

Anda dapat menggunakan langkah-langkah berikut untuk melakukan pemeriksaan Anda sendiri untuk beberapa kondisi di tabel sebelumnya. Dengan demikian, Anda dapat menjadwalkan peningkatan pada saat Anda mengetahui basis data dalam keadaan yang memungkinkan peningkatan berhasil diselesaikan dengan cepat.

  • Anda dapat memeriksa transaksi XA terbuka dengan menjalankan pernyataan XA RECOVER. Anda kemudian dapat meng-commit atau mengembalikan transaksi XA sebelum memulai peningkatan.

  • Anda dapat memeriksa pernyataan DDL dengan menjalankan pernyataan SHOW PROCESSLIST dan mencari pernyataan CREATE, DROP, ALTER, RENAME, dan TRUNCATE dalam output. Tunggu semua pernyataan DDL selesai sebelum memulai peningkatan.

  • Anda dapat memeriksa jumlah total baris yang tidak dikomit dengan mengueri tabel INFORMATION_SCHEMA.INNODB_TRX. Tabel ini berisi satu baris untuk setiap transaksi. Kolom TRX_ROWS_MODIFIED berisi jumlah baris yang diubah atau dimasukkan oleh transaksi.

  • Anda dapat memeriksa panjang daftar riwayat InnoDB dengan menjalankan pernyataan SHOW ENGINE INNODB STATUS SQL dan mencari History list length dalam output. Anda juga dapat memeriksa nilai secara langsung dengan menjalankan kueri berikut: 

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    Panjang daftar riwayat sesuai dengan jumlah informasi undo yang disimpan oleh basis data untuk menerapkan kontrol konkurensi multiversi (MVCC).

Pembersihan pasca-peningkatan untuk Aurora MySQL versi 3

Setelah Anda selesai meningkatkan klaster Aurora MySQL versi 2 ke Aurora MySQL versi 3, Anda dapat melakukan tindakan pembersihan lainnya sebagai berikut:

  • Buat versi baru yang kompatibel dengan MySQL 8.0 untuk setiap grup parameter kustom. Terapkan nilai parameter kustom yang diperlukan ke grup parameter baru.

  • Perbarui CloudWatch alarm, skrip penyiapan, dan sebagainya untuk menggunakan nama baru untuk metrik apa pun yang namanya dipengaruhi oleh perubahan bahasa inklusif. Untuk daftar metrik tersebut, lihat Perubahan bahasa inklusif untuk Aurora MySQL versi 3.

  • Perbarui AWS CloudFormation templat apa pun untuk menggunakan nama baru untuk parameter konfigurasi apa pun yang namanya dipengaruhi oleh perubahan bahasa inklusif. Untuk daftar parameter tersebut, lihat Perubahan bahasa inklusif untuk Aurora MySQL versi 3.

Indeks spasial

Setelah meningkatkan ke Aurora MySQL versi 3, periksa apakah Anda perlu menghapus atau membuat ulang objek dan indeks yang terkait dengan indeks spasial. Sebelum MySQL 8.0, Aurora dapat mengoptimalkan kueri spasial menggunakan indeks yang tidak berisi pengidentifikasi sumber daya spasial (SRID). Aurora MySQL versi 3 hanya menggunakan indeks spasial yang berisi SRID. Selama peningkatan, Aurora secara otomatis menghapus indeks spasial apa pun yang tidak memiliki SRID dan mencetak pesan peringatan di log basis data. Jika Anda mengamati pesan peringatan tersebut, buat indeks spasial baru dengan SRID setelah peningkatan. Untuk informasi selengkapnya tentang perubahan fungsi spasial dan tipe data di MySQL 8.0, lihat Changes in MySQL 8.0 dalam Panduan Referensi MySQL.