Cara menggunakan mysql cluster types

Dalam nomor versi Aurora MySQL seperti 2.08.1, 2 mewakili versi besar. Aurora MySQL versi 1 kompatibel dengan MySQL 5.6. Aurora MySQL versi 2 kompatibel dengan MySQL 5.7. Aurora MySQL versi 3 kompatibel dengan MySQL 8.0.23.

Meningkatkan antar versi besar memerlukan perencanaan dan pengujian yang lebih ekstensif daripada versi kecil. 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, cara kerja fitur terkait MySQL tertentu, atau pengaturan parameter antara versi lama dan baru.

Topik

• Meningkatkan dari Aurora MySQL 2.x ke 3.x
• Upgrade dari Aurora MySQL 1.x ke 2.x
• Merencanakan peningkatan versi besar untuk klaster Aurora MySQL
• Jalur peningkatan versi besar Aurora MySQL
• Cara kerja peningkatan versi besar Aurora MySQL di tempat
• Cara melakukan peningkatan di tempat
• Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster
• Perubahan pada properti klaster antara Aurora MySQL versi 1 dan 2
• Peningkatan besar untuk basis data global
• Setelah peningkatan
• Pemecahan masalah untuk peningkatan di tempat Aurora MySQL
• Tutorial peningkatan di tempat Aurora MySQL
• Teknik peningkatan biru-hijau alternatif

Meningkatkan dari Aurora MySQL 2.x ke 3.x

Saat ini, memutakhirkan ke Aurora MySQL versi 3 memerlukan pemulihan snapshot cluster Aurora MySQL versi 2 untuk membuat klaster versi 3 baru. Jika klaster asli Anda menjalankan Aurora MySQL versi 1, pertama-tama Anda meng-upgrade ke versi 2 dan kemudian menggunakan teknik pemulihan snapshot untuk membuat klaster versi 3. Untuk informasi umum tentang Aurora MySQL versi 3 dan fitur baru yang dapat Anda gunakan setelah Anda meng-upgrade, lihatAurora MySQL versi 3 kompatibel dengan MySQL 8.0. Untuk detail dan contoh melakukan upgrade jenis ini, lihatPerencanaan upgrade untuk Aurora MySQL versi 3danUpgrade ke Aurora MySQL versi 3.

Ketika Anda meng-upgrade versi utama klaster Anda dari 2.x ke 3.x, klaster asli dan yang ditingkatkan keduanya menggunakan yang samaaurora-mysqlvalue untukengineatribut.

Upgrade dari Aurora MySQL 1.x ke 2.x

Meningkatkan versi besar dari 1.x ke 2.x mengubahengineatribut cluster dariaurorakepadaaurora-mysql. Pastikan untuk memperbarui AWS CLI atau API otomatisasi yang Anda gunakan dengan klaster ini untuk memperhitungkan nilai engine yang diubah.

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

Mekanisme peningkatan di tempat melibatkan mematikan klaster DB Anda saat operasi berlangsung. Aurora melakukan shutdown bersih dan menyelesaikan operasi luar biasa seperti rollback transaksi dan penghapusan pembersihan.

Peningkatan di tempat ini mudah, karena mudah dilakukan dan meminimalkan perubahan konfigurasi pada aplikasi terkait. Sebagai contoh, peningkatan di tempat mempertahankan endpoint dan mengatur instans DB untuk klaster Anda. Namun, waktu yang diperlukan untuk peningkatan di tempat dapat bervariasi tergantung pada properti skema Anda dan seberapa sibuk klaster. Jadi, tergantung pada kebutuhan klaster Anda, Anda dapat memilih antara peningkatan di tempat, pemulihan snapshot seperti yang dijelaskan dalam Memulihkan dari snapshot klaster DB, atau teknik peningkatan lainnya seperti yang dijelaskan dalam Teknik peningkatan biru-hijau alternatif.

Jika klaster Anda menjalankan versi yang lebih rendah dari 1.22.3, peningkatan mungkin memerlukan waktu lebih lama karena Aurora MySQL secara otomatis melakukan peningkatan ke 1.22.3 sebagai langkah pertama. Untuk meminimalkan downtime selama peningkatan versi besar, Anda dapat melakukan peningkatan versi kecil awal ke Aurora MySQL 1.22.3 terlebih dahulu.

