Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengelola Amazon Aurora MySQL
Bagian berikut membahas pengelolaan klaster DB Amazon Aurora MySQL.
**Topics**
+ [Mengelola performa dan penskalaan untuk Amazon Aurora MySQL](AuroraMySQL.Managing.Performance.md)
+ [Melakukan backtracking klaster DB Aurora](AuroraMySQL.Managing.Backtrack.md)
+ [Menguji Amazon Aurora MySQL menggunakan kueri injeksi kesalahan](AuroraMySQL.Managing.FaultInjectionQueries.md)
+ [Mengubah tabel di Amazon Aurora menggunakan DDL Cepat](AuroraMySQL.Managing.FastDDL.md)
+ [Menampilkan status volume untuk klaster DB Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md)
# Mengelola performa dan penskalaan untuk Amazon Aurora MySQL
## Penskalaan instans DB Aurora MySQL
Anda dapat menskalakan instans DB Aurora MySQL dengan dua cara, penskalaan instans dan penskalaan baca. Untuk informasi selengkapnya tentang penskalaan baca, lihat [Penskalaan baca](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Anda dapat menskalakan klaster DB Aurora MySQL Anda dengan mengubah kelas instans DB untuk setiap instans DB dalam klaster DB. Aurora MySQL mendukung beberapa kelas instans DB yang dioptimalkan untuk Aurora. Jangan gunakan kelas instans db.t2 atau db.t3 untuk klaster Aurora yang berukuran lebih dari 40 TB. Untuk spesifikasi kelas instans DB yang didukung Aurora MySQL, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md).
**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).
## Koneksi maksimum ke instans DB Aurora MySQL
Jumlah maksimum koneksi yang diizinkan untuk instans DB Aurora MySQL ditentukan oleh parameter `max_connections` dalam grup parameter tingkat instans untuk instans DB.
Tabel berikut mencantumkan nilai default yang dihasilkan berupa `max_connections` untuk setiap kelas instans DB yang tersedia untuk Aurora MySQL. Anda dapat meningkatkan jumlah maksimum koneksi ke instans DB Aurora MySQL Anda dengan menaikkan skala instans ke kelas instans DB dengan lebih banyak memori, atau dengan menetapkan nilai yang lebih besar untuk parameter `max_connections` di grup parameter DB untuk instans Anda, hingga 16.000.
**Tip**
Jika aplikasi Anda sering membuka dan menutup koneksi, atau membiarkan sejumlah besar koneksi yang lama aktif tetap terbuka, kami menyarankan agar Anda menggunakan Proksi Amazon RDS. Proksi RDS adalah proksi basis data yang sepenuhnya terkelola dengan ketersediaan tinggi yang menggunakan pooling koneksi untuk berbagi koneksi basis data dengan aman dan efisien. Untuk mempelajari tentang Proksi RDS, lihat [Proksi Amazon RDS untuk Aurora](rds-proxy.md).
Untuk detail tentang cara instans Aurora Serverless v2 menangani parameter ini, lihat [Koneksi maksimum untuk Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
| Kelas instans | Nilai default max\$1connections |
| --- | --- |
| db.t2.small | 45 |
| db.t2.medium | 90 |
| db.t3.small | 45 |
| db.t3.medium | 90 |
| db.t3.large | 135 |
| db.t4g.medium | 90 |
| db.t4g.large | 135 |
| db.r3.large | 1000 |
| db.r3.xlarge | 2000 |
| db.r3.2xlarge | 3000 |
| db.r3.4xlarge | 4000 |
| db.r3.8xlarge | 5000 |
| db.r4.large | 1000 |
| db.r4.xlarge | 2000 |
| db.r4.2xlarge | 3000 |
| db.r4.4xlarge | 4000 |
| db.r4.8xlarge | 5000 |
| db.r4.16xlarge | 6000 |
| db.r5.large | 1000 |
| db.r5.xlarge | 2000 |
| db.r5.2xlarge | 3000 |
| db.r5.4xlarge | 4000 |
| db.r5.8xlarge | 5000 |
| db.r5.12xlarge | 6000 |
| db.r5.16xlarge | 6000 |
| db.r5.24xlarge | 7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6000 |
| db.r6g.16xlarge | 6000 |
| db.r6i.large | 1000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6000 |
| db.r6i.16xlarge | 6000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6000 |
| db.r7g.16xlarge | 6000 |
| db.r7i.large | 1000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6000 |
| db.r7i.16xlarge | 6000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6000 |
| db.r8g.16xlarge | 6000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
**Tip**
Perhitungan `max_connections` parameter menggunakan basis log 2 (berbeda dari logaritma natural) dan `DBInstanceClassMemory` nilai dalam byte untuk kelas instance Aurora MySQL yang dipilih. Parameter hanya menerima nilai integer, dengan bagian desimal terpotong dari perhitungan. Rumus mengimplementasikan batas koneksi sebagai berikut:
Peningkatan koneksi 1000 untuk instans R3, R4, dan R5 yang lebih besar
45 peningkatan koneksi untuk varian memori instans T2 dan T3
Contoh: Untuk db.r6g.large, sedangkan rumus menghitung 1069.2, sistem mengimplementasikan 1000 untuk mempertahankan pola inkremental yang konsisten.
Jika Anda membuat grup parameter baru untuk menyesuaikan nilai default Anda sendiri untuk batas koneksi, Anda akan melihat bahwa batas koneksi default akan diperoleh menggunakan formula berdasarkan nilai `DBInstanceClassMemory`. Seperti ditunjukkan dalam tabel sebelumnya, rumus ini menghasilkan batas koneksi yang bertambah sebanyak 1000 saat memorinya berlipat ganda antara instans R3, R4, dan R5 yang makin besar, dan sebanyak 45 untuk ukuran memori yang berbeda-beda pada instans T2 dan T3.
Lihat [Menentukan parameter DB](USER_ParamValuesRef.md) untuk detail selengkapnya tentang cara `DBInstanceClassMemory` dihitung.
instans DB Aurora MySQL dan RDS for MySQL memiliki jumlah overhead memori yang berbeda. Oleh karena itu, nilai `max_connections` dapat berbeda untuk instans DB Aurora MySQL dan RDS for MySQL yang menggunakan kelas instans yang sama. Nilai-nilai dalam tabel ini hanya berlaku untuk instans DB Aurora MySQL.
**catatan**
Batas konektivitas untuk instans T2 dan T3 jauh lebih rendah karena dengan Aurora, kelas instans tersebut hanya ditujukan untuk skenario pengembangan dan pengujian, bukan untuk beban kerja produksi.
Batas koneksi default disesuaikan untuk sistem yang menggunakan nilai default untuk pemakai memori besar lainnya, seperti pool buffer dan cache kueri. Jika Anda mengubah pengaturan lain tersebut untuk klaster Anda, pertimbangkan untuk menyesuaikan batas koneksi agar memperhitungkan peningkatan atau penurunan memori yang tersedia pada instans DB.
## Batas penyimpanan sementara untuk Aurora MySQL
Aurora MySQL menyimpan tabel dan indeks dalam subsistem penyimpanan Aurora. Aurora MySQL menggunakan penyimpanan sementara atau lokal terpisah untuk file sementara nonpersisten dan tabel sementara non-InnoDB. Penyimpanan lokal juga mencakup file yang digunakan untuk tujuan seperti mengurutkan set data besar selama pemrosesan kueri atau untuk operasi pembuatan indeks. Itu tidak termasuk tabel sementara InnoDB.
Untuk informasi selengkapnya tentang tabel sementara di Aurora MySQL versi 3, lihat [Perilaku tabel sementara baru di Aurora MySQL versi 3](ams3-temptable-behavior.md). Untuk informasi selengkapnya tentang tabel sementara di versi 2, lihat [Perilaku tablespace sementara di Aurora Versi saya 2 SQL](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.TempTables57).
Data dan file sementara pada volume ini hilang saat memulai dan menghentikan instans DB, dan selama penggantian host.
Volume penyimpanan lokal ini didukung oleh Amazon Elastic Block Store (EBS) dan dapat diperluas dengan menggunakan kelas instans DB yang lebih besar. Untuk informasi selengkapnya tentang penyimpanan, lihat [Penyimpanan Amazon Aurora](Aurora.Overview.StorageReliability.md).
Penyimpanan lokal juga digunakan untuk mengimpor data dari Amazon S3 `LOAD DATA FROM S3` menggunakan `LOAD XML FROM S3` atau, dan untuk mengekspor data ke S3 menggunakan SELECT INTO OUTFILE S3. Untuk informasi lebih lanjut tentang mengimpor dari dan mengekspor ke S3, lihat berikut ini:
+ [Memuat data ke klaster DB Amazon Aurora MySQL dari file teks di bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md)
+ [Menyimpan data dari klaster DB Amazon Aurora MySQL ke dalam file teks di bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md)
Aurora MySQL menggunakan penyimpanan permanen terpisah untuk log kesalahan, log umum, log kueri lambat, dan log audit untuk sebagian besar kelas instans Aurora MySQL DB (tidak termasuk tipe kelas instance berkinerja burstable seperti db.t2, db.t3, dan db.t4g). Data pada volume ini dipertahankan saat memulai dan menghentikan instans DB, dan selama penggantian host.
Volume penyimpanan permanen ini juga didukung oleh Amazon EBS dan memiliki ukuran tetap sesuai dengan kelas instans DB. Itu tidak dapat diperpanjang dengan menggunakan kelas instans DB yang lebih besar.
Tabel berikut menunjukkan jumlah maksimum penyimpanan sementara dan permanen yang tersedia untuk setiap kelas instans MySQL Aurora MySQL DB. Untuk informasi selengkapnya tentang dukungan kelas instans DB untuk Aurora, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md).
| Kelas instans DB | temporary/local Penyimpanan maksimum yang tersedia (GiB) | Penyimpanan maksimum tambahan tersedia untuk file log (GiB) |
| --- | --- | --- |
| db.x2g.16xlarge | 1280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
**penting**
Nilai-nilai ini merepresentasikan jumlah maksimum teoretis penyimpanan kosong di setiap instans DB. Penyimpanan lokal sebenarnya yang tersedia untuk Anda mungkin lebih rendah. Aurora menggunakan beberapa penyimpanan lokal untuk proses manajemennya, dan instans DB menggunakan beberapa penyimpanan lokal bahkan sebelum Anda memuat data apa pun. Anda dapat memantau penyimpanan sementara yang tersedia untuk instans DB tertentu dengan `FreeLocalStorage` CloudWatch metrik, yang dijelaskan dalam[CloudWatch Metrik Amazon untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Anda dapat memeriksa jumlah penyimpanan kosong saat ini. Anda juga dapat memetakan jumlah penyimpanan kosong dari waktu ke waktu. Memantau penyimpanan kosong dari waktu ke waktu membantu Anda menentukan apakah nilainya meningkat atau menurun, atau untuk menemukan nilai minimum, maksimum, atau rata-rata.
(Hal ini tidak berlaku untuk Aurora Serverless v2.)
# Melakukan backtracking klaster DB Aurora
Dengan Amazon Aurora Edisi Kompatibel MySQL, Anda dapat melakukan backtracking klaster DB ke waktu tertentu, tanpa memulihkan data dari cadangan.
**Contents**
+ [Gambaran umum backtracking](#AuroraMySQL.Managing.Backtrack.Overview)
+ [Jendela backtrack](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [Waktu backtracking](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [Batasan backtracking](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [Ketersediaan wilayah dan versi](#AuroraMySQL.Managing.Backtrack.Availability)
+ [Pertimbangan peningkatan untuk klaster yang memiliki backtrack aktif](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Mengkonfigurasi mundur cluster DB MySQL Aurora](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Melakukan backtrack untuk cluster Aurora SQL My DB](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Memantau backtracking untuk cluster DB MySQL Aurora](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [Berlangganan peristiwa backtrack dengan konsol](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [Mengambil backtrack yang ada](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Menonaktifkan backtracking untuk cluster Aurora My DB SQL](AuroraMySQL.Managing.Backtrack.Disabling.md)
## Gambaran umum backtracking
Backtracking “memundurkan” klaster DB ke waktu yang Anda tentukan. Backtracking bukan pengganti untuk mencadangkan klaster DB sehingga Anda dapat memulihkannya ke suatu titik waktu. Namun, backtracking memberikan keuntungan berikut dibandingkan pencadangan dan pemulihan biasa:
+ Anda dapat dengan mudah membatalkan kesalahan. Jika Anda tanpa sengaja melakukan tindakan destruktif, seperti DELETE tanpa klausa WHERE, Anda dapat melakukan backtracking klaster DB ke waktu sebelum tindakan destruktif tersebut dilakukan dengan gangguan layanan minimal.
+ Anda dapat melakukan backtracking klaster DB dengan cepat. Memulihkan klaster DB ke titik waktu akan meluncurkan klaster DB baru dan memulihkannya dari data cadangan atau snapshot klaster DB, yang dapat memakan waktu berjam-jam. Backtracking klaster DB tidak memerlukan klaster DB baru dan memundurkan klaster DB dalam hitungan menit.
+ Anda dapat menjelajahi perubahan data sebelumnya. Anda dapat berulang kali melakukan backtracking klaster DB secara tepat waktu untuk membantu menentukan kapan perubahan data tertentu terjadi. Misalnya, Anda dapat melakukan backtracking klaster DB tiga jam lalu melacak maju dalam waktu satu jam. Dalam hal ini, waktu backtrack adalah dua jam sebelum waktu asli.
**catatan**
Untuk informasi tentang memulihkan klaster DB ke suatu titik waktu, lihat [Gambaran umum pencadangan dan pemulihan klaster DB Aurora](Aurora.Managing.Backups.md).
### Jendela backtrack
Dengan backtrack, ada jendela backtrack target dan jendela backtrack aktual:
+ *Jendela backtrack target* adalah jumlah waktu yang Anda inginkan untuk dapat melakukan backtracking klaster DB Anda. Saat Anda mengaktifkan backtrack, Anda menentukan *jendela backtrack target*. Misalnya, Anda dapat menentukan jendela backtrack target selama 24 jam jika Anda ingin dapat melakukan backtracking klaster DB selama satu hari.
+ *Jendela backtrack aktual* adalah jumlah waktu aktual yang Anda inginkan untuk dapat melakukan backtracking klaster DB, yang dapat lebih kecil daripada jendela backtrack target. Jendela backtrack aktual didasarkan pada beban kerja dan penyimpanan yang tersedia untuk menyimpan informasi tentang perubahan basis data, yang disebut *catatan perubahan.*
Saat Anda membuat pembaruan pada klaster Aurora DB dengan backtracking aktif, Anda menghasilkan catatan perubahan. Aurora menyimpan catatan perubahan untuk jendela backtrack target, dan Anda membayar tarif per jam untuk menyimpannya. Jendela backtrack target dan beban kerja di klaster DB Anda menentukan jumlah catatan perubahan yang Anda simpan. Beban kerja adalah jumlah perubahan yang Anda buat pada klaster DB Anda dalam waktu tertentu. Jika beban kerja Anda berat, Anda menyimpan lebih banyak perubahan catatan di jendela backtrack dibandingkan jika beban kerja Anda ringan.
Anda dapat membayangkan jendela backtrack target sebagai sasaran jumlah waktu yang Anda inginkan untuk dapat melakukan backtracking klaster DB Anda. Dalam kebanyakan kasus, Anda dapat melakukan backtracking dalam jumlah waktu maksimum yang Anda tentukan. Namun, dalam beberapa kasus, klaster DB tidak dapat menyimpan cukup catatan untuk melakukan backtracking dalam jumlah waktu maksimum, dan jendela backtrack aktual Anda lebih kecil daripada target Anda. Biasanya, jendela backtrack aktual lebih kecil daripada target saat Anda memiliki beban kerja yang sangat berat pada klaster DB Anda. Saat jendela backtrack aktual Anda lebih kecil dari target, kami mengirimkan notifikasi kepada Anda.
Saat backtracking diaktifkan untuk klaster DB, dan Anda menghapus tabel yang disimpan dalam klaster DB, Aurora mempertahankan tabel tersebut di catatan perubahan backtrack. Ini dilakukan agar Anda dapat kembali ke waktu sebelum Anda menghapus tabel. Jika Anda tidak memiliki cukup ruang di jendela backtrack Anda untuk menyimpan tabel, pada akhirnya tabel mungkin akan dihapus dari catatan perubahan backtrack.
### Waktu backtracking
Aurora selalu melakukan backtracking ke waktu yang konsisten untuk klaster DB. Tindakan ini menghilangkan kemungkinan transaksi yang tidak di-commit saat backtrack selesai. Saat Anda menentukan waktu untuk backtrack, Aurora akan secara otomatis memilih waktu konsisten sedekat mungkin. Pendekatan ini berarti bahwa backtrack yang diselesaikan mungkin tidak sama persis dengan waktu yang Anda tentukan, tetapi Anda dapat menentukan waktu yang tepat untuk backtrack dengan menggunakan perintah CLI [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS . Untuk informasi selengkapnya, lihat [Mengambil backtrack yang ada](#AuroraMySQL.Managing.Backtrack.Retrieving).
### Batasan backtracking
Batasan berikut berlaku untuk backtracking:
+ Backtracking hanya tersedia untuk klaster DB yang dibuat dengan fitur Backtrack diaktifkan. Anda tidak dapat memodifikasi cluster DB untuk mengaktifkan fitur Backtrack. Anda dapat mengaktifkan fitur Backtrack saat membuat klaster DB baru atau memulihkan snapshot klaster DB.
+ Batasan untuk jendela backtrack adalah 72 jam.
+ Backtracking memengaruhi seluruh klaster DB. Misalnya, Anda tidak dapat memilih untuk melakukan backtracking satu tabel atau satu pembaruan data.
+ Anda tidak dapat membuat replika baca lintas wilayah dari cluster yang mendukung backtrack, tetapi Anda masih dapat mengaktifkan replikasi log biner (binlog) di cluster. Jika Anda mencoba untuk mundur cluster DB yang logging biner diaktifkan, kesalahan biasanya terjadi kecuali Anda memilih untuk memaksa backtrack. Setiap upaya untuk memaksa backtrack akan merusak replika baca hilir dan mengganggu operasi lain seperti penerapan. blue/green
+ Anda tidak dapat melakukan backtracking klon basis data ke waktu sebelum klon basis data tersebut dibuat. Namun, Anda dapat menggunakan basis data asli untuk melakukan backtracking ke suatu waktu sebelum klon dibuat. Untuk informasi selengkapnya tentang kloning basis data, lihat [Mengkloning volume untuk klaster DB Amazon Aurora](Aurora.Managing.Clone.md).
+ Backtracking akan menyebabkan gangguan instans DB dalam waktu singkat. Anda harus menghentikan atau menjeda aplikasi sebelum memulai operasi backtrack untuk memastikan bahwa tidak ada permintaan baca atau tulis baru. Selama operasi backtrack, Aurora menjeda basis data, menutup semua koneksi yang terbuka, dan menghentikan operasi baca dan tulis yang tidak di-commit. Aurora kemudian menunggu operasi backtrack selesai.
+ Anda tidak dapat memulihkan snapshot Lintas wilayah dari klaster berkemampuan backtrack di AWS Wilayah yang tidak mendukung backtracking.
+ Jika Anda melakukan peningkatan di tempat untuk klaster yang memiliki backtrack aktif dari Aurora MySQL versi 2 ke versi 3, Anda tidak dapat melakukan backtracking ke titik waktu sebelum peningkatan terjadi.
## Ketersediaan wilayah dan versi
Backtracking tidak tersedia untuk Aurora PostgreSQL.
Berikut ini adalah mesin yang didukung dan ketersediaan Wilayah untuk Backtrack dengan Aurora MySQL.
| Wilayah | Aurora MySQL versi 3 | Aurora MySQL versi 2 |
| --- | --- | --- |
| AS Timur (Virginia Utara) | Semua versi | Semua versi |
| AS Timur (Ohio) | Semua versi | Semua versi |
| AS Barat (California Utara) | Semua versi | Semua versi |
| AS Barat (Oregon) | Semua versi | Semua versi |
| Afrika (Cape Town) | – | – |
| Asia Pasifik (Hong Kong) | – | – |
| Asia Pasifik (Jakarta) | – | – |
| Asia Pasifik (Malaysia) | – | – |
| Asia Pacific (Melbourne) | – | – |
| Asia Pasifik (Mumbai) | Semua versi | Semua versi |
| Asia Pasifik (Selandia Baru) | – | – |
| Asia Pasifik (Osaka) | Semua versi | Versi 2.07.3 dan lebih tinggi |
| Asia Pasifik (Seoul) | Semua versi | Semua versi |
| Asia Pasifik (Singapura) | Semua versi | Semua versi |
| Asia Pasifik (Sydney) | Semua versi | Semua versi |
| Asia Pasifik (Taipei) | – | – |
| Asia Pasifik (Thailand) | – | – |
| Asia Pasifik (Tokyo) | Semua versi | Semua versi |
| Kanada (Pusat) | Semua versi | Semua versi |
| Kanada Barat (Calgary) | – | – |
| China (Beijing) | – | – |
| Tiongkok (Ningxia) | – | – |
| Eropa (Frankfurt) | Semua versi | Semua versi |
| Eropa (Irlandia) | Semua versi | Semua versi |
| Eropa (London) | Semua versi | Semua versi |
| Eropa (Milan) | – | – |
| Eropa (Paris) | Semua versi | Semua versi |
| Eropa (Spanyol) | – | – |
| Eropa (Stockholm) | – | – |
| Eropa (Zürich) | – | – |
| Israel (Tel Aviv) | – | – |
| Meksiko (Tengah) | – | – |
| Timur Tengah (Bahrain) | – | – |
| Timur Tengah (UEA) | – | – |
| Amerika Selatan (Sao Paulo) | – | – |
| AWS GovCloud (AS-Timur) | – | – |
| AWS GovCloud (AS-Barat) | – | – |
## Pertimbangan peningkatan untuk klaster yang memiliki backtrack aktif
Anda dapat meningkatkan klaster DB yang memiliki backtrack aktif dari Aurora MySQL versi 2 ke versi 3 karena semua versi minor Aurora MySQL versi 3 didukung untuk Backtrack.
# Mengkonfigurasi mundur cluster DB MySQL Aurora
Untuk menggunakan fitur Backtrack, Anda harus mengaktifkan backtracking dan menentukan jendela backtrack target. Jika tidak, backtracking dinonaktifkan.
Untuk Jendela Backtrack Target, tentukan jumlah waktu yang Anda inginkan untuk dapat memundurkan basis data Anda menggunakan Backtrack. Aurora mencoba mempertahankan catatan perubahan yang cukup untuk mendukung periode waktu tersebut.
## Konsol
Anda dapat menggunakan konsol untuk mengonfigurasi backtracking saat Anda membuat klaster DB baru. Anda juga dapat memodifikasi klaster DB untuk mengubah jendela backtrack untuk klaster yang memiliki backtrack aktif. Jika Anda menonaktifkan backtrack sepenuhnya untuk klaster dengan mengatur jendela backtrack ke 0, Anda tidak dapat mengaktifkan backtrack lagi untuk klaster tersebut.
**Topics**
+ [Mengonfigurasi backtracking dengan konsol saat membuat klaster DB](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Creating)
+ [Mengonfigurasi backtrack dengan konsol saat memodifikasi klaster DB](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Modifying)
### Mengonfigurasi backtracking dengan konsol saat membuat klaster DB
Saat Anda membuat klaster DB Aurora MySQL baru, backtracking akan dikonfigurasi jika Anda memilih **Aktifkan Backtrack** dan menentukan **Jendela Backtrack Target** yang lebih besar dari nol di bagian **Backtrack**.
Untuk membuat klaster DB, ikuti petunjuk dalam [Membuat klaster DB Amazon Aurora](Aurora.CreateInstance.md). Gambar berikut menunjukkan bagian **Backtrack**.
![\[Aktifkan Backtrack selama pembuatan klaster DB dengan konsol\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-create.png)
Ketika Anda membuat klaster DB baru, Aurora tidak memiliki data untuk beban kerja klaster DB. Jadi, Aurora tidak memperkirakan biaya secara khusus untuk klaster DB baru. Sebagai gantinya, konsol akan menampilkan biaya pengguna standar untuk jendela backtrack target yang ditentukan berdasarkan beban kerja standar. Biaya standar dimaksudkan untuk memberikan referensi umum untuk biaya fitur Backtrack.
**penting**
Biaya Anda sebenarnya mungkin tidak sama dengan biaya standar karena biaya Anda sebenarnya didasarkan pada beban kerja klaster DB Anda.
### Mengonfigurasi backtrack dengan konsol saat memodifikasi klaster DB
Anda dapat memodifikasi backtrack untuk klaster DB menggunakan konsol.
**catatan**
Saat ini, Anda dapat memodifikasi backtracking hanya untuk klaster DB yang memiliki fitur Backtrack aktif. Bagian **Backtrack** ini tidak muncul untuk klaster DB yang dibuat dengan fitur Backtrack dinonaktifkan atau jika fitur Backtrack telah dinonaktifkan untuk klaster DB tersebut.
**Untuk memodifikasi backtracking untuk klaster DB menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih klaster yang ingin Anda ubah, dan pilih **Modifikasi**.
1. Untuk **Jendela Backtrack Target**, ubah jumlah waktu yang Anda inginkan untuk dapat melakukan backtracking. Batasannya adalah 72 jam.
![\[Modifikasi Backtrack dengan konsol\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-modify.png)
Konsol menunjukkan perkiraan biaya untuk jumlah waktu yang Anda tentukan berdasarkan beban kerja terdahulu di klaster DB:
+ Jika pelacakan balik dinonaktifkan pada klaster DB, perkiraan biaya didasarkan metrik untuk `VolumeWriteIOPS` klaster DB di Amazon CloudWatch.
+ Jika pelacakan balik diaktifkan sebelumnya pada klaster DB, perkiraan biaya didasarkan metrik untuk `BacktrackChangeRecordsCreationRate` klaster DB di Amazon CloudWatch.
1. Pilih **Lanjutkan**.
1. Untuk **Penjadwalan Modifikasi**, pilih salah satu dari berikut ini:
+ **Terapkan selama jendela pemeliharaan terjadwal berikutnya** – Tunggu untuk menerapkan modifikasi **Jendela Backtrack Target** hingga periode pemeliharaan berikutnya.
+ **Terapkan segera** – Terapkan modifikasi **Jendela Backtrack Target** sesegera mungkin.
1. Pilih **Ubah klaster**.
## AWS CLI
Saat Anda membuat cluster Aurora MySQL DB baru menggunakan perintah [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI, backtracking dikonfigurasi saat Anda menentukan nilai yang lebih besar dari nol. `--backtrack-window` Nilai `--backtrack-window` menentukan jendela backtrack target. Untuk informasi selengkapnya, lihat [Membuat klaster DB Amazon Aurora](Aurora.CreateInstance.md).
Anda juga dapat menentukan `--backtrack-window` nilai menggunakan perintah AWS CLI berikut:
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
Prosedur berikut menjelaskan cara memodifikasi jendela backtrack target untuk klaster DB menggunakan AWS CLI.
**Untuk memodifikasi jendela backtrack target untuk cluster DB menggunakan AWS CLI**
+ Panggil perintah [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI dan berikan nilai-nilai berikut:
+ `--db-cluster-identifier` – Nama klaster DB.
+ `--backtrack-window` – Jumlah maksimum detik yang Anda inginkan untuk melakukan backtracking klaster DB.
Contoh berikut mengatur jendela backtrack target untuk `sample-cluster` ke satu hari (86.400 detik).
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 86400
```
Untuk Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 86400
```
**catatan**
Saat ini, Anda dapat mengaktifkan backtracking hanya untuk klaster DB yang dibuat dengan fitur Backtrack aktif.
## API RDS
Saat Anda membuat cluster DB Aurora MySQL baru menggunakan operasi Create [DBClusterAmazon](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) RDS API, backtracking dikonfigurasi saat Anda menentukan nilai yang lebih besar dari nol. `BacktrackWindow` Nilai `BacktrackWindow` menentukan jendela backtrack target untuk klaster DB yang ditentukan dalam nilai `DBClusterIdentifier`. Untuk informasi selengkapnya, lihat [Membuat klaster DB Amazon Aurora](Aurora.CreateInstance.md).
Anda juga dapat menentukan nilai `BacktrackWindow` yang sesuai dengan operasi API berikut:
+ [Memodifikasi DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [Kembalikan DBCluster dari3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [MemulihkanDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [MemulihkanDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
**catatan**
Saat ini, Anda dapat mengaktifkan backtracking hanya untuk klaster DB yang dibuat dengan fitur Backtrack aktif.
# Melakukan backtrack untuk cluster Aurora SQL My DB
Anda dapat melakukan backtracking klaster DB ke stempel waktu backtrack tertentu. Jika stempel waktu backtrack tidak lebih awal dari waktu backtrack yang paling awal, dan tidak di masa depan, klaster DB akan di-backtracking ke stempel waktu tersebut.
Jika tidak, biasanya terjadi kesalahan. Selain itu, jika Anda mencoba untuk melakukan backtracking klaster DB yang memiliki pencatatan log biner aktif, kesalahan biasanya terjadi kecuali jika Anda telah memilih untuk memaksa backtrack untuk terjadi. Memaksa backtrack agar terjadi dapat mengganggu operasi lain yang menggunakan pencatatan log biner.
**penting**
Backtracking tidak menghasilkan entri binlog untuk perubahan yang dibuatnya. Jika Anda mengaktifkan pencatatan log biner untuk klaster DB, backtracking mungkin tidak kompatibel dengan implementasi binlog Anda.
**catatan**
Untuk klon basis data, Anda tidak dapat melakukan backtracking klaster DB lebih awal dari tanggal dan waktu ketika klon dibuat. Untuk informasi selengkapnya tentang kloning basis data, lihat [Mengkloning volume untuk klaster DB Amazon Aurora](Aurora.Managing.Clone.md).
## Konsol
Prosedur berikut menjelaskan cara melakukan operasi backtrack untuk klaster DB menggunakan konsol.
**Untuk melakukan operasi backtrack menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Instans**.
1. Pilih instans primer untuk klaster DB yang ingin Anda backtrack.
1. Untuk **Tindakan**, pilih **Klaster DB Backtrack**.
1. Di halaman **Klaster DB Backtrack**, masukkan stempel waktu backtrack untuk melakukan backtracking klaster DB.
![\[Klaster DB backtrack\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-db-cluster.png)
1. Pilih **Klaster DB Backtrack**.
## AWS CLI
Prosedur berikut menjelaskan cara melakukan backtracking klaster DB menggunakan AWS CLI.
**Untuk mundur cluster DB menggunakan AWS CLI**
+ Panggil [backtrack-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/backtrack-db-cluster.html) AWS CLIperintah dan berikan nilai-nilai berikut:
+ `--db-cluster-identifier` – Nama klaster DB.
+ `--backtrack-to`— Cap waktu backtrack untuk mundur cluster DB ke, ditentukan dalam ISO format 8601.
Contoh berikut melakukan backtracking klaster DB `sample-cluster` ke 19 Maret 2018, pukul 10.00.
Untuk Linux, macOS, atau Unix:
```
aws rds backtrack-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
```
Untuk Windows:
```
aws rds backtrack-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-to 2018-03-19T10:00:00+00:00
```
## RDS API
Untuk mundur cluster DB menggunakan Amazon RDSAPI, gunakan acktrackDBCluster operasi [B](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BacktrackDBCluster.html). Operasi ini melakukan backtracking klaster DB yang ditentukan dalam nilai `DBClusterIdentifier` ke waktu yang ditentukan.
# Memantau backtracking untuk cluster DB MySQL Aurora
Anda dapat melihat informasi backtracking dan memantau metrik backtracking untuk klaster DB.
## Konsol
**Untuk melihat informasi backtracking dan memantau metrik backtracking menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih nama klaster DB untuk membuka informasi tentangnya.
Informasi backtrack ada di bagian **Backtrack**.
![\[Detail backtrack untuk klaster DB\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-details.png)
Saat backtrack diaktifkan, informasi berikut tersedia:
+ **Jendela target** – Jumlah waktu saat ini yang ditentukan untuk jendela backtrack target. Target adalah jumlah waktu maksimum yang Anda inginkan untuk melakukan backtracking jika ada penyimpanan yang memadai.
+ **Jendela aktual** – Jumlah waktu aktual yang Anda inginkan untuk dapat melakukan backtracking, yang dapat lebih kecil daripada jendela backtrack target. Jendela backtrack aktual didasarkan pada beban kerja Anda dan penyimpanan yang tersedia untuk mempertahankan catatan perubahan backtrack.
+ **Waktu backtrack paling awal** – Waktu backtrack paling awal yang memungkinkan untuk klaster DB. Anda tidak dapat melakukan backtracking klaster DB ke waktu sebelum waktu yang ditampilkan.
1. Lakukan hal berikut untuk melihat metrik backtracking untuk klaster DB:
1. Di panel navigasi, pilih **Instans**.
1. Pilih nama instans primer untuk klaster DB untuk menampilkan detailnya.
1. Di bagian **CloudWatch**, tik **Backtrack** ke dalam kotak **CloudWatch** untuk menampilkan hanya metrik Backtrack.
![\[Metrik backtrack\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-metrics.png)
Metrik berikut ditampilkan:
+ **Laju Pembuatan Catatan Perubahan Backtrack (Hitungan)** – Metrik ini menunjukkan jumlah catatan perubahan backtrack yang dibuat selama lima menit untuk klaster DB Anda. Anda dapat menggunakan metrik ini untuk memperkirakan biaya backtrack untuk jendela backtrack target Anda.
+ **[Ditagih] Catatan Perubahan Backtrack Disimpan (Hitungan)** – Metrik ini menunjukkan jumlah aktual RDS perubahan backtrack yang digunakan oleh klaster DB Anda.
+ **Jendela Backtrack Aktual (Menit)** – Metrik ini menunjukkan apakah terdapat perbedaan antara jendela backtrack target dan jendela backtrack aktual. Sebagai contoh, jika jendela backtrack target Anda adalah 2 jam (120 menit), dan metrik ini menunjukkan bahwa jendela backtrack aktual adalah 100 menit, berarti jendela backtrack aktual lebih kecil dari target.
+ **Peringatan Jendela Backtrack (Hitungan)** – Metrik ini menunjukkan jumlah berapa kali jendela backtrack aktual lebih kecil daripada jendela backtrack target untuk periode waktu tertentu.
**catatan**
Metrik berikut mungkin mengalami lag dari waktu saat ini:
**Laju Pembuatan Catatan Perubahan Backtrack (Hitungan)**
**[Ditagih] Catatan Perubahan Backtrack Disimpan (Hitungan)**
## AWS CLI
Prosedur berikut menjelaskan cara menampilkan informasi backtrack untuk klaster DB menggunakan AWS CLI.
**Untuk melihat informasi backtrack untuk cluster DB menggunakan AWS CLI**
+ Panggil perintah [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI dan berikan nilai-nilai berikut:
+ `--db-cluster-identifier` – Nama klaster DB.
Contoh berikut mencantumkan informasi backtrack untuk `sample-cluster`.
Untuk Linux, macOS, atau Unix:
```
aws rds describe-db-clusters \
--db-cluster-identifier sample-cluster
```
Untuk Windows:
```
aws rds describe-db-clusters ^
--db-cluster-identifier sample-cluster
```
## API RDS
Untuk melihat informasi backtrack untuk cluster DB menggunakan Amazon RDS API, gunakan operasi [DBClustersDeskripsikan](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html). Operasi ini menampilkan informasi backtrack untuk klaster DB yang ditentukan dalam nilai `DBClusterIdentifier`.
## Berlangganan peristiwa backtrack dengan konsol
Prosedur berikut menjelaskan cara berlangganan peristiwa backtrack menggunakan konsol. Peristiwa tersebut mengirimkan notifikasi email atau pesan teks saat jendela backtrack aktual Anda lebih kecil dari jendela backtrack target Anda.
**Untuk melihat informasi backtrack menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Langganan peristiwa**.
1. Pilih **Buat langganan peristiwa**.
1. Di kotak **Nama**, ketik nama untuk langganan peristiwa, dan pastikan bahwa **Ya** dipilih untuk **Diaktifkan**.
1. Di bagian **Target**, pilih **Topik email baru**.
1. Untuk **Nama topik**, ketik nama untuk topik, dan untuk **Dengan penerima ini**, masukkan alamat email atau nomor telepon untuk menerima notifikasi.
1. Di bagian **Sumber**, pilih **Instans** untuk **Jenis sumber**.
1. Untuk **Instans untuk disertakan**, klik **Pilih instans tertentu**, dan pilih instans DB Anda.
1. Untuk **Kategori peristiwa untuk disertakan**, klik **Pilih kategori peristiwa tertentu**, dan pilih **backtrack**.
Halaman Anda akan terlihat serupa dengan halaman berikut.
![\[Langganan peristiwa backtrack\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. Pilih **Buat**.
## Mengambil backtrack yang ada
Anda dapat mengambil informasi tentang backtrack yang ada untuk klaster DB. Informasi ini mencakup pengidentifikasi unik backtrack, rentang tanggal dan waktu backtracking, tanggal dan waktu backtrack diminta, dan status backtrack saat ini.
**catatan**
Saat ini, Anda tidak dapat mengambil backtrack yang ada menggunakan konsol.
### AWS CLI
Prosedur berikut menjelaskan cara mengambil backtrack yang ada untuk klaster DB menggunakan AWS CLI.
**Untuk mengambil backtrack yang ada menggunakan AWS CLI**
+ Panggil perintah [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS CLI dan berikan nilai-nilai berikut:
+ `--db-cluster-identifier` – Nama klaster DB.
Contoh berikut mengambil backtrack yang ada untuk `sample-cluster`.
Untuk Linux, macOS, atau Unix:
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Untuk Windows:
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### API RDS
Untuk mengambil informasi tentang backtrack untuk cluster DB menggunakan Amazon RDS API, gunakan operasi [Deskripsikan DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html) Backtracks. Operasi ini menampilkan informasi tentang backtrack untuk klaster DB yang ditentukan dalam nilai `DBClusterIdentifier`.
# Menonaktifkan backtracking untuk cluster Aurora My DB SQL
Anda dapat menonaktifkan fitur Backtrack untuk klaster DB.
## Konsol
Anda dapat menonaktifkan backtracking untuk klaster DB menggunakan konsol. Setelah Anda menonaktifkan backtracking sepenuhnya untuk sebuah klaster, Anda tidak dapat mengaktifkannya lagi untuk klaster tersebut.
**Untuk menonaktifkan fitur Backtrack untuk klaster DB menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih klaster yang ingin Anda ubah, dan pilih **Modifikasi**.
1. Di bagian **Backtrack**, pilih **Nonaktifkan Backtrack**.
1. Pilih **Lanjutkan**.
1. Untuk **Penjadwalan Modifikasi**, pilih salah satu dari berikut ini:
+ **Terapkan selama jendela pemeliharaan terjadwal berikutnya** – Tunggu untuk menerapkan modifikasi hingga periode pemeliharaan berikutnya.
+ **Terapkan segera** – Terapkan modifikasi sesegera mungkin.
1. Pilih **Ubah Klaster**.
## AWS CLI
Anda dapat menonaktifkan fitur Backtrack untuk cluster DB menggunakan AWS CLI dengan mengatur jendela target backtrack ke `0` (nol). Setelah Anda menonaktifkan backtracking sepenuhnya untuk sebuah klaster, Anda tidak dapat mengaktifkannya lagi untuk klaster tersebut.
**Untuk memodifikasi jendela backtrack target untuk cluster DB menggunakan AWS CLI**
+ Panggil [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLIperintah dan berikan nilai-nilai berikut:
+ `--db-cluster-identifier` – Nama klaster DB.
+ `--backtrack-window` – tentukan `0` untuk menonaktifkan backtrack.
Contoh berikut menonaktifkan fitur Backtrack untuk `sample-cluster` dengan mengatur `--backtrack-window` ke `0`.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 0
```
Untuk Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 0
```
## RDS API
Untuk menonaktifkan fitur Backtrack untuk cluster DB menggunakan Amazon RDSAPI, gunakan odifyDBCluster operasi [M](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Atur nilai `BacktrackWindow` ke `0` (nol), dan tentukan klaster DB dalam nilai `DBClusterIdentifier`. Setelah Anda menonaktifkan backtracking sepenuhnya untuk sebuah klaster, Anda tidak dapat mengaktifkannya lagi untuk klaster tersebut.
# Menguji Amazon Aurora MySQL menggunakan kueri injeksi kesalahan
Anda dapat menguji toleransi kesalahan klaster DB Aurora MySQL Anda menggunakan kueri injeksi kesalahan. Kueri injeksi kesalahan dikeluarkan sebagai perintah SQL ke instans Amazon Aurora. Kueri ini memungkinkan Anda menjadwalkan simulasi kemunculan salah satu peristiwa berikut:
+ Crash instans DB penulis atau pembaca
+ Kegagalan Replika Aurora
+ Kegagalan disk
+ Kepadatan disk
Ketika kueri injeksi kesalahan menentukan sebuah crash, kueri ini akan memaksa crash pada instans DB Aurora MySQL. Kueri injeksi kesalahan lainnya menghasilkan simulasi peristiwa kegagalan, tetapi tidak menyebabkan peristiwa terjadi. Jika Anda mengirim kueri injeksi kesalahan, Anda juga perlu menentukan durasi waktu untuk simulasi peristiwa kegagalan yang akan terjadi.
Anda dapat mengirim kueri injeksi kesalahan ke salah satu instans Replika Aurora dengan menghubungkan ke titik akhir untuk Replika Aurora tersebut. Untuk informasi selengkapnya, lihat [Koneksi titik akhir Amazon Aurora](Aurora.Overview.Endpoints.md).
Untuk menjalankan kueri injeksi kesalahan, diperlukan semua hak akses pengguna master. Untuk informasi selengkapnya, lihat [Hak akses akun pengguna master](UsingWithRDS.MasterAccounts.md).
## Menguji crash instans
Anda dapat memaksa crash instans Amazon Aurora menggunakan kueri injeksi kesalahan `ALTER SYSTEM CRASH`.
Untuk kueri injeksi kesalahan, failover tidak akan terjadi. Jika Anda ingin menguji failover, Anda dapat memilih tindakan instance **Failover** untuk cluster DB Anda di konsol RDS, atau menggunakan [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI perintah atau operasi [Failover DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) RDS API.
### Sintaksis
```
1. ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
```
### Opsi
Kueri injeksi kesalahan ini menggunakan salah satu dari jenis crash berikut:
+ **`INSTANCE`** – Crash basis data yang kompatibel dengan MySQL untuk instans Amazon Aurora disimulasikan.
+ **`DISPATCHER`** — Crash dispatcher pada instans penulis untuk klaster DB Aurora disimulasikan. *Dispatcher* menulis pembaruan ke volume klaster untuk klaster DB Amazon Aurora.
+ **`NODE`** – Crash basis data yang kompatibel dengan MySQL dan dispatcher untuk instans Amazon Aurora disimulasikan. Untuk simulasi injeksi kesalahan ini, cache juga dihapus.
Jenis crash default adalah `INSTANCE`.
## Menguji kegagalan replika Aurora
Anda dapat menyimulasikan kegagalan Replika Aurora menggunakan kueri injeksi kesalahan `ALTER SYSTEM SIMULATE READ REPLICA FAILURE`.
Kegagalan Replika Aurora akan memblokir semua permintaan dari instans penulis ke Replika Aurora atau semua Replika Aurora dalam klaster DB untuk interval waktu yang ditentukan. Ketika interval waktu selesai, Replika Aurora yang terpengaruh akan secara otomatis disinkronkan dengan instance penulis.
### Sintaksis
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
2. [ TO ALL | TO "replica name" ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opsi
Kueri injeksi kesalahan ini mengambil parameter berikut:
+ **`percentage_of_failure`** – Persentase permintaan yang akan diblokir selama peristiwa kegagalan. Nilai ini dapat berupa double antara 0 dan 100. Jika Anda menetapkan 0, tidak ada permintaan yang akan diblokir. Jika Anda menentukan 100, semua permintaan akan diblokir.
+ **failure\$1type** – Jenis kegagalan yang akan disimulasikan. Tentukan `TO ALL` untuk menyimulasikan kegagalan untuk semua Replika Aurora dalam klaster DB. Tentukan `TO` dan nama Replika Aurora untuk menyimulasikan kegagalan Replika Aurora tunggal. Jenis kegagalan default adalah `TO ALL`.
+ **`quantity`** – Jumlah waktu untuk menyimulasikan kegagalan Replika Aurora. Interval adalah jumlah yang diikuti oleh unit waktu. Simulasi akan terjadi untuk jumlah unit yang ditentukan tersebut. Misalnya, `20 MINUTE` akan menghasilkan simulasi berjalan selama 20 menit.
**catatan**
Berhati-hatilah saat menentukan interval waktu untuk peristiwa kegagalan Replika Aurora Anda. Jika Anda menentukan interval waktu yang terlalu panjang, dan instans penulis Anda menulis data dalam jumlah besar selama peristiwa kegagalan, maka klaster DB Aurora Anda mungkin menganggap bahwa Replika Aurora telah crash lalu menggantinya.
## Menguji kegagalan disk
Anda dapat menyimulasikan kegagalan disk untuk klaster DB Aurora menggunakan kueri injeksi kesalahan `ALTER SYSTEM SIMULATE DISK FAILURE`.
Selama simulasi kegagalan disk, klaster DB Aurora secara acak menandai segmen disk sebagai mengalami kesalahan. Permintaan ke segmen tersebut akan diblokir selama durasi simulasi.
### Sintaksis
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
2. [ IN DISK index | NODE index ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opsi
Kueri injeksi kesalahan ini mengambil parameter berikut:
+ **`percentage_of_failure`** – Persentase disk yang akan ditandai sebagai mengalami kesalahan selama peristiwa kegagalan. Nilai ini dapat berupa double antara 0 dan 100. Jika Anda menentukan 0, tidak ada disk yang akan ditandai sebagai mengalami kesalahan. Jika Anda menentukan 100, seluruh disk akan ditandai sebagai mengalami kesalahan.
+ **`DISK index`** – Blok data logis data tertentu untuk menyimulasikan peristiwa kegagalan. Jika Anda melampaui rentang blok data logis yang tersedia, Anda akan menerima kesalahan yang memberi tahu Anda nilai indeks maksimum yang dapat Anda tentukan. Untuk informasi selengkapnya, lihat [Menampilkan status volume untuk klaster DB Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`NODE index`** – Simpul penyimpanan spesifik untuk menyimulasikan peristiwa kegagalan. Jika Anda melebihi rentang simpul penyimpanan yang tersedia, Anda akan menerima kesalahan yang memberi tahu Anda nilai indeks maksimum yang dapat Anda tentukan. Untuk informasi selengkapnya, lihat [Menampilkan status volume untuk klaster DB Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`quantity`** – Jumlah waktu untuk menyimulasikan kegagalan disk. Interval adalah jumlah yang diikuti oleh unit waktu. Simulasi akan terjadi untuk jumlah unit yang ditentukan tersebut. Misalnya, `20 MINUTE` akan menghasilkan simulasi berjalan selama 20 menit.
## Menguji kepadatan disk
Anda dapat menyimulasikan kegagalan disk untuk klaster DB Aurora menggunakan kueri injeksi kesalahan `ALTER SYSTEM SIMULATE DISK CONGESTION`.
Selama simulasi kepadatan disk, klaster DB Aurora secara acak menandai segmen disk sebagai padat. Permintaan ke segmen tersebut akan ditunda antara waktu penundaan minimum dan maksimum yang ditentukan untuk durasi simulasi.
### Sintaksis
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
2. BETWEEN minimum AND maximum MILLISECONDS
3. [ IN DISK index | NODE index ]
4. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opsi
Kueri injeksi kesalahan ini mengambil parameter berikut:
+ **`percentage_of_failure`** – Persentase disk yang akan ditandai sebagai padat selama peristiwa kegagalan. Nilai ini dapat berupa double antara 0 dan 100. Jika Anda menetapkan 0, tidak ada disk yang ditandai sebagai padat. Jika Anda menetapkan 100, seluruh disk akan ditandai sebagai padat.
+ **`DISK index` Atau `NODE index`** – Disk atau simpul tertentu untuk menyimulasikan peristiwa kegagalan. Jika Anda melebihi rentang indeks untuk disk atau simpul, Anda akan menerima kesalahan yang memberi tahu Anda nilai indeks maksimum yang dapat Anda tentukan.
+ **`minimum` Dan `maximum`** – Jumlah penundaan kepadatan minimum dan maksimum, dalam milidetik. Segmen disk yang ditandai sebagai padat akan ditunda selama jumlah waktu acak dalam rentang jumlah minimum dan maksimum milidetik untuk durasi simulasi.
+ **`quantity`** – Jumlah waktu untuk menyimulasikan kepadatan disk. Interval adalah jumlah yang diikuti oleh unit waktu. Simulasi akan terjadi untuk jumlah unit waktu yang ditentukan. Misalnya, `20 MINUTE` akan menghasilkan simulasi yang berjalan selama 20 menit.
# Mengubah tabel di Amazon Aurora menggunakan DDL Cepat
Amazon Aurora menyediakan pengoptimalan untuk menjalankan operasi `ALTER TABLE` di tempat, hampir seketika. Operasi ini akan selesai tanpa mengharuskan tabel disalin dan tanpa memiliki dampak besar pada pernyataan DML lainnya. Karena operasi ini tidak menggunakan penyimpanan sementara untuk salinan tabel, hal ini membuat pernyataan DDL praktis bahkan untuk tabel besar pada kelas instans kecil.
Aurora MySQL versi 3 kompatibel dengan fitur MySQL 8.0 yang disebut DDL instan. Aurora MySQL versi 2 menggunakan implementasi berbeda yang disebut DDL Cepat.
**Topics**
+ [DDL instan (Aurora MySQL versi 3)](#AuroraMySQL.mysql80-instant-ddl)
+ [DDL Cepat (Aurora MySQL versi 2)](#AuroraMySQL.Managing.FastDDL-v2)
## DDL instan (Aurora MySQL versi 3)
Optimisasi yang dilakukan oleh Aurora MySQL versi 3 untuk meningkatkan efisiensi beberapa operasi DDL disebut DDL instan.
Aurora MySQL versi 3 kompatibel dengan DDL instan dari MySQL 8.0 komunitas. Anda melakukan operasi DDL instan dengan menggunakan klausa `ALGORITHM=INSTANT` dengan pernyataan `ALTER TABLE`. Untuk detail sintaksis dan penggunaan DDL instan, lihat [ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) dan [Online DDL Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html) dalam dokumentasi MySQL.
Contoh berikut menunjukkan fitur DDL instan. Pernyataan `ALTER TABLE` menambahkan kolom dan mengubah nilai kolom default. Contoh ini mencakup kolom reguler dan virtual, dan tabel reguler dan berpartisi. Pada setiap langkah, Anda dapat melihat hasilnya dengan mengeluarkan pernyataan `SHOW CREATE TABLE` dan `DESCRIBE`.
```
mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)) PARTITION BY KEY(b) PARTITIONS 6;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 MODIFY COLUMN c ENUM('a', 'b', 'c', 'd', 'e'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN (d INT GENERATED ALWAYS AS (a + 1) VIRTUAL), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t2 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t3 (a INT, b INT) PARTITION BY LIST(a)(
-> PARTITION mypart1 VALUES IN (1,3,5),
-> PARTITION MyPart2 VALUES IN (2,4,6)
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> ALTER TABLE t3 ALTER COLUMN a SET DEFAULT 20, ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t4 (a INT, b INT) PARTITION BY RANGE(a)
-> (PARTITION p0 VALUES LESS THAN(100), PARTITION p1 VALUES LESS THAN(1000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE);
Query OK, 0 rows affected (0.05 sec)
mysql> ALTER TABLE t4 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
/* Sub-partitioning example */
mysql> CREATE TABLE ts (id INT, purchased DATE, a INT, b INT)
-> PARTITION BY RANGE( YEAR(purchased) )
-> SUBPARTITION BY HASH( TO_DAYS(purchased) )
-> SUBPARTITIONS 2 (
-> PARTITION p0 VALUES LESS THAN (1990),
-> PARTITION p1 VALUES LESS THAN (2000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE
-> );
Query OK, 0 rows affected (0.10 sec)
mysql> ALTER TABLE ts ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
```
## DDL Cepat (Aurora MySQL versi 2)
Fast DDL di Aurora MySQL adalah optimasi yang dirancang untuk meningkatkan kinerja perubahan skema tertentu, seperti menambahkan atau menjatuhkan kolom, dengan mengurangi waktu henti dan penggunaan sumber daya. Hal ini memungkinkan operasi ini diselesaikan lebih efisien dibandingkan dengan metode DDL tradisional.
**penting**
Saat ini, Anda harus mengaktifkan mode lab Aurora untuk menggunakan Fast DDL. Untuk informasi tentang mengaktifkan mode lab, lihat[Mode lab Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md).
Optimasi Fast DDL awalnya diperkenalkan dalam mode lab pada Aurora MySQL versi 2 untuk meningkatkan efisiensi operasi DDL tertentu. Di Aurora MySQL versi 3, mode lab telah dihentikan, dan Fast DDL telah digantikan oleh fitur MySQL 8.0 Instant DDL.
Di MySQL, banyak operasi bahasa definisi data (DDL) memiliki dampak performa yang signifikan.
Misalnya, anggaplah bahwa Anda menggunakan operasi `ALTER TABLE` untuk menambahkan kolom ke tabel. Bergantung pada algoritma yang ditentukan untuk operasi, operasi ini dapat memerlukan hal-hal berikut:
+ Membuat salinan lengkap tabel
+ Membuat tabel sementara untuk memproses operasi bahasa manipulasi data (DML) konkuren
+ Membuat kembali semua indeks untuk tabel
+ Menerapkan kunci tabel sambil menerapkan perubahan DML konkuren
+ Memperlambat throughput DML konkuren
Dampak kinerja ini bisa sangat menantang di lingkungan dengan tabel besar atau volume transaksi yang tinggi. Fast DDL membantu mengurangi tantangan ini dengan mengoptimalkan perubahan skema, yang memungkinkan operasi yang lebih cepat dan kurang intensif sumber daya.
### Batasan DDL Cepat
Saat ini, DDL Cepat memiliki batasan berikut:
+ DDL Cepat hanya mendukung penambahan kolom yang dapat dibuat null, tanpa nilai default, ke akhir tabel yang ada.
+ DDL Cepat tidak berfungsi untuk tabel yang dipartisi.
+ DDL Cepat tidak berfungsi untuk tabel InnoDB yang menggunakan format baris REDUNDANT.
+ DDL Cepat tidak berfungsi untuk tabel dengan indeks pencarian teks lengkap.
+ Jika ukuran catatan maksimum yang mungkin untuk operasi DDL terlalu besar, DDL Cepat tidak digunakan. Ukuran catatan terlalu besar jika lebih besar dari setengah ukuran halaman. Ukuran maksimum catatan dihitung dengan menjumlahkan ukuran maksimum semua kolom. Untuk kolom dengan ukuran bervariasi, yang mengikuti standar InnoDB, byte extern tidak disertakan untuk perhitungan.
### Sintaksis DDL Cepat
```
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
```
Pernyataan ini mengambil opsi berikut:
+ **`tbl_name`** – Nama tabel yang akan diubah.
+ **`col_name`** – Nama kolom yang akan ditambahkan.
+ **`col_definition`** – Definisi kolom yang akan ditambahkan.
**catatan**
Anda harus menentukan kolom yang dapat dibuat null tanpa nilai default. Jika tidak, DDL Cepat tidak digunakan.
### Contoh DDL Cepat
Contoh berikut menunjukkan percepatan dari operasi DDL Cepat. Contoh SQL pertama menjalankan pernyataan `ALTER TABLE` pada tabel besar tanpa menggunakan DDL Cepat. Operasi ini membutuhkan waktu yang cukup lama. Salah satu contoh CLI ini menunjukkan cara mengaktifkan DDL Cepat untuk klaster. Kemudian, contoh SQL lainnya menjalankan pernyataan `ALTER TABLE` yang sama pada tabel yang identik. Dengan mengaktifkan DDL Cepat, operasinya sangat cepat.
Contoh ini menggunakan tabel `ORDERS` dari tolok ukur TPC-H, yang berisi 150 juta baris. Klaster ini sengaja menggunakan kelas instans yang relatif kecil untuk menunjukkan waktu yang diperlukan pernyataan `ALTER TABLE` saat Anda tidak dapat menggunakan DDL Cepat. Contoh ini membuat klon dari tabel asli yang berisi data identik. Dengan memeriksa pengaturan `aurora_lab_mode`, akan dikonfirmasi bahwa klaster tidak dapat menggunakan DDL Cepat karena mode lab tidak diaktifkan. Kemudian, pernyataan `ALTER TABLE ADD COLUMN` membutuhkan banyak waktu untuk menambahkan kolom baru di akhir tabel.
```
mysql> create table orders_regular_ddl like orders;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into orders_regular_ddl select * from orders;
Query OK, 150000000 rows affected (1 hour 1 min 25.46 sec)
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 0 |
+-------------------+
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (40 min 31.41 sec)
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (40 min 44.45 sec)
```
Contoh ini melakukan persiapan tabel besar yang sama seperti contoh sebelumnya. Namun, Anda tidak bisa begitu saja mengaktifkan mode lab dalam sesi SQL interaktif. Pengaturan tersebut harus diaktifkan dalam grup parameter kustom. Melakukannya membutuhkan peralihan dari `mysql` sesi dan menjalankan beberapa perintah AWS CLI atau menggunakan. Konsol Manajemen AWS
```
mysql> create table orders_fast_ddl like orders;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into orders_fast_ddl select * from orders;
Query OK, 150000000 rows affected (58 min 3.25 sec)
mysql> set aurora_lab_mode=1;
ERROR 1238 (HY000): Variable 'aurora_lab_mode' is a read only variable
```
Pengaktifan mode lab untuk klaster memerlukan beberapa pekerjaan dengan grup parameter. Contoh AWS CLI ini menggunakan grup parameter cluster, untuk memastikan bahwa semua instance DB di cluster menggunakan nilai yang sama untuk pengaturan mode lab.
```
$ aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora5.7 \
--db-cluster-parameter-group-name lab-mode-enabled-57 --description 'TBD'
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].[ParameterName,ParameterValue]' \
--output text | grep aurora_lab_mode
aurora_lab_mode 0
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--parameters ParameterName=aurora_lab_mode,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lab-mode-enabled-57"
}
# Assign the custom parameter group to the cluster that's going to use Fast DDL.
$ aws rds modify-db-cluster --db-cluster-identifier tpch100g \
--db-cluster-parameter-group-name lab-mode-enabled-57
{
"DBClusterIdentifier": "tpch100g",
"DBClusterParameterGroup": "lab-mode-enabled-57",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.2",
"Status": "available"
}
# Reboot the primary instance for the cluster tpch100g:
$ aws rds reboot-db-instance --db-instance-identifier instance-2020-12-22-5208
{
"DBInstanceIdentifier": "instance-2020-12-22-5208",
"DBInstanceStatus": "rebooting"
}
$ aws rds describe-db-clusters --db-cluster-identifier tpch100g \
--query '*[].[DBClusterParameterGroup]' --output text
lab-mode-enabled-57
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
--output text | grep aurora_lab_mode
aurora_lab_mode 1
```
Contoh berikut menunjukkan langkah-langkah yang tersisa setelah perubahan grup parameter berlaku. Contoh ini menguji pengaturan `aurora_lab_mode` untuk memastikan bahwa klaster dapat menggunakan DDL Cepat. Contoh ini kemudian menjalankan pernyataan `ALTER TABLE` untuk menambahkan kolom ke akhir tabel besar lainnya. Kali ini, pernyataan selesai dengan sangat cepat.
```
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 1 |
+-------------------+
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (1.51 sec)
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (0.40 sec)
```
# Menampilkan status volume untuk klaster DB Aurora MySQL
Di Amazon Aurora, volume klaster DB terdiri dari sekumpulan blok logis. Masing-masing blok merepresentasikan 10 gigabyte penyimpanan yang dialokasikan. Blok-blok ini disebut *grup perlindungan*.
Data di setiap grup perlindungan direplikasi di enam perangkat penyimpanan fisik, yang disebut *simpul penyimpanan*. Simpul penyimpanan ini dialokasikan di tiga Zona Ketersediaan (AZ) di Wilayah AWS tempat klaster DB berada. Pada gilirannya, setiap simpul penyimpanan berisi satu atau beberapa blok logis data untuk volume klaster DB. Untuk informasi selengkapnya tentang grup perlindungan dan simpul penyimpanan, lihat [Memperkenalkan mesin penyimpanan Aurora](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) dalam Blog Basis Data AWS.
Anda dapat menyimulasikan kegagalan seluruh simpul penyimpanan atau satu blok logis data dalam simpul penyimpanan. Untuk melakukannya, Anda menggunakan pernyataan injeksi kegagalan `ALTER SYSTEM SIMULATE DISK FAILURE`. Untuk pernyataan tersebut, Anda menentukan nilai indeks blok logis data atau simpul penyimpanan tertentu. Namun, jika Anda menentukan nilai indeks yang lebih besar dari jumlah blok logis simpul data atau penyimpanan yang digunakan oleh volume klaster DB, pernyataan tersebut akan menampilkan kesalahan. Untuk informasi selengkapnya tentang kueri injeksi kesalahan, lihat [Menguji Amazon Aurora MySQL menggunakan kueri injeksi kesalahan](AuroraMySQL.Managing.FaultInjectionQueries.md).
Anda dapat menghindari kesalahan tersebut dengan menggunakan pernyataan `SHOW VOLUME STATUS`. Pernyataan ini menghasilkan dua variabel status server, `Disks` dan `Nodes`. Variabel ini merepresentasikan jumlah total blok logis simpul data dan penyimpanan, masing-masing, untuk volume klaster DB.
## Sintaksis
```
SHOW VOLUME STATUS
```
## Contoh
Contoh berikut menggambarkan hasil SHOW VOLUME STATUS yang biasa.
```
mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
```