Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Aurora SQL Versi saya 3 kompatibel dengan My 8.0 SQL Anda dapat menggunakan Aurora My SQL versi 3 untuk mendapatkan fitur terbaru yang SQL kompatibel dengan Saya, peningkatan kinerja, dan perbaikan bug. Berikut ini, Anda dapat mempelajari tentang Aurora My SQL versi 3, dengan kompatibilitas My SQL 8.0. Anda dapat mempelajari cara meningkatkan cluster dan aplikasi Anda ke Aurora SQL My versi 3. Beberapa fitur Aurora, seperti Aurora Serverless v2, membutuhkan Aurora SQL Versi saya 3. **Topics** + [Fitur dari My SQL 8.0 Community Edition](#AuroraMySQL.8.0-features-community) + [Aurora Prasyarat SQL versi 3 saya untuk Aurora My Serverless v2 SQL](#AuroraMySQL.serverless-v2-8.0-prereq) + [Catatan rilis untuk Aurora My versi 3 SQL](#AuroraMySQL.mysql80-bugs-fixed) + [Optimisasi kueri paralel baru](#AuroraMySQL.8.0-features-pq) + [Optimisasi untuk mengurangi waktu pengaktifan ulang basis data.](#ReducedRestartTime) + [Perilaku tabel sementara baru di Aurora MySQL versi 3](ams3-temptable-behavior.md) + [Membandingkan Aurora SQL Versi saya 2 dan Aurora Versi saya 3 SQL](AuroraMySQL.Compare-v2-v3.md) + [Membandingkan Aurora MySQL versi 3 dan MySQL 8.0 Community Edition](AuroraMySQL.Compare-80-v3.md) + [Meningkatkan ke Aurora MySQL versi 3](AuroraMySQL.mysql80-upgrade-procedure.md) ## Fitur dari My SQL 8.0 Community Edition Rilis awal Aurora My SQL versi 3 kompatibel dengan My SQL 8.0.23 Community Edition. SQL8.0 saya memperkenalkan beberapa fitur baru, termasuk yang berikut ini: + Dukungan Atomic Data Definition Language (DDL). Untuk informasi selengkapnya, lihat [Dukungan Atomic Data Definition Language (DDL)](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl). + JSONfungsi. Untuk informasi penggunaan, lihat [JSONFungsi](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html) di *Manual SQL Referensi Saya*. + Fungsi Jendela. Untuk informasi penggunaan, lihat [Fungsi Jendela](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html) di *Manual SQL Referensi Saya*. + Ekspresi tabel umum (CTEs), menggunakan `WITH` klausa. Untuk informasi penggunaan, lihat [WITH(Ekspresi Tabel Umum)](https://dev.mysql.com/doc/refman/8.0/en/with.html) di *Manual SQL Referensi Saya*. + Klausa `ADD COLUMN` dan `RENAME COLUMN` yang dioptimalkan untuk pernyataan `ALTER TABLE`. Optimalisasi ini disebut “instanDDL.” Aurora SQL Versi saya 3 kompatibel dengan komunitas Fitur SQL instan DDL saya. DDLFitur cepat Aurora sebelumnya tidak digunakan. Untuk informasi penggunaan instanDDL, lihat[DDL instan (Aurora MySQL versi 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + Indeks menurun, fungsional, dan tidak terlihat. Untuk informasi penggunaan, lihat [Indeks Tak Terlihat, Indeks](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html) [Turun](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html), dan [CREATEINDEXPernyataan](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts) di Manual Referensi *Saya SQL*. + Hak istimewa berbasis peran dikendalikan melalui pernyataan. SQL Untuk informasi selengkapnya tentang perubahan pada model hak akses, lihat [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). + Klausa `NOWAIT` dan `SKIP LOCKED` dengan pernyataan `SELECT ... FOR SHARE`. Klausa ini menghindari tindakan menunggu transaksi lain untuk membuka kunci baris. Untuk informasi penggunaan, lihat [Mengunci Bacaan](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) di *Manual SQL Referensi Saya*. + Peningkatan pada replikasi log biner (binlog). Untuk SQL detail Aurora My, lihat. [Replikasi log biner](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog) Khususnya, Anda dapat melakukan replikasi yang difilter. Untuk informasi penggunaan tentang replikasi yang difilter, lihat [Cara Server Mengevaluasi Aturan Pemfilteran Replikasi di Manual Referensi](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) *Saya SQL*. + Petunjuk. Beberapa petunjuk yang SQL kompatibel dengan My 8.0 sudah di-backport ke Aurora My versi 2. SQL Untuk informasi tentang menggunakan petunjuk dengan Aurora SQL My, lihat. [Aurora Petunjuk saya SQL](AuroraMySQL.Reference.Hints.md) *Untuk daftar lengkap petunjuk di komunitas My SQL 8.0, lihat [Petunjuk Pengoptimal di Manual Referensi](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) Saya. SQL* Untuk daftar lengkap fitur yang ditambahkan ke My SQL 8.0 edisi komunitas, lihat posting blog [Daftar lengkap fitur baru di My SQL 8.0](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/). Aurora SQL Versi saya 3 juga mencakup perubahan kata kunci untuk bahasa inklusif, di-backport dari komunitas My 8.0.26. SQL Untuk detail tentang perubahan tersebut, lihat [Perubahan bahasa inklusif untuk Aurora Versi saya 3 SQL](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language). ## Aurora Prasyarat SQL versi 3 saya untuk Aurora My Serverless v2 SQL Aurora My SQL versi 3 adalah prasyarat untuk semua instans DB di cluster Aurora My Serverless v2. SQL Aurora My SQL Serverless v2 menyertakan dukungan untuk instance pembaca di cluster DB, dan fitur Aurora lainnya yang tidak tersedia untuk Aurora My Serverless v1. SQL Ini juga memiliki penskalaan yang lebih cepat dan lebih granular daripada Aurora My Serverless v1. SQL ## Catatan rilis untuk Aurora My versi 3 SQL Untuk catatan rilis untuk semua rilis Aurora My SQL version 3, lihat [Pembaruan mesin database untuk Amazon Aurora SQL My version](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) 3 di *Catatan Rilis untuk* Aurora My. SQL ## Optimisasi kueri paralel baru Optimasi kueri paralel Aurora sekarang berlaku untuk lebih banyak SQL operasi: + Kueri pararel sekarang berlaku untuk tabel yang berisi jenis data `TEXT`, `BLOB`, `JSON`, `GEOMETRY`, serta `VARCHAR` dan `CHAR` yang lebih panjang dari 768 byte. + Kueri paralel dapat mengoptimalkan kueri yang memerlukan tabel yang dipartisi. + Kueri paralel dapat mengoptimalkan kueri yang memerlukan panggilan fungsi agregat dalam daftar pilih dan klausa `HAVING`. Untuk informasi selengkapnya tentang peningkatan ini, lihat [Memutakhirkan cluster kueri paralel ke Aurora Versi saya 3 SQL](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). Untuk informasi umum tentang kueri paralel Aurora, lihat [Kueri paralel untuk Amazon Aurora My SQL](aurora-mysql-parallel-query.md). ## Optimisasi untuk mengurangi waktu pengaktifan ulang basis data. Cluster Aurora My SQL DB Anda harus sangat tersedia selama pemadaman yang direncanakan dan tidak direncanakan. Administrator basis data perlu melakukan pemeliharaan basis data sesekali. Pemeliharaan ini mencakup patching basis data, tingkatkan, modifikasi parameter basis data yang memerlukan boot ulang manual, pelaksanaan failover untuk mengurangi waktu yang diperlukan dalam mengubah kelas instans, dan sebagainya. Tindakan yang direncanakan ini membutuhkan waktu henti. Namun, waktu henti juga dapat disebabkan oleh tindakan yang tidak direncanakan, seperti failover yang tidak terduga karena kesalahan perangkat keras yang mendasarinya atau throttling sumber daya basis data. Semua tindakan yang direncanakan dan tidak direncanakan ini mengakibatkan pengaktifan ulang basis data. Di Aurora My SQL versi 3.05 dan yang lebih tinggi, kami telah memperkenalkan pengoptimalan yang mengurangi waktu restart database. Optimisasi ini memberikan waktu henti hingga 65% lebih sedikit daripada tanpa optimisasi, dan lebih sedikit gangguan pada beban kerja basis data Anda, setelah pengaktifan ulang. Selama pengaktifan basis data, banyak komponen memori internal yang diinisialisasi. Yang terbesar adalah [kumpulan buffer InnoDB](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/), yang di Aurora My SQL adalah 75% dari ukuran memori instance secara default. Pengujian kami telah menemukan bahwa waktu inisialisasinya sebanding dengan ukuran pool buffer InnoDB, dan oleh karena itu, akan diskalakan dengan ukuran kelas instans DB. Selama tahap inisialisasi ini, basis data tidak dapat menerima koneksi, sehingga memperpanjang waktu henti selama pengaktifan ulang. Fase pertama Aurora My SQL fast restart mengoptimalkan inisialisasi kumpulan buffer, yang mengurangi waktu untuk inisialisasi database dan dengan demikian mengurangi waktu restart secara keseluruhan. Untuk detail selengkapnya, lihat blog [Kurangi waktu henti dengan Amazon Aurora Database SQL saya memulai ulang](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/) pengoptimalan waktu. # Perilaku tabel sementara baru di Aurora MySQL versi 3 Aurora MySQL versi 3 menangani tabel sementara secara berbeda dari Aurora MySQL versi sebelumnya. Perilaku baru ini diwarisi dari MySQL 8.0 Community Edition. Berikut dua jenis tabel sementara yang dapat dibuat dengan Aurora MySQL versi 3: + Tabel sementara internal (atau *implisit*) — Dibuat oleh mesin MySQL Aurora untuk menangani operasi seperti pengurutan agregasi, tabel turunan, atau ekspresi tabel umum (). CTEs + Tabel sementara yang dibuat pengguna (atau *eksplisit*) — Dibuat oleh mesin Aurora MySQL saat Anda menggunakan pernyataan `CREATE TEMPORARY TABLE`. Terdapat pertimbangan tambahan untuk tabel sementara internal dan yang dibuat pengguna pada instans DB pembaca Aurora. Kita akan membahas perubahan ini di bagian berikut. **Topics** + [Mesin penyimpanan untuk tabel sementara internal (implisit)](#ams3-temptable-behavior-engine) + [Membatasi ukuran tabel sementara internal dalam memori](#ams3-temptable-behavior-limit) + [Mengurangi masalah kepenuhan untuk tabel sementara internal di Aurora Replicas](#ams3-temptable-behavior-mitigate) + [Mengoptimalkan parameter temptable\$1max\$1mmap pada instance Aurora MySQL DB](#ams-optimize-temptable_max_mmap) + [Tabel sementara yang dibuat pengguna (eksplisit) pada instans DB pembaca](#ams3-temptable-behavior.user) + [Kesalahan dan mitigasi pembuatan tabel sementara](#ams3-temptable-behavior.errors) ## Mesin penyimpanan untuk tabel sementara internal (implisit) Saat membuat set hasil perantara, Aurora MySQL awalnya mencoba menulis ke tabel sementara dalam memori. Langkah ini mungkin tidak berhasil karena tipe data yang tidak kompatibel atau batas yang dikonfigurasi. Jika demikian, tabel sementara dikonversi ke tabel sementara di disk, bukan disimpan di memori. Informasi selengkapnya tentang hal ini dapat ditemukan di [Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) dalam dokumentasi MySQL. Di Aurora MySQL versi 3, cara kerja tabel sementara internal berbeda dengan Aurora MySQL versi sebelumnya. Alih-alih memilih antara mesin penyimpanan InnoDB dan MyISAM untuk tabel sementara seperti itu, sekarang Anda memilih antara mesin penyimpanan dan mesin penyimpanan. `TempTable` `MEMORY` Dengan mesin penyimpanan `TempTable`, Anda dapat membuat pilihan tambahan untuk cara menangani data tertentu. Data yang terpengaruh memenuhi kumpulan memori yang menampung semua tabel sementara internal untuk instans DB. Pilihan tersebut dapat memengaruhi performa kueri yang menghasilkan volume data sementara yang tinggi, misalnya saat melakukan agregasi seperti `GROUP BY` pada tabel besar. **Tip** Jika beban kerja Anda mencakup kueri yang menghasilkan tabel sementara internal, konfirmasikan performa aplikasi Anda dengan perubahan ini melalui upaya menjalankan tolok ukur dan memantau metrik terkait performa. Dalam kasus tertentu, jumlah data sementara sesuai dengan kumpulan memori `TempTable` atau hanya memenuhi kumpulan memori dalam jumlah kecil. Jika demikian, sebaiknya gunakan pengaturan `TempTable` untuk tabel sementara internal dan file yang dipetakan memori untuk menyimpan data overflow apa pun. Ini adalah pengaturan default. Mesin penyimpanan `TempTable` adalah pengaturan default. `TempTable` menggunakan kumpulan memori umum untuk semua tabel sementara yang menggunakan mesin ini, bukan batas memori maksimum per tabel. Ukuran kumpulan memori ini ditentukan oleh parameter [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). Nilai default adalah 1 GiB pada instans DB dengan memori 16 GiB atau lebih, dan 16 MB pada instans DB dengan memori kurang dari 16 GiB. Ukuran kumpulan memori memengaruhi konsumsi memori tingkat sesi. Dalam kasus tertentu, bila Anda menggunakan mesin penyimpanan `TempTable`, data sementara mungkin melebihi ukuran kumpulan memori. Jika demikian, Aurora MySQL akan menyimpan data overflow tersebut menggunakan mekanisme sekunder. Anda dapat mengatur parameter [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) untuk memilih apakah data akan memenuhi file sementara yang dipetakan memori atau tabel sementara internal InnoDB di disk. Format data yang berbeda dan kriteria overflow dari mekanisme overflow ini dapat memengaruhi performa kueri. Hal ini dilakukan dengan memengaruhi jumlah data yang ditulis ke disk dan permintaan atas throughput penyimpanan disk. Aurora MySQL versi 3 menyimpan data overflow dengan cara berikut: + Pada instance DB penulis, data yang meluap ke tabel sementara internal InnoDB atau file sementara yang dipetakan memori berada di penyimpanan lokal pada instance. + Pada instans DB pembaca, data overflow selalu berada dalam file sementara yang dipetakan memori di penyimpanan lokal. Instans hanya-baca tidak dapat menyimpan data apa pun pada volume cluster Aurora. Parameter konfigurasi terkait tabel sementara internal berlaku untuk instans penulis dan pembaca dengan cara yang berbeda di klaster Anda: + Pada instans pembaca, Aurora MySQL selalu menggunakan mesin penyimpanan `TempTable`. + Ukuran default `temptable_max_mmap` adalah 1 GiB untuk instans penulis dan pembaca, berapa pun ukuran memori instans DB-nya. Anda dapat menyesuaikan nilai ini pada instans penulis dan pembaca. + Mengatur `temptable_max_mmap` ke `0` akan menonaktifkan penggunaan file sementara yang dipetakan memori pada instans penulis. + Anda tidak dapat mengatur `temptable_max_mmap` ke `0` pada instans pembaca. **catatan** Kami tidak menyarankan penggunaan parameter [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). Parameter tersebut telah dihentikan, dan dukungannya direncanakan akan dihapus dalam rilis MySQL mendatang. ## Membatasi ukuran tabel sementara internal dalam memori Sebagaimana dibahas dalam [Mesin penyimpanan untuk tabel sementara internal (implisit)](#ams3-temptable-behavior-engine), Anda dapat mengontrol sumber daya tabel sementara secara global dengan menggunakan pengaturan [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) dan [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap). Anda juga dapat membatasi ukuran setiap tabel sementara internal dalam memori menggunakan parameter DB [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Batas ini dimaksudkan untuk mencegah setiap kueri mengonsumsi sumber daya tabel sementara global dalam jumlah besar, yang dapat memengaruhi performa kueri bersamaan yang memerlukan sumber daya ini. Parameter `tmp_table_size` menetapkan ukuran maksimum tabel sementara yang dibuat oleh mesin penyimpanan `MEMORY` di Aurora MySQL versi 3. Di Aurora MySQL versi 3.04 dan yang lebih tinggi, `tmp_table_size` juga menetapkan ukuran maksimum tabel sementara yang dibuat oleh mesin penyimpanan `TempTable` saat parameter DB `aurora_tmptable_enable_per_table_limit` diatur ke `ON`. Perilaku ini dinonaktifkan secara default (`OFF`), yang merupakan perilaku serupa seperti di Aurora MySQL versi 3.03 dan yang lebih rendah. + Bila `aurora_tmptable_enable_per_table_limit` diatur ke `OFF`, `tmp_table_size` tidak dipertimbangkan untuk tabel sementara internal dalam memori yang dibuat oleh mesin penyimpanan `TempTable`. Namun, batas sumber daya `TempTable` global masih berlaku. Bila batas sumber daya `TempTable` global tercapai, Aurora MySQL memiliki perilaku berikut: + Instans DB penulis – Aurora MySQL secara otomatis mengonversi tabel sementara dalam memori menjadi tabel sementara di disk InnoDB. + Instans DB pembaca – Kueri berakhir dengan kesalahan. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` + Bila `aurora_tmptable_enable_per_table_limit` diatur ke `ON`, Aurora MySQL memiliki perilaku berikut saat batas `tmp_table_size` tercapai: + Instans DB penulis – Aurora MySQL secara otomatis mengonversi tabel sementara dalam memori menjadi tabel sementara di disk InnoDB. + Instans DB pembaca – Kueri berakhir dengan kesalahan. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` Dalam kasus ini, batas sumber daya `TempTable` global dan batas per tabel berlaku. **catatan** Parameter `aurora_tmptable_enable_per_table_limit` tidak berpengaruh saat [ internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) diatur ke `MEMORY`. Dalam hal ini, ukuran maksimum tabel sementara dalam memori ditentukan oleh nilai [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) atau [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size), mana pun yang lebih kecil. Contoh berikut menunjukkan perilaku parameter `aurora_tmptable_enable_per_table_limit` untuk instans DB penulis dan pembaca. **Example instans DB penulis dengan `aurora_tmptable_enable_per_table_limit` diatur ke `OFF`** Tabel sementara dalam memori tidak dikonversi ke tabel sementara di disk InnoDB. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 0 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (13.99 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example instans DB penulis dengan `aurora_tmptable_enable_per_table_limit` diatur ke `ON`** Tabel sementara dalam memori dikonversi ke tabel sementara di disk InnoDB. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 0 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; +---------+ | max(n) | +---------+ | 6000000 | +---------+ 1 row in set (4.10 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example instans DB pembaca dengan `aurora_tmptable_enable_per_table_limit` diatur ke `OFF`** Kueri selesai tanpa kesalahan karena `tmp_table_size` tidak berlaku dan batas sumber daya `TempTable` global belum tercapai. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (14.05 sec) ``` **Example instans DB pembaca dengan `aurora_tmptable_enable_per_table_limit` diatur ke `OFF`** Kueri ini mencapai batas TempTable sumber daya global dengan `aurora_tmptable_enable_per_table_limit` disetel ke OFF. Kueri berakhir dengan kesalahan pada instans pembaca. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.01 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full ``` **Example instans DB pembaca dengan `aurora_tmptable_enable_per_table_limit` diatur ke `ON`** Kueri berakhir dengan kesalahan saat batas `tmp_table_size` tercapai. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 1 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full ``` ## Mengurangi masalah kepenuhan untuk tabel sementara internal di Aurora Replicas Untuk mencegah masalah pembatasan ukuran pada tabel sementara, atur parameter `temptable_max_ram` dan `temptable_max_mmap` ke nilai gabungan yang dapat memenuhi persyaratan beban kerja Anda. Berhati-hatilah saat mengatur nilai parameter `temptable_max_ram`. Mengatur nilai terlalu tinggi mengurangi memori yang tersedia pada instance database, yang dapat menyebabkan suatu out-of-memory kondisi. Pantau memori rata-rata yang dapat dikosongkan pada instans DB. Lalu, tentukan nilai yang sesuai untuk `temptable_max_ram`, sehingga Anda akan tetap memiliki memori bebas dalam jumlah wajar yang tersisa pada instans. Untuk informasi selengkapnya, lihat [Masalah memori yang dapat dikosongkan di Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). Penting juga bagi Anda untuk memantau ukuran penyimpanan lokal dan konsumsi ruang tabel sementara. Anda dapat memantau penyimpanan sementara yang tersedia untuk instans DB tertentu dengan CloudWatch metrik `FreeLocalStorage` Amazon, yang dijelaskan dalam[CloudWatch Metrik Amazon untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). **catatan** Prosedur ini tidak berfungsi bila parameter `aurora_tmptable_enable_per_table_limit` diatur ke `ON`. Untuk informasi selengkapnya, lihat [Membatasi ukuran tabel sementara internal dalam memori](#ams3-temptable-behavior-limit). **Example 1** Anda tahu bahwa tabel sementara Anda berkembang menjadi berukuran kumulatif 20 GiB. Anda ingin mengatur tabel sementara dalam memori ke 2 GiB dan mengembangkannya menjadi maksimum 20 GiB pada disk. Atur `temptable_max_ram` ke **2,147,483,648** dan `temptable_max_mmap` ke **21,474,836,480**. Nilai ini dihitung dalam byte. Pengaturan parameter ini memastikan bahwa tabel sementara Anda dapat berkembang menjadi total kumulatif 22 GiB. **Example 2** Ukuran instans Anda saat ini adalah 16xlarge atau lebih besar. Anda tidak mengetahui ukuran total tabel sementara yang mungkin Anda perlukan. Anda ingin dapat menggunakan hingga 4 GiB dalam memori dan hingga ukuran penyimpanan maksimum yang tersedia pada disk. Atur `temptable_max_ram` ke **4,294,967,296** dan `temptable_max_mmap` ke **1,099,511,627,776**. Nilai ini dihitung dalam byte. Di sini, Anda mengatur `temptable_max_mmap` ke 1 TiB, yang lebih kecil dari penyimpanan lokal maksimum sebesar 1,2 TiB pada instans DB Aurora 16xlarge. Pada ukuran instans yang lebih kecil, sesuaikan nilai `temptable_max_mmap` agar tidak mengisi penyimpanan lokal yang tersedia. Misalnya, instans 2xlarge hanya memiliki penyimpanan lokal yang tersedia sebesar 160 GiB. Karena itu, sebaiknya atur nilainya menjadi kurang dari 160 GiB. Untuk informasi selengkapnya tentang penyimpanan lokal yang tersedia untuk ukuran instans DB, lihat [Batas penyimpanan sementara untuk Aurora MySQLBatas penyimpanan sementara](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Mengoptimalkan parameter temptable\$1max\$1mmap pada instance Aurora MySQL DB `temptable_max_mmap`Parameter di Aurora MySQL mengontrol jumlah maksimum ruang disk lokal yang dapat digunakan oleh file yang dipetakan memori sebelum meluap ke tabel sementara InnoDB on-disk (pada instance DB penulis) atau menyebabkan kesalahan (pada instance DB pembaca). Menyetel parameter instans DB ini dengan benar dapat membantu mengoptimalkan kinerja instans DB Anda. **Prasyarat** 1. Pastikan bahwa Skema Kinerja diaktifkan. Anda dapat memverifikasi ini dengan menjalankan perintah SQL berikut: ``` SELECT @@performance_schema; ``` Nilai output `1` menunjukkan bahwa itu diaktifkan. 1. Konfirmasikan bahwa instrumentasi memori tabel sementara diaktifkan. Anda dapat memverifikasi ini dengan menjalankan perintah SQL berikut: ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` `enabled`Kolom menunjukkan `YES` entri instrumentasi memori tabel sementara yang relevan. **Memantau penggunaan tabel sementara** Saat menyetel nilai awal`temptable_max_mmap`, kami sarankan Anda memulai dengan 80% ukuran penyimpanan lokal untuk kelas instans DB yang Anda gunakan. Ini memastikan bahwa tabel sementara memiliki ruang disk yang cukup untuk beroperasi secara efisien, sambil menyisakan ruang untuk penggunaan disk lain pada instance. Untuk menemukan ukuran penyimpanan lokal untuk kelas instans DB Anda, lihat[Batas penyimpanan sementara untuk Aurora MySQLBatas penyimpanan sementara](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Misalnya, jika Anda menggunakan kelas instans db.r5.large DB, ukuran penyimpanan lokal adalah 32 GiB. Dalam hal ini, Anda awalnya akan mengatur `temptable_max_mmap` parameter ke 80% dari 32 GiB, yaitu 25,6 GiB. Setelah mengatur `temptable_max_mmap` nilai awal, jalankan beban kerja puncak Anda pada instance Aurora MySQL. Pantau penggunaan disk tabel sementara saat ini dan tinggi menggunakan kueri SQL berikut: ``` SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%'; ``` Kueri ini mengambil informasi berikut: + `event_name`— Nama memori tabel sementara atau acara penggunaan disk. + `current_count`— Jumlah memori tabel sementara atau blok disk yang dialokasikan saat ini. + `current_alloc`— Jumlah memori atau disk saat ini yang dialokasikan untuk tabel sementara. + `current_avg_alloc`— Ukuran rata-rata saat ini dari memori tabel sementara atau blok disk. + `high_count`— Jumlah tertinggi memori tabel sementara atau blok disk yang dialokasikan. + `high_alloc`— Jumlah memori atau disk tertinggi yang dialokasikan untuk tabel sementara. + `high_avg_alloc`— Ukuran rata-rata tertinggi memori tabel sementara atau blok disk. Jika kueri Anda gagal dengan kesalahan penuh Tabel menggunakan pengaturan ini, ini menunjukkan bahwa beban kerja Anda memerlukan lebih banyak ruang disk untuk operasi tabel sementara. Dalam hal ini, pertimbangkan untuk meningkatkan ukuran instans DB Anda menjadi satu dengan lebih banyak ruang penyimpanan lokal. **Mengatur `temptable_max_mmap` nilai optimal** Gunakan prosedur berikut untuk memantau dan mengatur ukuran yang tepat untuk `temptable_max_mmap` parameter. 1. Tinjau output dari kueri sebelumnya, dan identifikasi penggunaan disk tabel sementara puncak, seperti yang ditunjukkan oleh `high_alloc` kolom. 1. Berdasarkan penggunaan disk tabel sementara puncak, sesuaikan `temptable_max_mmap` parameter dalam grup parameter DB untuk instance Aurora MySQL DB Anda. Tetapkan nilainya menjadi sedikit lebih tinggi dari penggunaan disk tabel sementara puncak untuk mengakomodasi pertumbuhan masa depan. 1. Terapkan perubahan grup parameter ke instans DB Anda. 1. Pantau penggunaan disk tabel sementara lagi selama beban kerja puncak Anda untuk memastikan bahwa `temptable_max_mmap` nilai baru sesuai. 1. Ulangi langkah sebelumnya sesuai kebutuhan untuk menyempurnakan `temptable_max_mmap` parameter. ## Tabel sementara yang dibuat pengguna (eksplisit) pada instans DB pembaca Anda dapat membuat tabel sementara eksplisit menggunakan kata kunci `TEMPORARY` dalam pernyataan `CREATE TABLE`. Tabel sementara eksplisit didukung pada instans DB penulis di klaster DB Aurora. Anda juga dapat menggunakan tabel sementara eksplisit pada instans DB pembaca, tetapi tabel tidak dapat menerapkan penggunaan mesin penyimpanan InnoDB. Untuk mencegah timbulnya kesalahan saat membuat tabel sementara eksplisit pada instans DB pembaca Aurora MySQL, pastikan Anda menjalankan semua pernyataan `CREATE TEMPORARY TABLE` dengan salah satu atau kedua cara berikut: + Jangan tentukan klausa `ENGINE=InnoDB`. + Jangan atur mode SQL ke `NO_ENGINE_SUBSTITUTION`. ## Kesalahan dan mitigasi pembuatan tabel sementara Kesalahan yang Anda terima berbeda tergantung pada apakah Anda menggunakan pernyataan `CREATE TEMPORARY TABLE` biasa atau variasi `CREATE TEMPORARY TABLE AS SELECT`. Contoh berikut menunjukkan berbagai jenis kesalahan. Perilaku tabel sementara ini hanya berlaku untuk instans hanya-baca. Contoh pertama ini mengonfirmasi jenis instans yang terhubung dengan sesi. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` Untuk pernyataan `CREATE TEMPORARY TABLE` biasa, pernyataan akan gagal saat mode SQL `NO_ENGINE_SUBSTITUTION` diaktifkan. Ketika `NO_ENGINE_SUBSTITUTION` dinonaktifkan (default), substitusi mesin yang sesuai dibuat, dan pembuatan tabel sementara berhasil. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` Untuk pernyataan `CREATE TEMPORARY TABLE AS SELECT`, pernyataan akan gagal saat mode SQL `NO_ENGINE_SUBSTITUTION` diaktifkan. Ketika `NO_ENGINE_SUBSTITUTION` dinonaktifkan (default), substitusi mesin yang sesuai dibuat, dan pembuatan tabel sementara berhasil. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> show create table tt3; +-------+----------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------+ | tt3 | CREATE TEMPORARY TABLE `tt3` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +-------+----------------------------------------------------------+ 1 row in set (0.00 sec) ``` Untuk informasi selengkapnya tentang aspek penyimpanan dan implikasi kinerja tabel sementara di Aurora MySQL versi 3, lihat [posting blog TempTable Gunakan mesin penyimpanan di Amazon RDS for MySQL dan Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/). # Membandingkan Aurora SQL Versi saya 2 dan Aurora Versi saya 3 SQL Gunakan yang berikut ini untuk mempelajari tentang perubahan yang harus diperhatikan saat Anda memutakhirkan klaster Aurora My SQL version 2 Anda ke versi 3. **Topics** + [Dukungan Atomic Data Definition Language (DDL)](#AuroraMySQL.Compare-v2-v3-atomic-ddl) + [Perbedaan fitur antara Aurora My SQL versi 2 dan 3](#AuroraMySQL.Compare-v2-v3-features) + [Dukungan kelas instans](#AuroraMySQL.mysql80-instance-classes) + [Perubahan parameter untuk Aurora Versi saya 3 SQL](#AuroraMySQL.mysql80-parameter-changes) + [Variabel status](#AuroraMySQL.mysql80-status-vars) + [Perubahan bahasa inklusif untuk Aurora Versi saya 3 SQL](#AuroraMySQL.8.0-inclusive-language) + [AUTO\$1 INCREMENT nilai](#AuroraMySQL.mysql80-autoincrement) + [Replikasi log biner](#AuroraMySQL.mysql80-binlog) ## Dukungan Atomic Data Definition Language (DDL) Salah satu perubahan terbesar dari My SQL 5.7 ke 8.0 adalah pengenalan [Atomic Data](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) Dictionary. Sebelum My SQL 8.0, kamus SQL data Saya menggunakan pendekatan berbasis file untuk menyimpan metadata seperti definisi tabel (.frm), pemicu (.trg), dan berfungsi secara terpisah dari metadata mesin penyimpanan (seperti InnoDB's). Ini memiliki beberapa masalah, termasuk risiko tabel menjadi "[yatim piatu](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html)" jika sesuatu yang tidak terduga terjadi selama DDL operasi, menyebabkan metadata berbasis file dan mesin penyimpanan tidak sinkron. Untuk memperbaikinya, My SQL 8.0 memperkenalkan Atomic Data Dictionary, yang menyimpan semua metadata dalam satu set tabel InnoDB internal dalam skema. `mysql` Arsitektur baru ini menyediakan cara transaksional [ACID](https://en.wikipedia.org/wiki/ACID)yang sesuai untuk mengelola metadata database, memecahkan masalah “atomDDL” dari pendekatan berbasis file lama. *Untuk informasi selengkapnya tentang Kamus Data Atom, lihat [Penghapusan penyimpanan metadata berbasis file](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) dan [dukungan pernyataan definisi data atom](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) di Manual Referensi Saya. SQL* Karena perubahan arsitektur ini, Anda harus mempertimbangkan hal berikut saat memutakhirkan dari Aurora SQL My versi 2 ke versi 3: + Metadata berbasis file dari versi 2 harus dimigrasikan ke tabel kamus data baru selama proses upgrade ke versi 3. Bergantung pada berapa banyak objek database yang dimigrasikan, ini bisa memakan waktu. + Perubahan juga telah memperkenalkan beberapa ketidakcocokan baru yang mungkin perlu ditangani sebelum Anda dapat meningkatkan dari My SQL 5.7 ke 8.0. Misalnya, 8.0 memiliki beberapa kata kunci cadangan baru yang dapat bertentangan dengan nama objek database yang ada. Untuk membantu Anda mengidentifikasi ketidakcocokan ini sebelum memutakhirkan mesin, Aurora My SQL menjalankan serangkaian pemeriksaan kompatibilitas pemutakhiran (prechecks) untuk menentukan apakah ada objek yang tidak kompatibel dalam kamus database Anda, sebelum melakukan pemutakhiran kamus data. Untuk informasi lebih lanjut tentang prechecks, lihat[Pra-pemeriksaan peningkatan versi mayor untuk Aurora MySQL](AuroraMySQL.upgrade-prechecks.md). ## Perbedaan fitur antara Aurora My SQL versi 2 dan 3 SQLFitur Amazon Aurora My berikut didukung di Aurora My SQL for My SQL 5.7, tetapi fitur ini tidak didukung di Aurora My untuk My 8.0: SQL SQL + Anda tidak dapat menggunakan Aurora My SQL versi 3 untuk Aurora Serverless kluster v1. Aurora SQL Versi saya 3 berfungsi dengan Aurora Serverless v2. + Mode lab tidak berlaku untuk Aurora My SQL versi 3. Tidak ada fitur mode lab di Aurora My SQL versi 3. Instan DDL menggantikan DDL fitur online cepat yang sebelumnya tersedia dalam mode lab. Sebagai contoh, lihat [DDL instan (Aurora MySQL versi 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + Cache kueri dihapus dari komunitas My SQL 8.0 dan juga dari Aurora SQL My versi 3. + Aurora SQL Versi saya 3 kompatibel dengan komunitas Fitur bergabung dengan SQL hash saya. Implementasi khusus Aurora dari gabungan hash di Aurora My version 2 tidak digunakan. SQL Untuk informasi tentang menggunakan hash join dengan kueri paralel Aurora, lihat [Mengaktifkan hash join untuk klaster kueri paralel](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) dan [Aurora Petunjuk saya SQL](AuroraMySQL.Reference.Hints.md). Untuk informasi penggunaan umum tentang gabungan hash, lihat [Pengoptimalan Gabung Hash](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html) di Manual Referensi *Saya SQL*. + Prosedur `mysql.lambda_async` tersimpan yang tidak digunakan lagi di Aurora My SQL version 2 dihapus di versi 3. Untuk versi 3, gunakan fungsi asinkron `lambda_async` sebagai gantinya. + Karakter default yang ditetapkan di Aurora My SQL versi 3 adalah. `utf8mb4` Di Aurora My SQL versi 2, set karakter default adalah. `latin1` *Untuk informasi tentang set karakter ini, lihat Set Karakter [utf8mb4 (4-Byte UTF -8 Unicode Encoding](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)) di Manual Referensi Saya. SQL* Beberapa SQL fitur Aurora My tersedia untuk kombinasi tertentu dari versi mesin AWS Region dan DB. Untuk detailnya, lihat [Fitur yang didukung di Amazon Aurora oleh dan mesin Wilayah AWS Aurora DB](Concepts.AuroraFeaturesRegionsDBEngines.grids.md). ## Dukungan kelas instans Aurora SQL Versi saya 3 mendukung serangkaian kelas instance yang berbeda dari Aurora My versi 2: SQL + Untuk instans yang lebih besar, Anda dapat menggunakan kelas instans modern seperti `db.r5`, `db.r6g`, dan `db.x2g`. + Untuk instans yang lebih kecil, Anda dapat menggunakan kelas instans modern seperti `db.t3` dan `db.t4g`. **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). Kelas instance berikut dari Aurora My SQL version 2 tidak tersedia untuk Aurora My versi 3: SQL + `db.r4` + `db.r3` + `db.t3.small` + `db.t2` Periksa skrip administrasi Anda untuk setiap CLI pernyataan yang membuat instance Aurora SQL My DB. Nama kelas instance hardcode yang tidak tersedia untuk Aurora SQL My versi 3. Jika perlu, ubah nama kelas instance menjadi nama yang didukung Aurora My SQL version 3. **Tip** Untuk memeriksa kelas instance yang dapat Anda gunakan untuk kombinasi spesifik Aurora SQL versi dan AWS Wilayah Saya, gunakan perintah. `describe-orderable-db-instance-options` AWS CLI Untuk detail selengkapnya tentang kelas instans Aurora, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md). ## Perubahan parameter untuk Aurora Versi saya 3 SQL Aurora My SQL version 3 mencakup parameter konfigurasi level cluster dan instance-level baru. Aurora SQL Versi saya 3 juga menghapus beberapa parameter yang ada di Aurora My versi 2. SQL Beberapa nama parameter diubah sebagai hasil dari inisiatif untuk bahasa inklusif. Untuk kompatibilitas mundur, Anda masih dapat mengambil nilai parameter menggunakan nama lama atau nama baru. Namun, Anda harus menggunakan nama baru untuk menentukan nilai parameter dalam grup parameter kustom. Di Aurora My SQL versi 3, nilai `lower_case_table_names` parameter diatur secara permanen pada saat cluster dibuat. Jika Anda menggunakan nilai nondefault untuk opsi ini, siapkan grup parameter kustom Aurora SQL My version 3 Anda sebelum memutakhirkan. Kemudian, tentukan grup parameter selama operasi pembuatan klaster atau pemulihan snapshot. **catatan** Dengan database global Aurora berdasarkan Aurora MySQL, Anda tidak dapat melakukan peningkatan di tempat dari Aurora SQL My versi 2 ke versi 3 jika parameter dihidupkan. `lower_case_table_names` Gunakan metode pemulihan snapshot sebagai gantinya. Di Aurora My SQL versi 3, `read_only` parameter `init_connect` dan tidak berlaku untuk pengguna yang memiliki hak istimewa. `CONNECTION_ADMIN` Ini termasuk pengguna master Aurora. Untuk informasi selengkapnya, lihat [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). Untuk daftar lengkap parameter Aurora My SQL cluster, lihat. [Parameter tingkat klaster](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster) Tabel ini mencakup semua parameter dari Aurora My SQL versi 2 dan 3. Tabel mencakup catatan yang menunjukkan parameter mana yang baru di Aurora My SQL versi 3 atau telah dihapus dari Aurora My versi 3. SQL Untuk daftar lengkap parameter Aurora My SQL instance, lihat. [Parameter tingkat instans](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance) Tabel ini mencakup semua parameter dari Aurora My SQL versi 2 dan 3. Tabel mencakup catatan yang menunjukkan parameter mana yang baru di Aurora My SQL versi 3 dan parameter mana yang dihapus dari Aurora My versi 3. SQL Ini juga mencakup catatan yang menunjukkan parameter mana yang dapat dimodifikasi di versi sebelumnya tetapi tidak Aurora My versi 3. SQL Untuk informasi tentang nama parameter yang berubah, lihat [Perubahan bahasa inklusif untuk Aurora Versi saya 3 SQL](#AuroraMySQL.8.0-inclusive-language). ## Variabel status Untuk informasi tentang variabel status yang tidak berlaku untuk Aurora MySQL, lihat. [Variabel status MySQL yang tidak berlaku untuk Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable) ## Perubahan bahasa inklusif untuk Aurora Versi saya 3 SQL Aurora My SQL version 3 kompatibel dengan versi 8.0.23 dari edisi My community. SQL Aurora SQL Versi saya 3 juga mencakup perubahan dari My SQL 8.0.26 terkait dengan kata kunci dan skema sistem untuk bahasa inklusif. Misalnya, perintah `SHOW REPLICA STATUS` sekarang lebih disarankan daripada `SHOW SLAVE STATUS`. CloudWatch Metrik Amazon berikut memiliki nama baru di Aurora SQL My versi 3. Di Aurora My SQL versi 3, hanya nama metrik baru yang tersedia. Pastikan untuk memperbarui alarm atau otomatisasi lain yang bergantung pada nama metrik saat Anda meningkatkan ke Aurora My versi 3. SQL | Nama lama | Nama baru | | --- | --- | | ForwardingMasterDMLLatency | ForwardingWriterDMLLatency | | ForwardingMasterOpenSessions | ForwardingWriterOpenSessions | | AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull | | ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput | Variabel status berikut memiliki nama baru di Aurora My SQL versi 3. Untuk kompatibilitas, Anda dapat menggunakan salah satu nama dalam rilis awal Aurora My SQL versi 3. Nama variabel status lama akan dihapus dalam rilis mendatang. | Nama yang akan dihapus | Nama yang baru atau direkomendasikan | | --- | --- | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | | Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | | Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout | | Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions | | Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit | | Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout | Parameter konfigurasi berikut memiliki nama baru di Aurora My SQL versi 3. Untuk kompatibilitas, Anda dapat memeriksa nilai parameter di `mysql` klien dengan menggunakan salah satu nama dalam rilis Aurora My SQL versi 3 awal. Anda hanya dapat menggunakan nama baru saat memodifikasi nilai dalam grup parameter kustom. Nama parameter lama akan dihapus dalam rilis mendatang. | Nama yang akan dihapus | Nama yang baru atau direkomendasikan | | --- | --- | | aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout | | aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct | | master\$1verify\$1checksum | source\$1verify\$1checksum | | sync\$1master\$1info | sync\$1source\$1info | | init\$1slave | init\$1replica | | rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout | | log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements | | slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet | | slave\$1compressed\$1protocol | replica\$1compressed\$1protocol | | slave\$1exec\$1mode | replica\$1exec\$1mode | | slave\$1type\$1conversions | replica\$1type\$1conversions | | slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum | | slave\$1parallel\$1type | replica\$1parallel\$1type | | slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order | | log\$1slave\$1updates | log\$1replica\$1updates | | slave\$1allow\$1batching | replica\$1allow\$1batching | | slave\$1load\$1tmpdir | replica\$1load\$1tmpdir | | slave\$1net\$1timeout | replica\$1net\$1timeout | | sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter | | slave\$1skip\$1errors | replica\$1skip\$1errors | | slave\$1checkpoint\$1period | replica\$1checkpoint\$1period | | slave\$1checkpoint\$1group | replica\$1checkpoint\$1group | | slave\$1transaction\$1retries | replica\$1transaction\$1retries | | slave\$1parallel\$1workers | replica\$1parallel\$1workers | | slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max | | pseudo\$1slave\$1mode | pseudo\$1replica\$1mode | Prosedur tersimpan berikut memiliki nama baru di Aurora My SQL versi 3. Untuk kompatibilitas, Anda dapat menggunakan salah satu nama dalam rilis awal Aurora My SQL versi 3. Nama prosedur lama akan dihapus dalam rilis mendatang. | Nama yang akan dihapus | Nama yang baru atau direkomendasikan | | --- | --- | | mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position | | mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source | | mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position | | mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source | | mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log | ## AUTO\$1 INCREMENT nilai Di Aurora My SQL versi 3, Aurora mempertahankan `AUTO_INCREMENT` nilai untuk setiap tabel saat me-restart setiap instans DB. Di Aurora My SQL versi 2, `AUTO_INCREMENT` nilainya tidak dipertahankan setelah restart. `AUTO_INCREMENT`Nilai tidak dipertahankan saat Anda menyiapkan klaster baru dengan memulihkan dari snapshot, melakukan point-in-time pemulihan, dan mengkloning cluster. Dalam kasus ini, nilai `AUTO_INCREMENT` diinisialisasi ke nilai berdasarkan nilai kolom terbesar dalam tabel pada saat snapshot dibuat. Perilaku ini berbeda dari pada RDS My SQL 8.0, di mana `AUTO_INCREMENT` nilainya dipertahankan selama operasi ini. ## Replikasi log biner Dalam edisi komunitas My SQL 8.0, replikasi log biner diaktifkan secara default. Di Aurora My SQL versi 3, replikasi log biner dimatikan secara default. **Tip** Jika persyaratan ketersediaan tinggi Anda dipenuhi oleh fitur replikasi default Aurora, Anda dapat menonaktifkan replikasi log biner. Dengan begitu, Anda dapat menghindari overhead performa replikasi log biner. Anda juga dapat menghindari pemantauan dan pemecahan masalah terkait yang diperlukan untuk mengelola replikasi log biner. Aurora mendukung replikasi log biner dari sumber My SQL 5.7 yang kompatibel dengan Aurora My versi 3. SQL Sistem sumber dapat berupa cluster Aurora My SQL DB, instans RDS for My SQL DB, atau instans Saya lokal. SQL Seperti halnya komunitas MySQL, Aurora My SQL mendukung replikasi dari sumber yang menjalankan versi tertentu ke target yang menjalankan versi utama yang sama atau satu versi utama yang lebih tinggi. Misalnya, replikasi dari SQL sistem My 5.6 yang kompatibel ke Aurora My SQL versi 3 tidak didukung. Mereplikasi dari Aurora SQL My versi 3 ke sistem My 5.7—kompatibel atau SQL SQL My 5.6—kompatibel tidak didukung. Untuk detail tentang menggunakan replikasi log biner, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). Aurora SQL Versi saya 3 mencakup peningkatan replikasi log biner di komunitas My SQL 8.0, seperti replikasi yang difilter. Untuk detail tentang peningkatan komunitas My SQL 8.0, lihat [Bagaimana Server Mengevaluasi Aturan Pemfilteran Replikasi](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) di Manual Referensi *Saya SQL*. ### Kompresi transaksi untuk replikasi log biner Untuk informasi penggunaan tentang kompresi log biner, lihat [Kompresi Transaksi Log Biner](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html) di Manual SQL Referensi Saya. Batasan berikut berlaku untuk kompresi log biner di Aurora My SQL versi 3: + Transaksi yang data log binernya lebih besar dari ukuran paket maksimum yang diizinkan tidak akan dikompresi. Ini benar terlepas dari apakah pengaturan kompresi log SQL biner Aurora My diaktifkan. Transaksi semacam itu direplikasi tanpa dikompresi. + Jika Anda menggunakan konektor untuk change data capture (CDC) yang belum mendukung My SQL 8.0, Anda tidak dapat menggunakan fitur ini. Kami menyarankan Anda menguji konektor pihak ketiga secara menyeluruh dengan kompresi log biner. Selain itu, kami menyarankan Anda melakukannya sebelum mengaktifkan kompresi binlog pada sistem yang menggunakan replikasi binlog untuk. CDC # Membandingkan Aurora MySQL versi 3 dan MySQL 8.0 Community Edition Anda dapat menggunakan informasi berikut untuk mempelajari tentang perubahan yang harus diperhatikan ketika Anda mengonversi dari sistem yang kompatibel dengan MySQL 8.0 yang berbeda ke Aurora MySQL versi 3. Secara umum, Aurora MySQL versi 3 mendukung set fitur MySQL 8.0.23 komunitas. Beberapa fitur baru dari MySQL 8.0 edisi komunitas tidak berlaku untuk Aurora MySQL. Beberapa fitur tersebut tidak kompatibel dengan beberapa aspek Aurora, seperti arsitektur penyimpanan Aurora. Fitur lain tidak diperlukan karena layanan manajemen Amazon RDS menyediakan fungsionalitas yang setara. Fitur berikut di MySQL 8.0 komunitas tidak didukung atau berfungsi secara berbeda di Aurora MySQL versi 3. Untuk catatan rilis untuk semua rilis Aurora MySQL versi 3, lihat [Pembaruan mesin basis data untuk Amazon Aurora MySQL versi 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) dalam *Catatan Rilis untuk Aurora MySQL*. **Topics** + [Fitur MySQL 8.0 tidak tersedia di Aurora MySQL versi 3](#AuroraMySQL.Compare-80-v3-features) + [Model hak akses berbasis peran](#AuroraMySQL.privilege-model) + [Menemukan ID server database](#AuroraMySQL.server-id) + [Autentikasi](#AuroraMySQL.mysql80-authentication) ## Fitur MySQL 8.0 tidak tersedia di Aurora MySQL versi 3 Fitur berikut dari MySQL 8.0 komunitas tidak tersedia atau berfungsi secara berbeda di Aurora MySQL versi 3. + Grup sumber daya dan pernyataan SQL terkait tidak didukung di Aurora MySQL. + Aurora MySQL tidak mendukung ruang tabel undo yang ditentukan pengguna dan pernyataan SQL terkait, seperti, dan. `CREATE UNDO TABLESPACE` `ALTER UNDO TABLESPACE ... SET INACTIVE` `DROP UNDO TABLESPACE` + Aurora MySQL tidak mendukung pemotongan undo tablespace untuk versi Aurora MySQL yang lebih rendah dari 3.06. [Di Aurora MySQL versi 3.06 dan yang lebih tinggi, pemotongan tablespace undo otomatis didukung.](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace) + Plugin validasi kata sandi didukung. + Anda tidak dapat mengubah pengaturan plugin MySQL apa pun, termasuk plugin validasi kata sandi. + Plugin X tidak didukung. + Replikasi multisumber tidak didukung. ## Model hak akses berbasis peran Dengan Aurora MySQL versi 3, Anda tidak dapat memodifikasi tabel dalam basis data `mysql` secara langsung. Secara khusus, Anda tidak dapat mengatur pengguna dengan melakukan penyisipan ke dalam tabel `mysql.user`. Sebagai gantinya, Anda menggunakan pernyataan SQL untuk memberikan hak akses berbasis peran. Anda juga tidak dapat membuat jenis objek lain seperti prosedur tersimpan dalam basis data `mysql`. Anda masih dapat mengueri tabel `mysql`. Jika Anda menggunakan replikasi log biner, perubahan yang dilakukan langsung ke tabel `mysql` di klaster sumber tidak direplikasi ke klaster target. Dalam beberapa kasus, aplikasi Anda mungkin menggunakan pintasan untuk membuat pengguna atau objek lain dengan melakukan penyisipan ke dalam tabel `mysql`. Jika demikian, ubah kode aplikasi Anda untuk menggunakan pernyataan yang sesuai seperti `CREATE USER`. Jika aplikasi Anda membuat prosedur tersimpan atau objek lain dalam basis data `mysql`, gunakan basis data yang berbeda sebagai gantinya. Untuk mengekspor metadata bagi pengguna database selama migrasi dari database MySQL eksternal, Anda dapat menggunakan perintah MySQL Shell sebagai gantinya. `mysqldump` Untuk informasi selengkapnya, lihat [Instance Dump Utility, Schema Dump Utility, dan Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about). Untuk menyederhanakan pengelolaan izin bagi banyak pengguna atau aplikasi, Anda dapat menggunakan pernyataan `CREATE ROLE` untuk membuat peran yang memiliki serangkaian izin. Kemudian, Anda dapat menggunakan pernyataan `GRANT` dan `SET ROLE` serta fungsi `current_role` untuk menetapkan peran ke pengguna atau aplikasi, mengganti peran saat ini, dan memeriksa peran mana yang berlaku. Untuk informasi selengkapnya tentang sistem izin berbasis peran di MySQL 8.0, lihat [Using Roles](https://dev.mysql.com/doc/refman/8.0/en/roles.html) dalam Panduan Referensi MySQL. **penting** Kami sangat menyarankan agar Anda tidak menggunakan pengguna master secara langsung di aplikasi Anda. Sebagai gantinya, ikuti praktik terbaik menggunakan pengguna basis data yang dibuat dengan hak akses paling rendah yang diperlukan untuk aplikasi Anda. **Topics** + [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role) + [Hak istimewa memeriksa pengguna untuk replikasi log biner](#AuroraMySQL.privilege-model.binlog) + [Peran untuk mengakses layanan lain AWS](#AuroraMySQL.privilege-model.other) ### rds\$1superuser\$1role Aurora MySQL versi 3 mencakup peran khusus yang memiliki semua hak akses berikut. Peran ini bernama `rds_superuser_role`. Pengguna administratif primer untuk setiap klaster sudah diberi peran ini. Peran `rds_superuser_role` mencakup hak akses berikut untuk semua objek basis data: + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CONNECTION_ADMIN` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `FLUSH_OPTIMIZER_COSTS`(Aurora MySQL versi 3.09 dan lebih tinggi) + `FLUSH_STATUS`(Aurora MySQL versi 3.09 dan lebih tinggi) + `FLUSH_TABLES`(Aurora MySQL versi 3.09 dan lebih tinggi) + `FLUSH_USER_RESOURCES`(Aurora MySQL versi 3.09 dan lebih tinggi) + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW_ROUTINE` (Aurora MySQL versi 3.04 dan lebih tinggi) + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` Definisi peran juga mencakup `WITH GRANT OPTION` sehingga pengguna administratif dapat memberikan peran tersebut kepada pengguna lain. Secara khusus, administrator harus memberikan hak akses yang diperlukan untuk melakukan replikasi log biner dengan klaster Aurora MySQL sebagai target. **Tip** Untuk melihat detail lengkap izin, masukkan pernyataan berikut. ``` SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%'; ``` ### Hak istimewa memeriksa pengguna untuk replikasi log biner Aurora MySQL versi 3 mencakup hak istimewa memeriksa pengguna untuk replikasi log biner (binlog),. `rdsrepladmin_priv_checks_user` Selain hak istimewa`rds_superuser_role`, pengguna ini memiliki `replication_applier` hak istimewa. Ketika Anda mengaktifkan replikasi binlog dengan memanggil prosedur `mysql.rds_start_replication` tersimpan, `rdsrepladmin_priv_checks_user` dibuat. `rdsrepladmin_priv_checks_user@localhost`Pengguna adalah pengguna yang dicadangkan. Jangan memodifikasinya. ### Peran untuk mengakses layanan lain AWS Aurora MySQL versi 3 mencakup peran yang dapat Anda gunakan untuk mengakses layanan lain. AWS Anda dapat menetapkan banyak peran ini sebagai alternatif untuk memberikan hak istimewa. Misalnya, Anda menentukan `GRANT AWS_LAMBDA_ACCESS TO user`, bukan `GRANT INVOKE LAMBDA ON *.* TO user`. Untuk prosedur untuk mengakses AWS layanan lain, lihat[Mengintegrasikan Amazon Aurora MySQL dengan layanan lain AWS](AuroraMySQL.Integrating.md). Aurora MySQL versi 3 mencakup peran berikut yang terkait dengan mengakses layanan lain: AWS + `AWS_LAMBDA_ACCESS`Sebuah alternatif untuk hak `INVOKE LAMBDA` istimewa. Untuk informasi penggunaan, lihat [Menginvokasi fungsi Lambda dari klaster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). + `AWS_LOAD_S3_ACCESS`Sebuah alternatif untuk hak `LOAD FROM S3` istimewa. Untuk informasi penggunaan, lihat [Memuat data ke klaster DB Amazon Aurora MySQL dari file teks di bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). + `AWS_SELECT_S3_ACCESS`Sebuah alternatif untuk hak `SELECT INTO S3` istimewa. Untuk informasi penggunaan, lihat [Menyimpan data dari klaster DB Amazon Aurora MySQL ke dalam file teks di bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). + `AWS_COMPREHEND_ACCESS`Sebuah alternatif untuk hak `INVOKE COMPREHEND` istimewa. Untuk informasi penggunaan, lihat [Memberikan akses pengguna basis data ke machine learning Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_SAGEMAKER_ACCESS`Sebuah alternatif untuk hak `INVOKE SAGEMAKER` istimewa. Untuk informasi penggunaan, lihat [Memberikan akses pengguna basis data ke machine learning Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_BEDROCK_ACCESS`— Tidak ada `INVOKE` hak istimewa analog untuk Amazon Bedrock. Untuk informasi penggunaan, lihat [Memberikan akses pengguna basis data ke machine learning Aurora](mysql-ml.md#aurora-ml-sql-privileges). Ketika Anda memberikan akses dengan menggunakan peran di Aurora MySQL versi 3, Anda juga perlu mengaktifkan peran ini dengan menggunakan pernyataan `SET ROLE role_name` atau `SET ROLE ALL`. Contoh berikut menunjukkan cara melakukannya. Ganti nama peran yang sesuai untuk `AWS_SELECT_S3_ACCESS`. ``` # Grant role to user. mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +-----------------------------------------------------+ | CURRENT_ROLE() | +-----------------------------------------------------+ | `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` | +-----------------------------------------------------+ ``` ## Menemukan ID server database ID server database (`server_id`) diperlukan untuk replikasi biner logging (binlog). Cara menemukan ID server berbeda di Aurora MySQL dari MySQL Komunitas. Di MySQL Komunitas, ID server adalah nomor, yang Anda dapatkan dengan menggunakan sintaks berikut saat masuk ke server: ``` mysql> select @@server_id; +-------------+ | @@server_id | +-------------+ | 2 | +-------------+ 1 row in set (0.00 sec) ``` Di Aurora MySQL, ID server adalah ID instans DB, yang Anda dapatkan dengan menggunakan sintaks berikut saat masuk ke instance DB: ``` mysql> select @@aurora_server_id; +------------------------+ | @@aurora_server_id | +------------------------+ | mydbcluster-instance-2 | +------------------------+ 1 row in set (0.00 sec) ``` Untuk informasi lebih lanjut tentang replikasi binlog, lihat. [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md) ## Autentikasi Di MySQL 8.0 komunitas, plugin autentikasi default adalah `caching_sha2_password`. Aurora MySQL versi 3 masih menggunakan plugin `mysql_native_password`. Anda tidak dapat mengubah pengaturan `default_authentication_plugin`. Namun, Anda dapat membuat pengguna baru dan mengubah pengguna saat ini, dan kata sandi masing-masing menggunakan plugin otentikasi baru. Berikut adalah contohnya. ``` mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword'; Query OK, 0 rows affected (0.74 sec) ``` # Meningkatkan ke Aurora MySQL versi 3 Untuk informasi tentang memutakhirkan database Anda dari Aurora MySQL versi 2 ke versi 3, lihat. [Meningkatkan versi mayor klaster DB Amazon Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md)