Merencanakan peningkatan versi besar untuk klaster Aurora MySQL

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

Anda dapat mempelajari jenis masalah yang mungkin Anda alami selama peningkatan dengan membaca Pemecahan 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.

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

Teknik ini berlaku untuk upgrade dari Aurora MySQL versi 1 ke versi 2. Saat ini, Anda tidak dapat meng-upgrade dari Aurora MySQL versi 2 ke 3 dengan menggunakan kloning.

Gunakan langkah-langkah berikut:

1. Membuat tiruan dari klaster asli. Ikuti prosedur di 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 klaster kloning. Ikuti prosedur di Cara melakukan peningkatan di tempat. Mulai peningkatan segera setelah membuat klon. Dengan begitu, volume klaster masih identik dengan keadaan klaster aslinya. Jika klon tidak digunakan sebelum Anda melakukan peningkatan, Aurora melakukan proses pembersihan database di latar belakang. Dalam hal ini, peningkatan klon bukanlah simulasi yang akurat untuk meningkatkan klaster asli.

4. Uji kompatibilitas aplikasi, kinerja, prosedur administrasi, dan sebagainya, menggunakan klaster kloning.

5. Jika Anda mengalami masalah apa pun, sesuaikan rencana peningkatan Anda untuk memperhitungkannya. Misalnya, sesuaikan kode aplikasi apa pun agar kompatibel dengan kumpulan fitur dari versi yang lebih tinggi. Perkirakan berapa lama waktu yang dibutuhkan untuk meningkatkan 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. Untuk meminimalkan total downtime klaster Anda selama peningkatan versi besar, pastikan bahwa beban kerja di klaster rendah atau nol pada saat peningkatan. Secara khusus, pastikan bahwa tidak ada transaksi berjalan lama berlangsung saat Anda memulai peningkatan.

Jalur peningkatan versi besar 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.

Cara kerja peningkatan versi besar Aurora MySQL di tempat

Aurora MySQL melakukan peningkatan versi besar sebagai proses multitahap. Anda dapat memeriksa status peningkatan saat ini. Beberapa langkah peningkatan juga memberikan informasi kemajuan. Sebagai setiap tahap dimulai, Aurora MySQL mencatat sebuah peristiwa. Anda dapat memeriksa peristiwa yang terjadi di halaman Peristiwa di konsol RDS. Untuk informasi lebih lanjut tentang bekerja dengan peristiwa, lihat Bekerja dengan pemberitahuan kejadian Amazon RDS.

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

Proses peningkatan terdiri dari tiga tahap:

1. Aurora melakukan serangkaian pemeriksaan sebelum memulai proses peningkatan. Klaster Anda terus berjalan sementara 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 beberapa jenis pernyataan SQL. Atau Anda mungkin hanya menunggu sampai pernyataan lama berjalan tertentu selesai. Kemudian coba mulai peningkatan lagi. Beberapa pemeriksaan tes untuk kondisi yang tidak mencegah peningkatan tetapi mungkin membuat peningkatan memakan waktu lama.

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

2. Aurora mengambil klaster Anda secara offline. Kemudian Aurora melakukan serangkaian tes serupa seperti pada tahap sebelumnya, untuk memastikan bahwa tidak ada masalah baru yang muncul selama proses shutdown. Jika Aurora mendeteksi kondisi apapun pada saat ini yang akan mencegah peningkatan, Aurora membatalkan peningkatan dan membawa klaster kembali online. Dalam hal ini, mengkonfirmasi ketika kondisi tidak lagi berlaku dan mulai peningkatan lagi.

3. Aurora menciptakan sebuah snapshot dari volume klaster Anda. Misalkan Anda menemukan kompatibilitas atau jenis lain dari masalah setelah peningkatan selesai. Atau anggaplah bahwa Anda ingin melakukan pengujian menggunakan kedua klaster asli dan peningkatan. Dalam kasus tersebut, Anda dapat memulihkan dari snapshot ini untuk membuat sebuah klaster baru dengan versi mesin asli dan data asli.

   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 permanen sampai Anda menghapusnya. Setelah Anda menyelesaikan semua pengujian pasca-peningkatan, Anda dapat menghapus snapshot ini untuk meminimalkan biaya penyimpanan.

