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 3.04.1, 3 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.
Daftar Isi
- Upgrade dari Aurora MySQL versi 2 ke versi 3
- Jalur peningkatan versi mayor Aurora MySQL
- Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL
- Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL
- Pra-cek pemutakhiran versi utama untuk Aurora My SQL
- Cara melakukan peningkatan di tempat
- Aurora Tutorial peningkatan di tempat SQL saya
- Menemukan alasan Aurora Kegagalan peningkatan versi SQL utama saya
- Pemecahan masalah untuk Aurora Peningkatan di tempat saya SQL
- Pembersihan pasca-upgrade untuk Aurora Versi saya 3 SQL
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 untuk cluster Anda, Anda dapat memilih di antara teknik upgrade:
-
catatan
Jika Anda menggunakan AWS CLI atau RDS API untuk metode upgrade pemulihan snapshot, Anda harus menjalankan operasi berikutnya untuk membuat instance DB penulis di cluster DB yang dipulihkan.
Untuk informasi umum tentang Aurora MySQL versi 3 dan fitur-fiturnya yang baru, lihat Aurora SQL Versi saya 3 kompatibel dengan My 8.0 SQL.
Untuk detail tentang merencanakan peningkatan, lihat Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL dan Cara melakukan peningkatan di tempat.
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 |
---|---|---|
Kluster yang disediakan Aurora MySQL, versi 2 |
Ya |
Upgrade di tempat didukung untuk klaster MySQL MySQL 5.7 yang kompatibel dengan MySQL. Untuk informasi tentang peningkatan ke Aurora MySQL versi 3, lihat Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL dan Cara melakukan peningkatan di tempat. |
Kluster yang disediakan Aurora MySQL, versi 3 |
Tidak berlaku |
Gunakan prosedur peningkatan versi minor untuk peningkatan di antara Aurora MySQL versi 3. |
Aurora Serverless v1 cluster |
Tidak berlaku |
Aurora Serverless v1 didukung untuk Aurora MySQL hanya pada versi 2. |
Aurora Serverless v2 cluster |
Tidak berlaku |
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 Anda dapat melakukan upgrade di tempat dari Aurora MySQL versi 2 ke versi 3 hanya |
Klaster kueri paralel |
Ya |
Anda dapat melakukan peningkatan di tempat. |
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 upgrade di tempat untuk cluster Aurora MySQL yang menggunakan fitur Backtrack. 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 RDS acara Amazon.
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:
-
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 Aurora Peningkatan di tempat saya SQL. Jika Aurora mendeteksi kondisi yang mungkin menyebabkan peningkatan yang lambat, rencanakan untuk memantau peningkatan dalam waktu lama.
-
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.
-
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.
-
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.
-
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.
-
-
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.
-
-
Aurora meningkatkan versi mesin pada instans DB pembaca.
-
Proses peningkatan selesai. Aurora mencatat peristiwa akhir untuk menunjukkan bahwa proses peningkatan berhasil selesai. Sekarang klaster DB Anda menjalankan versi mayor baru.
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:
-
Jika Anda mengonversi dari RDS untuk MySQL 8.0 atau MySQL 8.0 Community Edition, lihat. Membandingkan Aurora My SQL version 3 dan My SQL 8.0 Community Edition
-
Jika Anda meningkatkan dari Aurora MySQL versi 2, RDS untuk MySQL 5.7, atau komunitas MySQL 5.7, lihat. Membandingkan Aurora SQL Versi saya 2 dan Aurora Versi saya 3 SQL
-
Buat versi baru yang kompatibel dengan MySQL 8.0 untuk setiap grup parameter kustom. Terapkan nilai parameter kustom yang diperlukan ke grup parameter baru. Baca Perubahan parameter untuk Aurora Versi saya 3 SQL untuk mempelajari tentang perubahan parameter.
-
Tinjau definisi skema dan objek basis data Aurora MySQL versi 2 untuk penggunaan kata kunci baru yang dicadangkan, yang diperkenalkan di MySQL 8.0 Community Edition. Lakukan hal ini sebelum Anda meningkatkan. Untuk informasi selengkapnya, lihat MySQL 8.0 New Keywords and Reserved Words
dalam dokumentasi MySQL.
Anda juga dapat menemukan lebih banyak pertimbangan dan tips peningkatan khusus MySQL dalam Changes in MySQL 8.0mysqlcheck --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-upgrade untuk Aurora Versi saya 3 SQL. Terakhir, uji fungsionalitas dan performa aplikasi Anda.
Jika Anda mengonversi dari RDS dari MySQL atau MySQL komunitas, ikuti prosedur migrasi yang dijelaskan di. Migrasi data ke cluster Amazon Aurora My DB SQL 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 Aurora Peningkatan di tempat saya SQL. 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
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:
-
Membuat klon dari klaster asli. Ikuti prosedur dalam Mengkloning volume untuk klaster DB Amazon Aurora.
-
Siapkan satu set instans DB penulis dan pembaca yang serupa seperti di klaster asli.
-
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.
-
Uji kompatibilitas aplikasi, performa, prosedur administrasi, dan sebagainya, menggunakan klaster yang dikloning.
-
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.
-
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.
-
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.
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 Aurora Blue/Green Deployment untuk pembaruan basis data.