Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Meningkatkan versi minor atau tingkat patch klaster DB Aurora MySQL
Anda dapat menggunakan metode berikut untuk meningkatkan versi minor klaster DB atau untuk mem-patch klaster DB:
+ [Meningkatkan Aurora MySQL dengan mengubah versi mesin](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (untuk Aurora MySQL versi 2 dan 3)
+ [Mengaktifkan upgrade otomatis antara Aurora minor versi Saya SQL](AuroraMySQL.Updates.AMVU.md)
Untuk informasi tentang cara patching zero-downtime dapat mengurangi gangguan selama proses peningkatan, lihat [Menggunakan zero-downtime patching](AuroraMySQL.Updates.ZDP.md).
Untuk informasi tentang melakukan upgrade versi minor untuk cluster DB MySQL Aurora Anda, lihat topik berikut.
**Topics**
+ [Sebelum melakukan upgrade versi minor](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Pra-cek pemutakhiran versi minor untuk Aurora MySQL](#AuroraMySQL.minor-upgrade-prechecks)
+ [Meningkatkan Aurora MySQL dengan mengubah versi mesin](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [Mengaktifkan upgrade otomatis antara Aurora minor versi Saya SQL](AuroraMySQL.Updates.AMVU.md)
+ [Menggunakan zero-downtime patching](AuroraMySQL.Updates.ZDP.md)
+ [Teknik blue/green peningkatan alternatif](#AuroraMySQL.UpgradingMinor.BlueGreen)
## Sebelum melakukan upgrade versi minor
Kami menyarankan Anda melakukan tindakan berikut untuk mengurangi waktu henti selama upgrade versi minor:
+ Pemeliharaan cluster Aurora DB harus dilakukan selama periode lalu lintas rendah. Gunakan Performance Insights untuk mengidentifikasi periode waktu ini agar dapat mengonfigurasi jendela pemeliharaan dengan benar. Untuk informasi selengkapnya tentang Performance Insights, lihat [Memantau pemuatan DB dengan Performance Insights di](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) Amazon RDS. Untuk informasi lebih lanjut tentang jendela pemeliharaan cluster DB,[Menyesuaikan periode pemeliharaan klaster DB yang dinginkan](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
+ Gunakan dukungan AWS SDKs itu backoff eksponensial dan jitter sebagai praktik terbaik. Untuk informasi lebih lanjut, lihat [Exponential Backoff](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) And Jitter.
## Pra-cek pemutakhiran versi minor untuk Aurora MySQL
Saat Anda memulai pemutakhiran versi minor, Amazon Aurora menjalankan prechecks secara otomatis.
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. Anda kemudian dapat menggunakan log untuk mempersiapkan database Anda untuk upgrade dengan mengurangi ketidakcocokan. Untuk informasi rinci tentang menghapus ketidakcocokan, lihat [Mempersiapkan instalasi Anda untuk upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) dalam dokumentasi MySQL.
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 RDS acara Amazon](USER_Events.md).
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](USER_LogAccess.Procedural.Viewing.md).
Karena sifatnya, pra-pemeriksaan akan menganalisis objek di basis data Anda. Analisis ini mengakibatkan konsumsi sumber daya dan menambah waktu penyelesaian peningkatan.
# Meningkatkan Aurora MySQL dengan mengubah versi mesin
Memutakhirkan versi minor dari cluster DB MySQL Aurora menerapkan perbaikan tambahan dan fitur baru ke cluster yang ada.
Peningkatan semacam ini berlaku untuk cluster Aurora MySQL di mana versi asli dan versi yang ditingkatkan keduanya memiliki versi utama Aurora MySQL yang sama, baik 2 atau 3. Prosesnya cepat dan mudah karena tidak memerlukan konversi apa pun untuk metadata Aurora MySQL atau penyusunan ulang data tabel Anda.
Anda melakukan upgrade semacam ini dengan memodifikasi versi mesin dari cluster DB menggunakan Konsol Manajemen AWS, AWS CLI, atau RDS API. Misalnya, jika cluster Anda menjalankan Aurora MySQL 3.x, pilih versi 3.x yang lebih tinggi.
Jika Anda melakukan peningkatan kecil pada Database Global Aurora, tingkatkan semua cluster sekunder sebelum Anda memutakhirkan klaster utama.
**catatan**
Untuk melakukan upgrade versi minor ke Aurora MySQL versi 3.04.\$1 atau lebih tinggi, atau versi 2.12.\$1, gunakan proses berikut:
Hapus semua Wilayah sekunder dari klaster global. Ikuti langkah-langkahnya dalam [Menghapus klaster dari basis data global Amazon Aurora](aurora-global-database-detaching.md).
Tingkatkan versi mesin Wilayah utama ke versi 3.04.\$1 atau lebih tinggi, atau versi 2.12.\$1, sebagaimana berlaku. Ikuti langkah-langkahnya dalam [To modify the engine version of a DB cluster](#modify-db-cluster-engine-version).
Tambahkan Wilayah sekunder ke klaster global. Ikuti langkah-langkahnya dalam [Menambahkan Wilayah AWS ke database global Amazon Aurora](aurora-global-database-attaching.md).
**Untuk mengubah versi mesin klaster DB**
+ **Dengan menggunakan konsol** – Ubah properti klaster Anda. Di jendela **Modifikasi klaster DB**, ubah versi mesin Aurora MySQL dalam kotak **Versi mesin DB**. Jika Anda tidak memahami prosedur umum untuk mengubah klaster, ikuti petunjuk dalam [Memodifikasi klaster DB dengan menggunakan konsol, CLI, dan API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
+ **Dengan menggunakan AWS CLI** — Panggil [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI perintah, dan tentukan nama cluster DB Anda untuk `--db-cluster-identifier` opsi dan versi mesin untuk `--engine-version` opsi tersebut.
Misalnya, untuk meningkatkan ke Aurora MySQL versi 3.04.1, atur opsi ke. `--engine-version` `8.0.mysql_aurora.3.04.1` Tentukan opsi `--apply-immediately` untuk segera memperbarui versi mesin untuk klaster DB Anda.
+ **Dengan menggunakan RDS API** — Panggil operasi [Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API, dan tentukan nama cluster DB Anda untuk `DBClusterIdentifier` parameter dan versi engine untuk `EngineVersion` parameter tersebut. Tetapkan parameter `ApplyImmediately` ke `true` untuk segera memperbarui versi mesin untuk klaster DB Anda.
# Mengaktifkan upgrade otomatis antara Aurora minor versi Saya SQL
Untuk klaster Amazon Aurora My SQL DB, Anda dapat menentukan bahwa Aurora memutakhirkan cluster DB secara otomatis ke versi minor baru. Anda melakukannya dengan menyetel `AutoMinorVersionUpgrade` properti (**Peningkatan versi minor otomatis** di Konsol Manajemen AWS) dari cluster DB.
Peningkatan otomatis terjadi selama periode pemeliharaan. Jika instans DB individu di klaster DB memiliki periode pemeliharaan yang berbeda dengan periode pemeliharaan klaster, periode pemeliharaan klaster akan diutamakan.
Upgrade versi minor otomatis tidak berlaku untuk jenis klaster Aurora My SQL berikut:
+ Klaster yang merupakan bagian dari basis data global Aurora.
+ Klaster yang memiliki replika lintas Wilayah.
Durasi pemadaman bervariasi tergantung pada beban kerja, ukuran cluster, jumlah data log biner, dan jika Aurora dapat menggunakan fitur zero-downtime patching (). ZDP Aurora mengaktifkan ulang klaster basis data, sehingga Anda mungkin mengalami periode ketidaktersediaan yang singkat sebelum melanjutkan penggunaan klaster Anda. Secara khusus, jumlah data log biner akan memengaruhi waktu pemulihan. Instans DB memproses data log biner selama pemulihan. Dengan demikian, volume tinggi data log biner akan menambah waktu pemulihan.
**catatan**
Aurora hanya melakukan peningkatan otomatis jika semua instans DB di cluster DB Anda mengaktifkan pengaturan. `AutoMinorVersionUpgrade` Untuk informasi tentang cara mengaturnya, dan cara kerjanya saat diterapkan di tingkat cluster dan instance, lihat[Peningkatan versi minor otomatis untuk klaster DB Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
Kemudian jika jalur pemutakhiran ada untuk instance cluster DB ke versi mesin DB minor yang telah `AutoUpgrade` disetel ke true, pemutakhiran akan dilakukan. `AutoUpgrade`Pengaturannya dinamis, dan diatur olehRDS.
Peningkatan versi minor otomatis dilakukan ke versi minor default.
Anda dapat menggunakan CLI perintah seperti berikut ini untuk memeriksa status `AutoMinorVersionUpgrade` pengaturan untuk semua instans DB di cluster Aurora SQL My Anda.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
Perintah ini menghasilkan output yang serupa dengan berikut:
```
[
{
"DBInstanceIdentifier": "db-t2-medium-instance",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-t2-small-original-size",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "instance-2020-05-01-2332",
"DBClusterIdentifier": "cluster-57-2020-05-01-4615",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
Dalam contoh ini, opsi **Aktifkan peningkatan versi minor otomatis** dinonaktifkan untuk klaster DB `cluster-57-2020-06-03-6411`, karena dinonaktifkan untuk salah satu instans DB dalam klaster.
# Menggunakan zero-downtime patching
Melakukan upgrade untuk Aurora SQL My DB cluster melibatkan kemungkinan pemadaman ketika database dimatikan dan saat sedang ditingkatkan. Secara default, jika Anda memulai peningkatan saat basis data sibuk, Anda akan kehilangan semua koneksi dan transaksi yang sedang diproses oleh klaster DB. Jika Anda menunggu hingga basis data idle untuk melakukan peningkatan, Anda mungkin harus menunggu lama.
Fitur zero-downtime patching (ZDP) mencoba, dengan upaya terbaik, untuk mempertahankan koneksi klien melalui peningkatan Aurora My. SQL Jika ZDP berhasil diselesaikan, sesi aplikasi dipertahankan dan mesin database restart saat upgrade sedang berlangsung. Pengaktifan ulang mesin basis data dapat menyebabkan penurunan throughput yang berlangsung selama beberapa detik hingga kira-kira satu menit.
ZDPtidak berlaku untuk yang berikut:
+ Patch dan peningkatan sistem operasi (OS)
+ Peningkatan versi mayor
ZDPtersedia untuk semua SQL versi Aurora My yang didukung dan kelas instans DB.
ZDPtidak didukung untuk Aurora Serverless v1 atau database global Aurora.
**catatan**
Kami menyarankan penggunaan kelas instans DB T hanya untuk server pengembangan dan pengujian, atau server non-produksi lainnya. Untuk detail selengkapnya tentang kelas instans T, lihat [Menggunakan kelas instans T untuk pengembangan dan pengujian](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Anda dapat melihat metrik atribut penting selama ZDP di log SQL kesalahan saya. Anda juga dapat melihat informasi tentang kapan Aurora My SQL menggunakan ZDP atau memilih untuk tidak menggunakan ZDP pada halaman **Acara** di halaman. Konsol Manajemen AWS
Di Aurora My, SQL Aurora dapat melakukan patch zero-downtime apakah replikasi log biner diaktifkan atau tidak. Jika replikasi log biner diaktifkan, Aurora SQL My secara otomatis menjatuhkan koneksi ke target binlog selama operasi. ZDP Aurora My SQL secara otomatis terhubung kembali ke target binlog dan melanjutkan replikasi setelah restart selesai.
ZDPjuga berfungsi dalam kombinasi dengan peningkatan reboot di Aurora My. SQL Patching terhadap instans DB penulis akan secara otomatis menjalankan patching terhadap pembaca secara bersamaan. Setelah melakukan patching, Aurora memulihkan koneksi pada instans DB penulis dan pembaca.
ZDPmungkin tidak berhasil diselesaikan dalam kondisi berikut:
+ Kueri atau transaksi berjalan lama sedang berlangsung. Jika Aurora dapat melakukan ZDP dalam kasus ini, setiap transaksi terbuka dibatalkan tetapi koneksi mereka dipertahankan.
+ Tabel sementara, kunci pengguna, atau kunci tabel sedang digunakan, misalnya saat pernyataan bahasa definisi data (DDL) berjalan. Aurora menjatuhkan koneksi ini.
+ Ada perubahan parameter tertunda.
Jika tidak ada jendela waktu yang sesuai untuk melakukan ZDP menjadi tersedia karena satu atau lebih dari kondisi ini, patch kembali ke perilaku standar.
Meskipun koneksi tetap utuh setelah ZDP operasi yang berhasil, beberapa variabel dan fitur diinisialisasi ulang. Jenis informasi berikut ini tidak dipertahankan selama pengaktifan ulang yang disebabkan oleh zero-downtime patching:
+ Variabel global. Aurora memulihkan variabel sesi, tetapi tidak memulihkan variabel global setelah pengaktifan ulang.
+ Variabel status. Secara khusus, nilai uptime yang dilaporkan oleh status engine diatur ulang setelah restart yang menggunakan ZDP mekanisme ZDR atau.
+ `LAST_INSERT_ID`.
+ Status `auto_increment` dalam memori untuk tabel. Status inkremen otomatis dalam memori diinisialisasi ulang. Untuk informasi selengkapnya tentang nilai kenaikan otomatis, lihat Panduan [SQLReferensi Saya](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization).
+ Informasi diagnostik dari tabel `INFORMATION_SCHEMA` dan `PERFORMANCE_SCHEMA`. Informasi diagnostik ini juga muncul dalam output perintah seperti `SHOW PROFILE` dan `SHOW PROFILES`.
Aktivitas berikut yang berkaitan dengan pengaktifan ulang dengan nol waktu henti akan dilaporkan di halaman **Peristiwa**:
+ Mencoba meningkatkan basis data dengan nol waktu henti.
+ Mencoba meningkatkan basis data dengan nol waktu henti selesai. Peristiwa ini melaporkan berapa lama prosesnya berjalan. Peristiwa ini juga melaporkan berapa banyak koneksi yang dipertahankan selama pengaktifan ulang dan berapa banyak koneksi yang terputus. Anda dapat melihat log kesalahan basis data untuk melihat detail selengkapnya tentang apa yang terjadi selama pengaktifan ulang.
## Teknik blue/green peningkatan alternatif
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 Amazon Blue/Green Aurora Deployment untuk pembaruan database](blue-green-deployments.md).