4. Aurora mengkloning volume klaster Anda. Kloning adalah operasi cepat yang tidak melibatkan menyalin 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 kloning sementara selama peningkatan tidak tunduk pada batas biasa pada jumlah klon untuk satu volume klaster.

5. Aurora melakukan shutdown bersih untuk instans DB penulis. Selama shutdown bersih, kemajuan 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 versi lama dari baris.

   • Aurora mengembalikan setiap transaksi yang tidak terikat.

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 untuk alasan apapun, Aurora mengembalikan data asli dari volume klaster kloning.

7. Aurora meningkatkan versi mesin pada instans DB pembaca.

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

Cara melakukan peningkatan di tempat

Untuk meningkatkan versi besar dari klaster DB Aurora MySQL

1. (Opsional) Tinjau materi latar belakang di Cara kerja peningkatan versi besar Aurora MySQL di tempat. Melakukan perencanaan dan pengujian sebelum peningkatan, seperti yang dijelaskan dalam Merencanakan peningkatan versi besar untuk klaster Aurora MySQL.

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

3. Jika Anda menggunakan grup parameter kustom dengan klaster 1.x asli, buat grup parameter yang kompatibel dengan MySQL 5.7. Buat penyesuaian yang diperlukan untuk parameter konfigurasi di grup parameter baru itu. Untuk informasi selengkapnya, lihat Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster.

4. Di panel navigasi, pilih Database.

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

6. Pilih Modifikasi.

7. Untuk Versi, pilih versi Aurora MySQL 2.x.

8. Pilih Lanjutkan.

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

10. (Opsional) Periksa secara berkala halaman Peristiwa di konsol RDS selama peningkatan. Melakukan hal ini membantu Anda untuk memantau kemajuan peningkatan dan mengidentifikasi masalah apa pun. Jika peningkatan mengalami masalah apa pun, konsultasikan Pemecahan masalah untuk peningkatan di tempat Aurora MySQL untuk langkah-langkah yang harus diambil.

11. Jika Anda membuat grup parameter baru yang kompatibel dengan MySQL 5.7 di awal prosedur ini, kaitkan grup parameter khusus dengan klaster yang ditingkatkan versinya. Untuk informasi selengkapnya, lihat Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster.

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

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

Untuk meningkatkan versi besar klaster DB Aurora MySQL, gunakan klaster DB Aurora MySQL, gunakanAWS CLI modify-db-clusterperintah dengan parameter wajib berikut:

• --db-cluster-identifier

• --engine aurora-mysql

• --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 instance di klaster menggunakan grup parameter DB kustom

Contoh berikut meningkatkan klaster DB sample-cluster ke Aurora MySQL versi 2.09.0. Peningkatan terjadi segera, alih-alih menunggu jendela pemeliharaan berikutnya.

contoh

Untuk Linux, macOS, atau Unix:

aws rds modify-db-cluster \
          --db-cluster-identifier sample-cluster \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.09.0 \
          --allow-major-version-upgrade \
          --apply-immediately

Untuk Windows:

aws rds modify-db-cluster ^
          --db-cluster-identifier sample-cluster ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.09.0 ^
          --allow-major-version-upgrade ^
          --apply-immediately

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

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

• DBClusterIdentifier

• Engine

• EngineVersion

• AllowMajorVersionUpgrade

• ApplyImmediately (atur ke true atau false)

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.6 atau 5.7. Saat Anda melakukan peningkatan di tempat, klaster yang ditingkatkan dan semua instansnya harus menggunakan kluster yang kompatibel dengan 5.7 dan grup parameter instans. Jika klaster dan instans Anda menggunakan grup parameter default yang kompatibel dengan 5.6, klaster dan instans yang ditingkatkan akan dimulai dengan grup parameter default yang kompatibel dengan 5.7. Jika klaster dan instans Anda menggunakan grup parameter khusus apa pun, Anda harus membuat grup parameter yang kompatibel dengan 5.7 dan menentukannya selama proses peningkatan.

Jika klaster asli Anda menggunakan grup parameter cluster kustom yang kompatibel dengan 5.6, buat grup parameter klaster yang kompatibel dengan 5.7. Anda mengaitkan grup parameter tersebut dengan klaster sebagai bagian dari proses peningkatan.

Demikian pula, buat grup parameter DB yang kompatibel dengan 5.7. Anda mengaitkan grup parameter tersebut dengan semua instans DB di kluster sebagai bagian dari proses peningkatan.

Jika Anda menentukan grup parameter khusus apa pun selama proses peningkatan, Anda harus me-reboot klaster secara manual setelah pemutakhiran selesai. Melakukan hal itu membuat klaster mulai menggunakan pengaturan parameter kustom Anda.

Perubahan pada properti klaster antara Aurora MySQL versi 1 dan 2

Untuk klaster yang kompatibel dengan MySQL 5.6, nilai yang Anda gunakan untuk parameter engine dalam perintah AWS CLI atau operasi RDS API adalah aurora. Untuk klaster yang kompatibel dengan MySQL 5.7 atau klaster yang kompatibel dengan MySQL 5.7 atau 8.0, nilai yang sesuai adalahaurora-mysql. Saat Anda meningkatkan dari Aurora MySQL versi 1 ke versi 2 atau versi 3, pastikan untuk mengubah aplikasi atau skrip apa pun yang Anda gunakan untuk menyiapkan atau mengelola klaster Aurora MySQL dan instans DB.

Juga, ubah kode Anda yang memanipulasi grup parameter untuk memperhitungkan fakta bahwa nama grup parameter default berbeda untuk klaster yang kompatibel dengan MySQL 5.6, 5.7, dan 8.0. Nama grup parameter default untuk klaster Aurora MySQL versi 1 adalah default.aurora5.6. Nama grup parameter yang sesuai untuk kluster Aurora MySQL versi 2 dan 3 adalahdefault.aurora-mysql5.7dandefault.aurora-mysql8.0.

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

# Add a new DB instance to a MySQL 5.6-compatible cluster.
aws rds create-db-instance --db-instance-identifier instance-2020-04-28-6889 --db-cluster-identifier cluster-2020-04-28-2690 \
  --db-instance-class db.t2.small --engine aurora --region us-east-1

# Find the Aurora MySQL v1.x versions available for minor version upgrades and patching.
aws rds describe-orderable-db-instance-options --engine aurora --region us-east-1 \
  --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text

# Check the default parameter values for MySQL 5.6-compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora5.6 --region us-east-1

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

# Add a new DB instance to a MySQL 5.7-compatible cluster.
aws rds create-db-instance --db-instance-identifier instance-2020-04-28-3333 --db-cluster-identifier cluster-2020-04-28-2690 \
  --db-instance-class db.t2.small --engine aurora-mysql --region us-east-1

# Find the Aurora MySQL v2.x versions available for minor version upgrades and patching.
aws rds describe-orderable-db-instance-options --engine aurora-mysql --region us-east-1 \
  --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text

# 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

Peningkatan besar untuk basis data global

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

Ikuti instruksi di Cara kerja peningkatan versi besar Aurora MySQL di tempat. Saat Anda menentukan apa yang akan diupgrade, pastikan untuk memilih klaster database global, bukan salah satu klaster yang dikandungnya.

Jika Anda menggunakanAWS Management Console, pilih item dengan peranBasis data global.

Jika Anda menggunakan AWS CLI atau RDS API, mulai proses peningkatan dengan memanggil perintah modify-global-cluster atau operasi ModifyGlobalCluster alih-alih modify-db-cluster atau ModifyDBCluster.

Anda tidak dapat menentukan grup parameter khusus untuk klaster database global saat Anda melakukan peningkatan versi utama dari database global Aurora tersebut. Buat grup parameter kustom Anda di setiap Wilayah klaster global dan kemudian terapkan secara manual ke klaster Regional setelah upgrade.

Setelah peningkatan

Jika klaster yang Anda tingkatkan memiliki fitur backtrack diaktifkan, Anda tidak dapat melacak klaster yang ditingkatkan versinya ke waktu sebelum peningkatan.

Pemecahan masalah untuk peningkatan di tempat Aurora MySQL

Gunakan tips berikut untuk membantu memecahkan masalah dengan peningkatan di tempat Aurora MySQL. Kiat-kiat ini tidak berlaku untukAurora ServerlessPanel DB.

Anda dapat menggunakan langkah-langkah berikut untuk melakukan pemeriksaan Anda sendiri untuk beberapa kondisi di tabel sebelumnya. Dengan begitu, Anda dapat menjadwalkan peningkatan pada saat Anda mengetahui database dalam keadaan di mana peningkatan dapat diselesaikan dengan sukses dan cepat.

• Anda dapat memeriksa transaksi XA terbuka dengan menjalankan pernyataan XA RECOVER. Anda kemudian dapat melakukan atau memutar kembali transaksi XA sebelum memulai peningkatan.

• Anda dapat memeriksa pernyataan DDL dengan menjalankan pernyataan SHOW PROCESSLIST dan mencari pernyataan CREATE, DROP, ALTER, RENAME, dan TRUNCATE di output. Memungkinkan semua pernyataan DL untuk menyelesaikan sebelum memulai peningkatan.

• Anda dapat memeriksa jumlah total baris tidak terikat dengan membuat kueri tabel INFORMATION_SCHEMA.INNODB_TRX. Tabel berisi satu baris untuk setiap transaksi. Kolom TRX_ROWS_MODIFIED berisi jumlah baris 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 membatalkan disimpan oleh database untuk menerapkan multi-versi concurrency control (MVCC).

Tutorial peningkatan di tempat Aurora MySQL

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

Contoh pertama ini membuat klaster Aurora DB yang menjalankan Aurora MySQL versi 1.x. Klaster ini mencakup instans DB penulis dan instans DB pembaca. Klasterwait db-instance-availableperintah jeda hingga instans DB penulis tersedia. Pada saat itulah, klaster siap untuk ditingkatkan.

$ aws rds create-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --engine aurora \
  --db-cluster-version 5.6.mysql_aurora.1.22.3
...
$ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-7832 \
  --db-cluster-identifier cluster-56-2020-11-17-3824 --db-instance-class db.t2.medium --engine aurora
...
$ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-7832 --region us-east-1

Aurora MySQL 2.x versi yang dapat Anda tingkatkan untuk klaster bergantung pada versi 1.x klaster yang sedang berjalan dan di Wilayah AWS tempat klaster berada. Perintah pertama, dengan --output text, hanya menunjukkan versi target yang tersedia. Perintah kedua menunjukkan output JSON penuh respon. Dalam respons terperinci itu, Anda dapat melihat detail seperti nilai aurora-mysql yang Anda gunakan untuk parameter engine, dan fakta bahwa pemutakhiran ke 2.07.3 mewakili peningkatan versi utama.

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.6.mysql_aurora.1.22.3

$ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.3 \
  --query '*[].[ValidUpgradeTarget]'
[
    [
        [
            {
                "Engine": "aurora-mysql",
                "EngineVersion": "5.7.mysql_aurora.2.07.3",
                "Description": "Aurora (MySQL 5.7) 2.07.3",
                "AutoUpgrade": false,
                "IsMajorVersionUpgrade": true
            }
        ]
    ]
]

Contoh ini menunjukkan bagaimana jika Anda memasukkan nomor versi target yang bukan merupakan target peningkatan yang valid untuk klaster, Aurora tidak akan melakukan peningkatan. Aurora juga tidak akan melakukan peningkatan versi besar kecuali Anda menyertakan parameter --allow-major-version-upgrade. Dengan begitu, Anda tidak dapat secara tidak sengaja melakukan peningkatan yang memiliki potensi untuk memerlukan pengujian ekstensif dan perubahan kode aplikasi Anda.

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.04.9 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.6.mysql_aurora.1.22.3 with requested version 5.7.mysql_aurora.2.04.9.

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.09.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 cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "cluster-56-2020-11-17-9355",
  "Status": "available",
  "Engine": "aurora",
  "EngineVersion": "5.6.mysql_aurora.1.22.3"
}

Dibutuhkan beberapa saat untuk status klaster dan instans DB terkait untuk diubah 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 cluster-56-2020-11-17-9355 \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.6.mysql_aurora.1.22.3

$ aws rds describe-db-instances --db-instance-identifier instance-2020-11-17-5158 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "instance-2020-11-17-5158",
    "DBInstanceStatus": "upgrading"
}

$ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158

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

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --query '*[].[EngineVersion]' --output text
5.7.mysql_aurora.2.09.0

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

Contoh berikut meningkatkan klaster yang awalnya menjalankan Aurora MySQL versi 1.22.2. Di output describe-db-engine-versions, nilai False dan True mewakili properti IsMajorVersionUpgrade. Dari versi 1.22.2, Anda dapat meningkatkan ke beberapa versi 1.* lainnya. Peningkatan tersebut tidak dianggap sebagai peningkatan versi besar sehingga tidak memerlukan peningkatan di tempat. Peningkatan di tempat ini hanya tersedia untuk peningkatan ke versi 2.07 dan 2.09 yang ditampilkan dalam daftar.

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-3824 \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.6.mysql_aurora.1.22.2
$ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.6.mysql_aurora.1.22.3 False
5.6.mysql_aurora.1.23.0 False
5.6.mysql_aurora.1.23.1 False
5.7.mysql_aurora.2.07.1 True
5.7.mysql_aurora.2.07.1 True
5.7.mysql_aurora.2.07.2 True
5.7.mysql_aurora.2.07.3 True
5.7.mysql_aurora.2.09.1 True

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --no-apply-immediately --allow-major-version-upgrade
...

Ketika sebuah klaster dibuat tanpa jendela pemeliharaan tertentu, Aurora mengambil hari acak dalam seminggu. Dalam hal ini, perintah modify-db-cluster dikirimkan pada hari Senin. Dengan demikian, kita mengubah jendela pemeliharaan menjadi Selasa pagi. Semua waktu diwakili dalam zona waktu UTC. Jendela tue:10:00-tue:10:30 menunjukkan pukul 2-2:30 AM waktu Pasifik. Perubahan di jendela pemeliharaan segera berlaku.

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --preferred-maintenance-window tue:10:00-tue:10:30"
$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-3824 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

$ aws rds create-db-cluster --engine aurora --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --region us-east-1 --master-username my_username --master-user-password my_password
{
  "DBClusterIdentifier": "cluster-56-2020-11-17-9355",
  "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-9355",
  "Engine": "aurora",
  "EngineVersion": "5.6.mysql_aurora.1.22.2",
  "Status": "creating",
  "Endpoint": "cluster-56-2020-11-17-9355.cluster-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com",
  "ReaderEndpoint": "cluster-56-2020-11-17-9355.cluster-ro-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com"
}

$ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-5158 \
  --db-cluster-identifier cluster-56-2020-11-17-9355 --db-instance-class db.r5.large --region us-east-1 --engine aurora
{
  "DBInstanceIdentifier": "instance-2020-11-17-5158",
  "DBClusterIdentifier": "cluster-56-2020-11-17-9355",
  "DBInstanceClass": "db.r5.large",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158 --region us-east-1

Contoh berikut menunjukkan cara mendapatkan laporan dari peristiwa yang dihasilkan oleh peningkatan. Argumen --duration mewakili 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 cluster-56-2020-11-17-3824 --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2020-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-cluster-56-2020-11-17-3824-5-6-mysql-aurora-1-22-2-to-5-7-mysql-aurora-2-09-0-2020-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        }
    ]
}

Teknik peningkatan biru-hijau alternatif

Untuk situasi di mana prioritas utama adalah untuk melakukan peralihan langsung dari klaster lama ke klaster yang ditingkatkan, Anda dapat menggunakan proses multilangkah yang menjalankan klaster lama dan baru side-by-side. Dalam hal ini, Anda mereplikasi data dari klaster lama ke klaster baru hingga Anda siap untuk mengambil alih klaster baru. Untuk detailnya, lihat posting blog ini: Melakukan peningkatan versi besar untuk Amazon Aurora MySQL dengan downtime minimum.