' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
Precheck melaporkan bahwa tabel `test.test` memiliki operasi Fast DDL yang tertunda.
Untuk memungkinkan pemutakhiran dilanjutkan, Anda dapat membangun kembali tabel, lalu coba lagi pemutakhiran.
Sebelum membangun kembali tablespace, lihat [Operasi DDL online](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) di dokumentasi MySQL untuk memahami efek penguncian dan pergerakan data pada transaksi latar depan.
```
mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status | OK |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)
```
Setelah membangun kembali tabel, precheck berhasil.
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**Tingkat precheck: Kesalahan**
**Tabel dengan referensi `FULLTEXT` indeks menggantung**
Sebelum MySQL 5.6.26, ada kemungkinan bahwa setelah menjatuhkan indeks pencarian teks lengkap, kolom tersembunyi dan akan menjadi yatim piatu. `FTS_DOC_ID` `FTS_DOC_ID_INDEX` Untuk informasi selengkapnya, lihat [Bug \$176012](https://bugs.mysql.com/bug.php?id=76012).
Jika Anda memiliki tabel yang dibuat pada versi MySQL sebelumnya di mana hal ini terjadi, ini dapat menyebabkan peningkatan ke Aurora MySQL versi 3 gagal. Precheck ini memverifikasi bahwa tidak ada indeks teks lengkap yatim piatu, atau “menggantung” yang ada di cluster DB Anda sebelum memutakhirkan ke MySQL 8.0. Jika precheck ini gagal, buat kembali tabel apa pun yang berisi indeks teks lengkap yang menggantung.
**Contoh keluaran:**
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.table_with_fts_index",
"description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}
]
},
```
Precheck melaporkan kesalahan untuk `test.table_with_fts_index` tabel karena berisi indeks teks lengkap yang menggantung. Untuk memungkinkan upgrade untuk melanjutkan, membangun kembali tabel untuk membersihkan tabel tambahan indeks teks lengkap. Gunakan `OPTIMIZE TABLE test.table_with_fts_index` atau`ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`.
Setelah membangun kembali tabel, precheck berlalu.
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**Tingkat precheck: Kesalahan**
**Periksa ketidakkonsistenan yang terkait dengan jalur `ibd` file**
Precheck ini hanya berlaku untuk Aurora MySQL versi 3.03.0 dan yang lebih rendah. Jika Anda mengalami kesalahan dengan precheck ini, tingkatkan ke Aurora MySQL versi 3.04 atau lebih tinggi.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**Tingkat precheck: Kesalahan**
**Periksa indeks teks lengkap dengan ID spasi sebagai nol**
Di MySQL, saat Anda menambahkan [indeks teks lengkap](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) ke tabel InnoDB, sejumlah ruang tabel indeks tambahan dibuat. Karena [bug](https://bugs.mysql.com/bug.php?id=72132) di versi MySQL sebelumnya, yang diperbaiki di versi 5.6.20, ada kemungkinan bahwa tabel indeks tambahan ini dibuat di tablespace [sistem](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace), bukan tablespace InnoDB mereka sendiri.
Jika ada ruang tabel tambahan seperti itu, pemutakhiran akan gagal. Buat ulang indeks teks lengkap yang disebutkan dalam kesalahan precheck, lalu coba lagi pemutakhiran.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
Precheck melaporkan kesalahan untuk `test.fts_space_zero_check` tabel, karena memiliki tabel pencarian teks lengkap (FTS) tambahan di tablespace sistem.
Setelah Anda menjatuhkan dan membuat ulang indeks FTS yang terkait dengan tabel ini, precheck berhasil.
Sebelum membangun kembali ruang tabel, lihat [Mempartisi operasi dalam](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) dokumentasi MySQL untuk memahami efek penguncian dan pergerakan data pada transaksi latar depan.
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**Tingkat precheck: Kesalahan**
**Periksa transaksi XA dalam keadaan siap**
[Saat menjalankan proses peningkatan versi utama, penting bahwa instance Aurora MySQL versi 2 DB mengalami shutdown yang bersih.](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) Ini memastikan bahwa semua transaksi dilakukan atau dibatalkan, dan bahwa InnoDB telah membersihkan semua catatan log undo. Karena rollback transaksi diperlukan, jika database Anda memiliki [transaksi XA](https://dev.mysql.com/doc/refman/5.7/en/xa.html) dalam keadaan siap, itu dapat memblokir shutdown bersih dari proses. Untuk alasan ini, jika ada transaksi XA yang disiapkan terdeteksi, peningkatan tidak akan dapat dilanjutkan sampai Anda mengambil tindakan untuk melakukan atau mengembalikannya.
Untuk informasi selengkapnya tentang menemukan transaksi XA dalam keadaan siap menggunakan`XA RECOVER`, lihat [pernyataan SQL transaksi XA dalam dokumentasi MySQL](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html). Untuk informasi selengkapnya tentang status transaksi XA, lihat [status transaksi XA dalam dokumentasi](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html) MySQL.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
}
]
}
```
Precheck ini melaporkan kesalahan karena ada transaksi dalam keadaan siap yang harus dilakukan atau dibatalkan.
Setelah masuk ke database, Anda dapat memeriksa tabel [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) dan output untuk informasi lebih lanjut. `XA RECOVER`
Sebelum melakukan atau mengembalikan transaksi, kami sarankan Anda meninjau dokumentasi [MySQL](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) dan persyaratan aplikasi Anda.
```
mysql> select trx_started,
trx_mysql_thread_id,
trx_id,trx_state,
trx_operation_state,
trx_rows_modified,
trx_rows_locked
from
information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started | trx_mysql_thread_id | trx_id | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 | 0 | 2849470 | RUNNING | NULL | 1 | 0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)
mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+--------+
| 1 | 6 | 0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)
```
Dalam hal ini, kami memutar kembali transaksi yang disiapkan.
```
mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)
```
Setelah transaksi XA dibatalkan, precheck berhasil.
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**Tingkat precheck: Kesalahan**
**Periksa apakah upgrade didukung pada kelas instance saat ini**
Menjalankan pemutakhiran di tempat dari Aurora MySQL versi 2.12.0 atau 2.12.1, di mana kelas instans DB [penulis adalah db.r6i.32xlarge, saat](Concepts.DBInstanceClass.md) ini tidak didukung. Dalam hal ini, precheck mengembalikan kesalahan. Untuk memungkinkan pemutakhiran dilanjutkan, Anda dapat mengubah kelas instans DB Anda menjadi db.r6i.24xlarge atau lebih kecil. Atau Anda dapat meningkatkan ke Aurora MySQL versi 2.12.2 atau lebih tinggi, di mana upgrade di tempat ke Aurora MySQL versi 3 didukung pada db.r6i.32xlarge.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForInstanceLimit",
"title": "Checks if upgrade is supported on the current instance class",
"status": "OK",
"description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
}
]
},
```
Precheck mengembalikan kesalahan karena instance DB penulis menggunakan kelas instance db.r6i.32xlarge, dan berjalan pada Aurora MySQL versi 2.12.1.
**auroraUpgradeCheckForInternalUsers**
**Tingkat precheck: Kesalahan**
**Periksa 8.0 pengguna internal**
Precheck ini hanya berlaku untuk Aurora MySQL versi 3.03.0 dan yang lebih rendah. Jika Anda mengalami kesalahan dengan precheck ini, tingkatkan ke Aurora MySQL versi 3.04 atau lebih tinggi.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3 CharacterStringInViews**
**Tingkat precheck: Kesalahan**
**Periksa karakter utf8mb3 yang tidak valid dalam definisi tampilan**
Precheck ini mengidentifikasi tampilan yang berisi komentar dengan pengkodean karakter yang tidak valid`utf8mb3`. Di MySQL 8.0, validasi yang lebih ketat diterapkan pada pengkodean karakter dalam metadata, termasuk komentar tampilan. Jika ada definisi tampilan yang berisi karakter yang tidak valid dalam kumpulan `utf8mb3` karakter, pemutakhiran gagal.
Untuk mengatasi masalah ini, ubah definisi tampilan untuk menghapus atau mengganti karakter non-BMP sebelum Anda mencoba upgrade.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews",
"title": "Check for invalid utf8mb3 character string.",
"status": "OK",
"description": "Definition of following view(s) has/have invalid utf8mb3 character string.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_invalid_char_view",
"description": "Definition of view precheck.utf8mb3_invalid_char_view contains an invalid utf8mb3 character string. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify the view definition to not use non-BMP characters and try the upgrade again."
}
]
},
```
Precheck melaporkan bahwa definisi `utf8mb3_invalid_char_view` tampilan berisi `utf8mb3` karakter yang tidak valid dalam definisinya.
Untuk mengatasi masalah ini, identifikasi tampilan yang berisi karakter yang tidak didukung dan perbarui komentar. Pertama, periksa struktur tampilan dan identifikasi komentar.
```
MySQL> SHOW CREATE VIEW precheck.utf8mb3_invalid_char_view\G
*************************** 1. row ***************************
View: utf8mb3_invalid_char_view
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`admin`@`%` SQL SECURITY DEFINER VIEW `utf8mb3_invalid_char_view` AS select 'This row contains a dolphin 🐬' AS `message`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set, 1 warning (0.00 sec)
```
Setelah Anda mengidentifikasi tampilan yang berisi kesalahan, ganti tampilan dengan `CREATE OR REPLACE VIEW` pernyataan.
```
MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;
```
Setelah memperbarui semua definisi tampilan yang berisi karakter yang tidak didukung, precheck berlalu dan pemutakhiran dapat dilanjutkan.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3 ColumnComments**
**Tingkat precheck: Kesalahan**
**Periksa komentar kolom utf8mb3 yang tidak valid**
Precheck ini mengidentifikasi tabel yang berisi komentar kolom dengan pengkodean karakter yang tidak valid`utf8mb3`. Di MySQL 8.0, validasi yang lebih ketat diterapkan pada pengkodean karakter dalam metadata, termasuk komentar kolom. Jika ada komentar kolom yang berisi karakter yang tidak valid dalam set karakter utf8mb3, pemutakhiran akan gagal.
Untuk mengatasi masalah ini, Anda harus memodifikasi kolom komentar untuk menghapus atau mengganti karakter non-BMP sebelum mencoba upgrade. Anda dapat menggunakan `ALTER TABLE` pernyataan untuk memperbarui kolom komentar.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
Precheck melaporkan bahwa `test.t2` tabel berisi `utf8mb3` karakter yang tidak valid dalam satu atau beberapa kolom komentar, khususnya karena adanya karakter non-BMP.
Untuk mengatasi masalah ini, Anda dapat mengidentifikasi kolom bermasalah dan memperbarui komentar mereka. Pertama, periksa struktur tabel untuk mengidentifikasi kolom dengan komentar:
```
mysql> SHOW CREATE TABLE test.t2\G
```
Setelah Anda mengidentifikasi kolom dengan komentar bermasalah, perbarui dengan menggunakan `ALTER TABLE` pernyataan. Misalnya:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
Atau, Anda dapat menghapus komentar sepenuhnya:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
Setelah memperbarui semua komentar kolom yang bermasalah, precheck akan lulus dan peningkatan dapat dilanjutkan:
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
Sebelum memodifikasi komentar kolom, pastikan bahwa kode aplikasi atau dokumentasi apa pun yang bergantung pada komentar ini diperbarui sesuai dengan itu. Pertimbangkan untuk bermigrasi ke set karakter utf8mb4 untuk dukungan Unicode yang lebih baik jika aplikasi Anda memerlukan karakter non-BMP.
**auroraUpgradeCheckForInvalidUtf8mb3 IndexComments**
**Tingkat precheck: Kesalahan**
**Periksa komentar indeks utf8mb3 yang tidak valid**
Precheck ini mengidentifikasi tabel yang berisi komentar indeks dengan pengkodean karakter yang tidak valid`utf8mb3`. Di MySQL 8.0, validasi yang lebih ketat diterapkan pada pengkodean karakter dalam metadata, termasuk komentar indeks. Jika ada komentar indeks yang berisi karakter yang tidak valid dalam kumpulan `utf8mb3` karakter, pemutakhiran gagal.
Untuk mengatasi masalah ini, Anda harus mengubah komentar indeks untuk menghapus atau mengganti karakter non-BMP sebelum mencoba upgrade.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the index.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_tab_index_comment",
"description": "Table precheck.utf8mb3_tab_index_comment has invalid utf8mb3 comments in it's index. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
Precheck melaporkan bahwa `utf8mb3_tab_index_comment` tabel berisi `utf8mb3` karakter yang tidak valid dalam satu atau beberapa kolom komentar, khususnya karena adanya karakter non-BMP.
Untuk mengatasi masalah ini, pertama, periksa struktur tabel untuk mengidentifikasi indeks dengan komentar bermasalah.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_tab_index_comment\G
*************************** 1. row ***************************
Table: utf8mb3_tab_index_comment
Create Table: CREATE TABLE `utf8mb3_tab_index_comment` (
`id` int(11) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
KEY `idx_name` (`name`) COMMENT 'Name index 🐬'
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)
```
Setelah Anda mengidentifikasi indeks yang berisi komentar yang menggunakan karakter yang tidak didukung, jatuhkan dan buat ulang indeks.
Menjatuhkan dan membuat ulang indeks tabel dapat menyebabkan downtime. Kami menyarankan Anda merencanakan dan menjadwalkan operasi ini selama pemeliharaan.
```
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment DROP INDEX idx_name;
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment ADD INDEX idx_name(name);
```
Contoh berikut menunjukkan cara lain untuk membuat ulang indeks.
```
MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';
```
Setelah Anda menghapus atau memperbarui semua komentar indeks yang tidak didukung, precheck akan berlalu dan pemutakhiran dapat dilanjutkan.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForInvalidUtf8mb3 TableComments**
**Tingkat precheck: Kesalahan**
**Periksa karakter utf8mb3 yang tidak valid dalam definisi tabel**
Precheck ini mengidentifikasi tabel yang berisi komentar dengan pengkodean karakter yang tidak valid`utf8mb3`. Di MySQL 8.0, validasi yang lebih ketat diterapkan pada pengkodean karakter dalam metadata, termasuk komentar tabel. Jika ada komentar tabel yang berisi karakter yang tidak valid dalam set `utf8mb3` karakter, pemutakhiran gagal.
Untuk mengatasi masalah ini, Anda harus mengubah komentar tabel untuk menghapus atau mengganti karakter non-BMP sebelum mencoba upgrade.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_table_with_comment",
"description": "Table precheck.utf8mb3_table_with_comment has invalid utf8mb3 comments. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
Precheck melaporkan `utf8mb3` komentar tidak valid yang ditentukan untuk `utf8mb3_table_with_comment` tabel dalam database pengujian.
Untuk mengatasi masalah ini, identifikasi tabel yang berisi karakter yang tidak didukung dan perbarui komentar. Pertama, periksa struktur tabel dan identifikasi komentarnya.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_table_with_comment\G
*************************** 1. row ***************************
Table: utf8mb3_table_with_comment
Create Table: CREATE TABLE `utf8mb3_table_with_comment` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='This table comment contains flag 🏳️'
1 row in set (0.00 sec)
```
Setelah Anda mengidentifikasi komentar tabel yang berisi obrolan yang tidak didukung, perbarui komentar dengan pernyataan tersebut. `ALTER TABLE`
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';
```
Atau, Anda dapat menghapus komentar.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';
```
Setelah Anda menghapus semua karakter yang tidak didukung dari semua komentar tabel, precheck berhasil.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForMasterUser**
**Tingkat precheck: Kesalahan**
**Periksa apakah pengguna master RDS ada**
MySQL 8 telah menambahkan model hak istimewa baru dengan dukungan [untuk peran dan hak istimewa dinamis untuk](https://dev.mysql.com/doc/refman/8.0/en/roles.html) [membuat manajemen hak istimewa lebih mudah dan](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) lebih halus. Sebagai bagian dari perubahan ini, Aurora MySQL telah memperkenalkan yang baru`rds_superuser_role`, yang secara otomatis diberikan kepada pengguna master database pada peningkatan dari Aurora MySQL versi 2 ke versi 3.
Untuk informasi selengkapnya tentang peran dan hak istimewa yang diberikan kepada pengguna master di Aurora MySQL, lihat. [Hak akses akun pengguna master](UsingWithRDS.MasterAccounts.md) Untuk informasi lebih lanjut tentang model hak istimewa berbasis peran di Aurora MySQL versi 3, lihat. [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)
Precheck ini memverifikasi bahwa pengguna master ada dalam database. Jika pengguna master tidak ada, precheck gagal. Untuk memungkinkan pemutakhiran dilanjutkan, buat ulang pengguna master dengan mengatur ulang kata sandi pengguna master, atau dengan membuat pengguna secara manual. Kemudian coba lagi upgrade. Untuk informasi selengkapnya tentang mengatur ulang kata sandi pengguna utama, lihat[Mengubah kata sandi untuk pengguna master database](Aurora.Modifying.md#Aurora.Modifying.Password).
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForMasterUser",
"title": "Check if master user exists",
"status": "OK",
"description": "Throws error if master user has been dropped!",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
}
]
}
```
Setelah Anda mengatur ulang kata sandi pengguna utama Anda, precheck akan lulus, dan Anda dapat mencoba kembali upgrade.
Contoh berikut menggunakan AWS CLI untuk mengatur ulang kata sandi. Perubahan kata sandi diterapkan segera.
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
Kemudian precheck berhasil.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**Tingkat precheck: Kesalahan**
**Periksa kolom geometri pada indeks awalan**
[Pada [MySQL](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support) 8.0.12, Anda tidak dapat lagi membuat indeks awalan pada kolom [menggunakan](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) tipe data GEOMETRY.](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html) Untuk informasi lebih lanjut, lihat [WL \$111808](https://dev.mysql.com/worklog/task/?id=11808).
Jika ada indeks seperti itu, pemutakhiran Anda akan gagal. Untuk mengatasi masalah ini, letakkan `GEOMETRY` indeks awalan pada tabel yang disebutkan dalam kegagalan precheck.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.geom_index_prefix",
"description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
}
]
}
```
Precheck melaporkan kesalahan karena `test.geom_index_prefix` tabel berisi indeks dengan awalan pada kolom. `GEOMETRY`
Setelah Anda menjatuhkan indeks ini, precheck berhasil.
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**Tingkat precheck: Kesalahan**
**Periksa ketidakkonsistenan yang terkait dengan karakter khusus dalam prosedur tersimpan**
Sebelum MySQL 8.0, nama database, nama tabel, dan objek lain berhubungan dengan file dalam direktori data, yaitu metadata berbasis file. [Sebagai bagian dari upgrade ke MySQL 8.0, semua objek database dimigrasikan ke tabel kamus data internal baru yang disimpan dalam `mysql` skema untuk mendukung Kamus Data Atom yang baru diimplementasikan.](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) Sebagai bagian dari migrasi prosedur tersimpan, definisi prosedur dan isi untuk setiap prosedur divalidasi karena dimasukkan ke dalam kamus data baru.
Sebelum MySQL 8, dalam beberapa kasus dimungkinkan untuk membuat rutinitas yang disimpan, atau memasukkan langsung ke dalam tabel, prosedur `mysql.proc` yang berisi karakter khusus. Misalnya, Anda dapat membuat prosedur tersimpan yang berisi komentar dengan karakter spasi yang tidak sesuai dan [tidak melanggar](https://en.wikipedia.org/wiki/Non-breaking_space). `\xa0` Jika ada prosedur seperti itu ditemui, upgrade gagal.
Precheck ini memvalidasi bahwa isi dan definisi prosedur tersimpan Anda tidak mengandung karakter seperti itu. Untuk memungkinkan peningkatan dilanjutkan, buat ulang prosedur tersimpan ini tanpa karakter tersembunyi atau khusus.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"description": "Following procedure(s) has special characters inconsistency.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "information_schema.routines",
"description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
}
]
}
```
Precheck melaporkan bahwa cluster DB berisi prosedur yang disebut `get_version_proc` dalam `test` database yang berisi karakter khusus dalam badan prosedur.
Setelah menjatuhkan dan membuat ulang prosedur yang disimpan, precheck berhasil, memungkinkan peningkatan untuk melanjutkan.
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**Tingkat precheck: Kesalahan**
**Periksa ketidakcocokan tipe objek untuk skema `sys`**
[Skema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) adalah sekumpulan objek dan tampilan dalam database MySQL yang membantu pengguna memecahkan masalah, mengoptimalkan, dan memantau instance DB mereka. Saat melakukan upgrade versi utama dari Aurora MySQL versi 2 ke versi 3, tampilan `sys` skema dibuat ulang dan diperbarui ke definisi Aurora MySQL versi 3 yang baru.
Sebagai bagian dari peningkatan, jika ada objek dalam `sys` skema yang didefinisikan menggunakan mesin penyimpanan (`sys_config/BASE TABLE`di [INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)), bukan tampilan, pemutakhiran akan gagal. Tabel semacam itu dapat ditemukan di `information_schema.tables` tabel. Ini bukan perilaku yang diharapkan, tetapi dalam beberapa kasus dapat terjadi karena kesalahan pengguna.
Precheck ini memvalidasi semua objek `sys` skema untuk memastikan bahwa mereka menggunakan definisi tabel yang benar, dan bahwa tampilan tidak salah didefinisikan sebagai tabel InnoDB atau MyISAM. Untuk mengatasi masalah ini, perbaiki objek yang dikembalikan secara manual dengan mengganti nama atau menjatuhkannya. Kemudian coba lagi upgrade.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"description": "Database contains objects with type mismatch for sys schema.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sys.waits_global_by_latency",
"description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
}
]
}
```
Precheck melaporkan bahwa tampilan [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) dalam skema memiliki ketidakcocokan tipe yang memblokir pemutakhiran agar tidak melanjutkan. `sys`
Setelah masuk ke instance DB, Anda dapat melihat bahwa objek ini didefinisikan sebagai tabel InnoDB, ketika seharusnya tampilan.
```
mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
`events` varchar(128) DEFAULT NULL,
`total` bigint(20) unsigned DEFAULT NULL,
`total_latency` text,
`avg_latency` text,
`max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Untuk mengatasi masalah ini, kami dapat menghapus dan membuat ulang tampilan dengan [definisi yang benar](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql) atau mengganti namanya. Selama proses upgrade, itu akan secara otomatis dibuat dengan definisi tabel yang benar.
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
Setelah melakukan ini, precheck berlalu.
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**Tingkat precheck: Kesalahan**
**Periksa batas atas untuk nama kolom dalam tampilan**
[Panjang maksimum yang diizinkan dari nama kolom](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) di MySQL adalah 64 karakter. Sebelum MySQL 8.0, dalam beberapa kasus dimungkinkan untuk membuat tampilan dengan nama kolom yang lebih besar dari 64 karakter. Jika ada tampilan seperti itu pada instance database Anda, kesalahan precheck dikembalikan, dan pemutakhiran akan gagal. Untuk memungkinkan pemutakhiran dilanjutkan, Anda harus membuat ulang tampilan yang dimaksud, memastikan bahwa panjang kolomnya kurang dari 64 karakter. Kemudian coba lagi upgrade.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"description": "Following view(s) has column(s) with length greater than 64.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
"description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
}
]
}
```
Precheck melaporkan bahwa `test.colname_view_test` tampilan berisi kolom `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` yang melebihi panjang kolom maksimum yang diizinkan dari 64 karakter.
Melihat definisi tampilan, kita bisa melihat kolom yang menyinggung.
```
mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11) | YES | | NULL | |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Untuk memungkinkan pemutakhiran dilanjutkan, buat ulang tampilan, pastikan panjang kolom tidak melebihi 64 karakter.
```
mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)
mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)
mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_nopad | int(11) | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Setelah melakukan ini, precheck berhasil.
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**Tingkat precheck: Kesalahan**
**Periksa tabel dengan indeks yang didefinisikan dengan panjang awalan lebih besar dari 255 byte pada kolom kecil**
Saat membuat indeks pada kolom menggunakan [tipe data biner](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) di MySQL, Anda harus menambahkan panjang awalan [dalam](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) definisi indeks. Sebelum MySQL 8.0, dalam beberapa kasus dimungkinkan untuk menentukan panjang awalan yang lebih besar dari ukuran maksimum yang diizinkan dari tipe data tersebut. Contohnya adalah `TINYTEXT` dan `TINYBLOB` kolom, di mana ukuran data maksimum yang diizinkan adalah 255 byte, tetapi awalan indeks yang lebih besar dari ini diizinkan. Untuk informasi selengkapnya, lihat [batas InnoDB dalam dokumentasi](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) MySQL.
Jika precheck ini gagal, jatuhkan indeks yang menyinggung atau kurangi panjang awalan `TINYTEXT` dan `TINYBLOB` kolom indeks menjadi kurang dari 255 byte. Kemudian coba lagi upgrade.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.tintxt_prefixed_index.col1",
"description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
}
]
}
```
Precheck melaporkan kesalahan untuk `test.tintxt_prefixed_index` tabel, karena memiliki Indeks `PRIMARY` yang memiliki awalan lebih besar dari 255 byte pada kolom TINYTEXT atau TINYBLOB.
Melihat definisi untuk tabel ini, kita dapat melihat bahwa kunci utama memiliki awalan 65 pada `TINYTEXT` kolom`col1`. Karena tabel didefinisikan menggunakan set `utf8mb4` karakter, yang menyimpan 4 byte per karakter, awalan melebihi batas 255-byte.
```
mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
`col1` tinytext NOT NULL,
`col2` tinytext,
`col_id` tinytext,
PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)
```
Memodifikasi awalan indeks ke 63 saat menggunakan set `utf8mb4` karakter akan memungkinkan peningkatan untuk melanjutkan.
```
mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0
```
Setelah melakukan ini, precheck berhasil.
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**Tingkat precheck: Kesalahan**
**Periksa inkonsistensi metadata InnoDB yang hilang untuk tabel `mysql.host`**
Ini adalah precheck internal saja yang dilakukan oleh layanan RDS. Kesalahan apa pun akan ditangani secara otomatis saat upgrade dan dapat diabaikan dengan aman.
Jika Anda menemukan kesalahan dengan precheck ini, buka kasus dengan [AWS Support](https://aws.amazon.com/support) untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba kembali upgrade dengan melakukan dump logis, kemudian mengembalikan ke cluster Aurora MySQL versi 3 DB baru.
## Peringatan
Prechecks berikut menghasilkan peringatan ketika precheck gagal, tetapi upgrade dapat dilanjutkan.
**Topics**
+ [MySQL memeriksa sebelumnya yang melaporkan peringatan](#precheck-descriptions-warnings.mysql)
+ [Aurora MySQL mengecek peringatan laporan itu](#precheck-descriptions-warnings.aurora)
### MySQL memeriksa sebelumnya yang melaporkan peringatan
Precheck berikut berasal dari MySQL Komunitas:
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [UTF8MB3Periksa](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**Tingkat precheck: Peringatan**
**Pertimbangan plugin otentikasi default baru**
Di MySQL 8.0, plugin otentikasi diperkenalkan, `caching_sha2_password` menyediakan enkripsi kata sandi yang lebih aman dan kinerja yang lebih baik daripada plugin yang tidak digunakan lagi. `mysql_native_password` Untuk Aurora MySQL versi 3, plugin otentikasi default yang digunakan untuk pengguna database adalah plugin. `mysql_native_password`
Precheck ini memperingatkan bahwa plugin ini akan dihapus dan default diubah dalam rilis versi utama masa depan. Pertimbangkan untuk mengevaluasi kompatibilitas klien dan pengguna aplikasi Anda sebelum perubahan ini.
Untuk informasi selengkapnya, lihat masalah [kompatibilitas caching\$1sha2\$1password dan solusi](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "defaultAuthenticationPlugin",
"title": "New default authentication plugin considerations",
"description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},
```
**maxdbFlagCheck**
**Tingkat precheck: Peringatan**
**Penggunaan bendera usang `MAXDB` `sql_mode`**
[Di MySQL 8.0, sejumlah opsi variabel sistem [sql\$1mode yang tidak digunakan lagi](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) telah dihapus, salah satunya adalah.](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) `MAXDB` Precheck ini memeriksa semua sesi yang terhubung saat ini, bersama dengan rutinitas dan pemicu, untuk memastikan bahwa tidak ada yang `sql_mode` mengatur kombinasi apa pun yang disertakan. `MAXDB`
**Contoh keluaran:**
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.maxdb_stored_routine",
"description": "PROCEDURE uses obsolete MAXDB sql_mode",
"dbObjectType": "Routine"
}
]
}
```
Precheck melaporkan bahwa `test.maxdb_stored_routine` rutinitas berisi opsi yang tidak didukung`sql_mode`.
Setelah masuk ke database, Anda dapat melihat dalam definisi rutin yang `sql_mode` berisi`MAXDB`.
```
> SHOW CREATE PROCEDURE test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Untuk mengatasi masalah, buat kembali prosedur setelah mengatur yang benar `sql_mode` pada klien.
Menurut [dokumentasi MySQL, MySQL](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html) menyimpan `sql_mode` pengaturan yang berlaku ketika rutinitas dibuat atau diubah. Itu selalu menjalankan rutinitas dengan pengaturan ini, terlepas dari `sql_mode` pengaturan ketika rutinitas dimulai.
Sebelum mengubah`sql_mode`, lihat [mode Server SQL](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) dalam dokumentasi MySQL. Hati-hati mengevaluasi dampak potensial dari melakukannya pada aplikasi Anda.
Buat ulang prosedur tanpa yang tidak `sql_mode` didukung.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Precheck berhasil.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**Tingkat precheck: Peringatan**
**Periksa penggunaan tanda dolar tunggal yang tidak digunakan lagi dalam nama objek**
Pada [MySQL](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal) 8.0.32, penggunaan tanda dolar `$` () sebagai karakter pertama dari pengidentifikasi yang tidak dikutip tidak digunakan lagi. Jika Anda memiliki skema, tabel, tampilan, kolom, atau rutinitas yang berisi `$` sebagai karakter pertama, precheck ini mengembalikan peringatan. Meskipun peringatan ini tidak menghalangi peningkatan untuk melanjutkan, kami menyarankan Anda segera mengambil tindakan untuk menyelesaikannya. Dari [MySQL](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) 8.4 pengidentifikasi semacam itu akan mengembalikan kesalahan sintaks daripada peringatan.
**Contoh keluaran:**
```
{
"id": "mysqlDollarSignNameCheck",
"title": "Check for deprecated usage of single dollar signs in object names",
"status": "OK",
"description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.$deprecated_syntx",
"description": " name starts with $ sign."
}
]
},
```
Precheck melaporkan peringatan karena `$deprecated_syntx` tabel dalam `test` skema berisi a `$` sebagai karakter pertama.
**reservedKeywordsCheck**
**Tingkat precheck: Peringatan**
**Penggunaan objek database dengan nama yang bertentangan dengan kata kunci baru yang dicadangkan**
Pemeriksaan ini mirip dengan [routineSyntaxCheck](#routineSyntaxCheck), karena memeriksa penggunaan objek database dengan nama yang bertentangan dengan kata kunci baru yang dicadangkan. Meskipun mereka tidak memblokir peningkatan, Anda perlu mengevaluasi peringatan dengan hati-hati.
**Contoh keluaran:**
Menggunakan contoh sebelumnya dengan tabel bernama`except`, precheck mengembalikan peringatan:
```
{
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.except",
"description": "Table name",
"dbObjectType": "Table"
}
]
}
```
Peringatan ini memberi tahu Anda bahwa mungkin ada beberapa kueri aplikasi untuk ditinjau. Jika kueri aplikasi Anda tidak [lolos dari literal string dengan benar, mereka mungkin mengalami kesalahan setelah memutakhirkan](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html) ke MySQL 8.0. Tinjau aplikasi Anda untuk mengonfirmasi, menguji klon atau snapshot dari cluster DB MySQL Aurora Anda yang berjalan pada versi 3.
Contoh kueri aplikasi yang tidak lolos yang akan gagal setelah memutakhirkan:
```
SELECT * FROM escape;
```
Contoh kueri aplikasi yang lolos dengan benar yang akan berhasil setelah memutakhirkan:
```
SELECT * FROM 'escape';
```
**UTF8MB3Periksa**
**Tingkat precheck: Peringatan**
**Penggunaan set `utf8mb3` karakter**
Di MySQL 8.0 `utf8mb3` set karakter tidak digunakan lagi, dan akan dihapus dalam versi utama MySQL future. Precheck ini diimplementasikan untuk memunculkan peringatan jika ada objek database yang menggunakan set karakter ini terdeteksi. Meskipun ini tidak akan memblokir peningkatan dari proses, kami sangat menyarankan Anda berpikir tentang memigrasikan tabel ke set `utf8mb4` karakter, yang merupakan default pada MySQL 8.0. Untuk informasi selengkapnya tentang [utf8mb3 dan [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html), lihat [Mengonversi antara set karakter Unicode 3-byte dan 4-byte](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "utf8mb3",
"title": "Usage of utf8mb3 charset",
"status": "OK",
"description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.t1.col1",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
},
{
"level": "Warning",
"dbObject": "test.t1.col2",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
}
]
}
```
Untuk mengatasi masalah ini, Anda membangun kembali objek dan tabel yang direferensikan. Untuk informasi selengkapnya dan prasyarat sebelum melakukannya, lihat [Mengonversi antara set karakter Unicode 3-byte dan 4-byte](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) dalam dokumentasi MySQL.
**zeroDatesCheck**
**Tingkat precheck: Peringatan**
**Nilai tanggal nol, datetime, dan stempel waktu**
MySQL sekarang memberlakukan aturan yang lebih ketat mengenai penggunaan nilai nol di kolom tanggal, datetime, dan timestamp. Kami menyarankan Anda menggunakan `NO_ZERO_DATE SQL` mode `NO_ZERO_IN_DATE` dan dalam hubungannya dengan `strict` mode, karena mereka akan digabungkan dengan `strict` mode dalam rilis MySQL future.
Jika `sql_mode` pengaturan untuk salah satu koneksi database Anda, pada saat menjalankan precheck, tidak menyertakan mode ini, peringatan akan muncul di precheck. Pengguna mungkin masih dapat menyisipkan nilai tanggal, datetime, dan stempel waktu yang berisi nilai nol. Namun, kami sangat menyarankan untuk mengganti nilai nol dengan nilai yang valid, karena perilakunya mungkin berubah di masa mendatang dan mungkin tidak berfungsi dengan benar. Karena ini adalah peringatan, ini tidak akan memblokir peningkatan, tetapi kami menyarankan Anda mulai merencanakan untuk mengambil tindakan.
**Contoh keluaran:**
```
{
"id": "zeroDatesCheck",
"title": "Zero Date, Datetime, and Timestamp values",
"status": "OK",
"description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
"documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "global.sql_mode",
"description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
},
{
"level": "Warning",
"dbObject": "session.sql_mode",
"description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
}
]
}
```
### Aurora MySQL mengecek peringatan laporan itu
Precheck berikut khusus untuk Aurora MySQL:
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**Tingkat precheck: Peringatan**
**Memeriksa apakah panjang daftar riwayat segmen rollback untuk cluster tinggi**
[Seperti disebutkan dalam [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), saat menjalankan proses peningkatan versi utama, penting bahwa instance Aurora MySQL versi 2 DB mengalami shutdown yang bersih.](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) Ini memastikan bahwa semua transaksi dilakukan atau dibatalkan, dan bahwa InnoDB telah membersihkan semua catatan log undo.
Jika cluster DB Anda memiliki panjang daftar riwayat segmen rollback (HLL) yang tinggi, itu dapat memperpanjang jumlah waktu yang dibutuhkan InnoDB untuk menyelesaikan pembersihan catatan log batal, yang menyebabkan waktu henti yang diperpanjang selama proses peningkatan versi utama. Jika precheck mendeteksi bahwa HLL pada cluster DB Anda tinggi, itu menimbulkan peringatan. Meskipun ini tidak menghalangi peningkatan Anda untuk melanjutkan, kami sarankan Anda memantau HLL di cluster DB Anda dengan cermat. Menjaga pada tingkat rendah mengurangi waktu henti yang diperlukan selama peningkatan versi utama. Untuk informasi lebih lanjut tentang pemantauan HLL, lihat[Panjang daftar riwayat InnoDB meningkat secara signifikan](proactive-insights.history-list.md).
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
"title": "Checks if the rollback segment history length for the cluster is high",
"status": "OK",
"description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_metrics",
"description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
}
]
}
```
Precheck mengembalikan peringatan karena mendeteksi InnoDB undo HLL tinggi pada cluster database (82989114). Meskipun upgrade berlangsung, tergantung pada jumlah undo untuk membersihkan, itu dapat memperpanjang downtime yang diperlukan selama proses upgrade.
Kami menyarankan Anda [menyelidiki transaksi terbuka](proactive-insights.history-list.md) pada cluster DB Anda sebelum menjalankan upgrade dalam produksi, untuk memastikan HLL Anda disimpan pada ukuran yang dapat dikelola.
**auroraUpgradeCheckForUncommittedRowModifications**
**Tingkat precheck: Peringatan**
**Memeriksa apakah ada banyak modifikasi baris yang tidak berkomitmen**
[Seperti disebutkan dalam [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), saat menjalankan proses peningkatan versi utama, penting bahwa instance Aurora MySQL versi 2 DB mengalami shutdown yang bersih.](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) Ini memastikan bahwa semua transaksi dilakukan atau dibatalkan, dan bahwa InnoDB telah membersihkan semua catatan log undo.
Jika cluster DB Anda memiliki transaksi yang telah memodifikasi sejumlah besar baris, itu dapat memperpanjang jumlah waktu yang dibutuhkan InnoDB untuk menyelesaikan rollback transaksi ini sebagai bagian dari proses shutdown bersih. Jika precheck menemukan transaksi yang berjalan lama, dengan sejumlah besar baris yang dimodifikasi pada cluster DB Anda, itu menimbulkan peringatan. Meskipun ini tidak menghalangi peningkatan Anda untuk melanjutkan, kami sarankan Anda memantau dengan cermat ukuran transaksi aktif di cluster DB Anda. Menjaga pada tingkat rendah mengurangi waktu henti yang diperlukan selama peningkatan versi utama.
**Contoh keluaran:**
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_trx",
"description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
}
]
},
```
Precheck melaporkan bahwa cluster DB berisi transaksi dengan 11.000.000 perubahan baris tanpa komitmen yang perlu dibatalkan selama proses shutdown bersih. Upgrade akan dilanjutkan, tetapi untuk mengurangi downtime selama proses upgrade, kami sarankan Anda memantau dan menyelidiki ini sebelum menjalankan upgrade pada cluster produksi Anda.
Untuk melihat transaksi aktif pada instance DB penulis Anda, Anda dapat menggunakan tabel [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html). Kueri berikut pada instance DB penulis menunjukkan transaksi saat ini, waktu berjalan, status, dan baris yang dimodifikasi untuk cluster DB.
```
# Example of uncommitted transaction
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 | 1592 | 20041 | 52866130 | RUNNING | 11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)
# Example of transaction rolling back
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 | 1719 | 20041 | 52866130 | ROLLING BACK | 10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)
```
Setelah transaksi dilakukan atau dibatalkan, precheck tidak lagi mengembalikan peringatan. Konsultasikan dokumentasi MySQL dan tim aplikasi Anda sebelum mengembalikan transaksi besar apa pun, karena rollback dapat memakan waktu untuk diselesaikan, tergantung pada ukuran transaksi.
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
Untuk informasi selengkapnya tentang mengoptimalkan manajemen transaksi InnoDB, dan dampak potensial dari menjalankan dan mengembalikan transaksi besar pada instance database MySQL, lihat [Mengoptimalkan manajemen transaksi InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) dalam dokumentasi MySQL.
## Pemberitahuan
Precheck berikut menghasilkan pemberitahuan ketika precheck gagal, tetapi upgrade dapat dilanjutkan.
**sqlModeFlagMemeriksa**
**Tingkat precheck: Pemberitahuan**
**Penggunaan bendera usang `sql_mode`**
Selain itu`MAXDB`, sejumlah `sql_mode` opsi lain telah [dihapus](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html):`DB2`,,`MSSQL`,`MYSQL323`,`MYSQL40`,`ORACLE`,`POSTGRESQL`, `NO_FIELD_OPTIONS``NO_KEY_OPTIONS`, dan`NO_TABLE_OPTIONS`. Pada MySQL 8.0, tidak satu pun dari nilai-nilai ini dapat ditetapkan ke variabel sistem. `sql_mode` [Jika precheck ini menemukan sesi terbuka menggunakan `sql_mode` pengaturan ini, pastikan bahwa instans DB dan grup parameter cluster DB Anda, serta aplikasi dan konfigurasi klien, diperbarui untuk menonaktifkannya.- Untuk informasi lebih lanjut, lihat dokumentasi MySQL.](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)
**Contoh keluaran:**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
Untuk mengatasi salah satu kegagalan precheck ini, lihat [maxdbFlagCheck](#maxdbFlagCheck).
## Kesalahan, peringatan, atau pemberitahuan
Precheck berikut dapat mengembalikan kesalahan, peringatan, atau pemberitahuan tergantung pada output precheck.
**checkTableOutput**
**Tingkat precheck: Kesalahan, Peringatan, atau Pemberitahuan**
**Masalah yang dilaporkan oleh `check table x for upgrade` perintah**
Sebelum memulai upgrade ke Aurora MySQL versi 3, `check table for upgrade` dijalankan pada setiap tabel dalam skema pengguna di cluster DB Anda. Precheck ini tidak sama dengan [checkTableMysqlSchema](#checkTableMysqlSchema).
`check table for upgrade`Perintah memeriksa tabel untuk setiap potensi masalah yang mungkin timbul selama upgrade ke versi MySQL yang lebih baru. Menjalankan perintah ini sebelum mencoba upgrade dapat membantu mengidentifikasi dan menyelesaikan ketidakcocokan sebelumnya, membuat proses upgrade yang sebenarnya lebih lancar.
Perintah ini melakukan berbagai pemeriksaan pada setiap tabel, seperti berikut ini:
+ Memverifikasi bahwa struktur tabel dan metadata kompatibel dengan versi MySQL target
+ Memeriksa fitur yang tidak digunakan lagi atau dihapus yang digunakan oleh tabel
+ Memastikan bahwa tabel dapat ditingkatkan dengan benar tanpa kehilangan data
Tidak seperti prechecks lainnya, ini dapat mengembalikan kesalahan, peringatan, atau pemberitahuan tergantung pada `check table` output. Jika precheck ini mengembalikan tabel apa pun, tinjau dengan cermat, bersama dengan kode pengembalian dan pesan sebelum memulai pemutakhiran. Untuk informasi selengkapnya, lihat [pernyataan CHECK TABLE](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) dalam dokumentasi MySQL.
Di sini kami memberikan contoh kesalahan dan contoh peringatan.
**Contoh kesalahan:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.parent",
"description": "Table 'test.parent' doesn't exist"
}
]
},
```
Precheck melaporkan kesalahan bahwa `test.parent` tabel tidak ada.
`mysql-error.log`File untuk instance DB penulis menunjukkan bahwa ada kesalahan kunci asing.
```
2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
```
Masuk ke instans DB penulis dan jalankan `show engine innodb status\G` untuk mendapatkan informasi lebih lanjut tentang kesalahan kunci asing.
```
mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.
```
`LATEST FOREIGN KEY ERROR`Pesan melaporkan bahwa kendala kunci `fk_pname` asing dalam `test.child` tabel, yang mereferensikan `test.parent` tabel, memiliki indeks yang hilang atau ketidakcocokan tipe data. Dokumentasi MySQL [pada batasan kunci asing](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) menyatakan bahwa kolom yang direferensikan dalam kunci asing harus memiliki indeks terkait, dan kolom harus menggunakan tipe data yang parent/child sama.
[Untuk memverifikasi apakah ini terkait dengan ketidakcocokan indeks atau tipe data yang hilang, masuk ke database dan periksa definisi tabel dengan menonaktifkan sementara variabel sesi foreign\$1key\$1checks.](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks) Setelah melakukannya, kita dapat melihat bahwa batasan anak di question (`fk_pname`) digunakan `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` untuk mereferensikan tabel induk. `name varchar(20) NOT NULL` Tabel induk menggunakan`DEFAULT CHARSET=utf8`, tetapi `p_name` kolom tabel anak menggunakan`latin1`, sehingga kesalahan ketidakcocokan tipe data dilemparkan.
```
mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)
mysql> show create table parent\G
*************************** 1. row ***************************
Table: parent
Create Table: CREATE TABLE `parent` (
`name` varchar(20) NOT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Untuk mengatasi masalah ini, kita dapat mengubah tabel anak untuk menggunakan set karakter yang sama dengan induk, atau mengubah induk untuk menggunakan set karakter yang sama dengan tabel anak. Di sini, karena tabel anak secara eksplisit menggunakan `latin1` dalam definisi `p_name` kolom, kami menjalankan `ALTER TABLE` untuk memodifikasi set karakter ke. `utf8`
```
mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)
```
Setelah melakukannya, precheck berlalu, dan peningkatan dapat dilanjutkan.
**Contoh peringatan:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.orders",
"description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
}
]
}
```
Precheck melaporkan peringatan untuk `delete_audit_trigg` pemicu di `test.orders` atas meja karena tidak memiliki `CREATED` atribut. Menurut [Memeriksa kompatibilitas versi](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility) dalam dokumentasi MySQL, pesan ini bersifat informasi, dan dicetak untuk pemicu yang dibuat sebelum MySQL 5.7.2.
Karena ini adalah peringatan, itu tidak menghalangi peningkatan untuk melanjutkan. Namun, jika Anda ingin menyelesaikan masalah, Anda dapat membuat ulang pemicu yang dimaksud, dan precheck berhasil tanpa peringatan.
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# Cara melakukan peningkatan di tempat
Sebaiknya Anda meninjau materi latar belakang dalam [Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence).
Lakukan perencanaan dan pengujian pra-upgrade, seperti yang dijelaskan dalam[Merencanakan peningkatan versi mayor untuk klaster Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning).
## Konsol
Contoh berikut meningkatkan cluster `mydbcluster-cluster` DB ke Aurora MySQL versi 3.04.1.
**Untuk meningkatkan versi mayor klaster DB Aurora MySQL**
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. Jika Anda menggunakan grup parameter kustom untuk klaster DB asli, buat grup parameter terkait yang kompatibel dengan versi mayor baru. Buat penyesuaian yang diperlukan untuk parameter konfigurasi di grup parameter baru tersebut. Untuk informasi selengkapnya, lihat [Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster](#AuroraMySQL.Upgrading.ParamGroups).
1. Di panel navigasi, pilih **Basis Data**.
1. Dalam daftar, pilih klaster DB yang ingin Anda ubah.
1. Pilih **Ubah**.
1. Untuk **Versi**, pilih versi mayor Aurora MySQL baru.
Biasanya, kami merekomendasikan untuk menggunakan versi minor terbaru dari versi mayor. Di sini, kami memilih versi default saat ini.
![\[Peningkatan di tempat terhadap klaster DB Aurora MySQL dari versi 2 ke versi 3\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Pilih **Lanjutkan**.
1. Di halaman berikutnya, tentukan kapan harus melakukan peningkatan. Pilih **Selama jendela pemeliharaan terjadwal berikutnya** atau **Segera**.
1. (Opsional) Periksa secara berkala halaman **Peristiwa** di konsol RDS selama peningkatan. Tindakan ini akan membantu Anda memantau progres peningkatan dan identifikasi masalah apa pun. Jika peningkatan mengalami masalah apa pun, lihat [Pemecahan masalah untuk Aurora Peningkatan di tempat saya SQL](AuroraMySQL.Upgrading.Troubleshooting.md) untuk langkah-langkah yang harus diambil.
1. Jika Anda membuat grup parameter baru di awal prosedur ini, kaitkan grup parameter kustom dengan klaster yang ditingkatkan. Untuk informasi selengkapnya, lihat [Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster](#AuroraMySQL.Upgrading.ParamGroups).
**catatan**
Langkah ini mengharuskan Anda untuk memulai ulang klaster lagi untuk menerapkan grup parameter baru.
1. (Opsional) Setelah Anda menyelesaikan setiap pengujian pasca-peningkatan, hapus snapshot manual yang dibuat Aurora pada awal peningkatan.
## AWS CLI
Untuk memutakhirkan versi utama cluster DB MySQL Aurora, gunakan AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)perintah dengan parameter yang diperlukan berikut:
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` atau `--no-apply-immediately`
Jika klaster Anda menggunakan grup parameter kustom, sertakan juga salah satu atau kedua opsi berikut ini:
+ `--db-cluster-parameter-group-name`, jika klaster menggunakan grup parameter klaster kustom
+ `--db-instance-parameter-group-name`, jika ada instans di klaster yang menggunakan grup parameter DB kustom
Contoh berikut meningkatkan cluster `sample-cluster` DB ke Aurora MySQL versi 3.04.1. Peningkatan akan segera terjadi, bukan menunggu periode pemeliharaan berikutnya.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Untuk Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
Anda dapat menggabungkan perintah CLI lainnya `modify-db-cluster` untuk membuat end-to-end proses otomatis untuk melakukan dan memverifikasi peningkatan. Untuk informasi selengkapnya dan contoh tambahan, lihat [Aurora Tutorial peningkatan di tempat SQL saya](AuroraMySQL.Upgrading.Tutorial.md).
**catatan**
Jika klaster Anda adalah bagian dari basis data global Aurora, prosedur peningkatan di tempat ini sedikit berbeda. Anda memanggil operasi [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html)perintah alih-alih`modify-db-cluster`. Untuk informasi selengkapnya, lihat [Peningkatan besar di tempat untuk basis data global](#AuroraMySQL.Upgrading.GlobalDB).
## API RDS
[Untuk memutakhirkan versi utama cluster DB MySQL Aurora, gunakan operasi RDS API Modify dengan parameter yang diperlukan berikut: DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (atur ke `true` atau `false`)
**catatan**
Jika klaster Anda adalah bagian dari basis data global Aurora, prosedur peningkatan di tempat ini sedikit berbeda. Anda memanggil [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html)operasi alih-alih`ModifyDBCluster`. Untuk informasi selengkapnya, lihat [Peningkatan besar di tempat untuk basis data global](#AuroraMySQL.Upgrading.GlobalDB).
## Bagaimana peningkatan di tempat memengaruhi grup parameter untuk klaster
Grup parameter Aurora memiliki kumpulan pengaturan konfigurasi yang berbeda untuk klaster yang kompatibel dengan MySQL 5.7 atau 8.0. Saat Anda melakukan peningkatan di tempat, klaster yang ditingkatkan dan semua instans harus menggunakan grup parameter klaster dan instans yang sesuai:
Klaster dan instans Anda mungkin menggunakan grup parameter default yang kompatibel dengan 5.7. Jika demikian, klaster dan instans yang ditingkatkan akan dimulai dengan grup parameter default yang kompatibel dengan 8.0. Jika klaster dan instans Anda menggunakan grup parameter kustom apa pun, pastikan untuk membuat grup parameter yang sesuai atau yang kompatibel dengan 8.0. Pastikan juga untuk menentukannya selama proses peningkatan.
**catatan**
Untuk sebagian besar pengaturan parameter, Anda dapat memilih grup parameter kustom di dua titik. Titik ini adalah saat Anda membuat klaster atau mengaitkan grup parameter dengan klaster nanti.
Namun, jika Anda menggunakan pengaturan nondefault untuk parameter `lower_case_table_names`, Anda harus mengatur grup parameter kustom dengan pengaturan ini terlebih dahulu. Kemudian, tentukan grup parameter saat Anda melakukan pemulihan snapshot untuk membuat klaster. Setiap perubahan pada parameter `lower_case_table_names` tidak akan berpengaruh setelah klaster dibuat.
Kami menyarankan Anda menggunakan pengaturan yang sama untuk `lower_case_table_names` ketika Anda meningkatkan dari Aurora MySQL versi 2 ke versi 3.
Dengan database global Aurora berdasarkan Aurora MySQL, Anda dapat melakukan peningkatan di tempat dari Aurora MySQL versi 2 ke versi 3 hanya jika Anda mengatur parameter ke default dan me-reboot database global Anda. `lower_case_table_names` Untuk informasi selengkapnya tentang metode yang dapat Anda gunakan, lihat [Peningkatan versi utama](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
## Perubahan pada properti klaster di antara versi Aurora MySQL
Saat Anda meningkatkan dari Aurora MySQL versi 2 ke versi 3, pastikan untuk memeriksa aplikasi atau skrip apa pun yang Anda gunakan untuk menyiapkan atau mengelola klaster dan instans DB Aurora MySQL.
Selain itu, ubah kode Anda yang memanipulasi grup parameter untuk memperhitungkan fakta bahwa nama grup parameter default berbeda untuk klaster yang kompatibel dengan 5.7 dan 8.0. Nama grup parameter default untuk klaster Aurora MySQL versi 2 dan 3 masing-masing adalah `default.aurora-mysql5.7` dan `default.aurora-mysql8.0`.
Misalnya, Anda mungkin memiliki kode seperti berikut yang berlaku untuk klaster Anda sebelum peningkatan.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Setelah meningkatkan versi mayor klaster, ubah kode tersebut sebagai berikut.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## Peningkatan besar di tempat untuk basis data global
Untuk basis data global Aurora, Anda meningkatkan klaster basis data global. Aurora secara otomatis meningkatkan semua klaster pada saat yang sama dan memastikan bahwa semua klaster ini menjalankan versi mesin yang sama. Persyaratan ini berlaku karena setiap perubahan pada tabel sistem, format file data, dan sebagainya akan secara otomatis direplikasi ke semua klaster sekunder.
Ikuti petunjuk dalam [Cara kerja peningkatan di tempat terhadap versi mayor Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Saat Anda menentukan hal yang akan ditingkatkan, pastikan untuk memilih klaster basis data global, bukan salah satu klaster yang terdapat di dalamnya.
Jika Anda menggunakan Konsol Manajemen AWS, pilih item dengan peran **Database global**.
![\[Meningkatkan klaster basis data global\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Jika Anda menggunakan AWS CLI atau RDS API, mulai proses upgrade dengan memanggil [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html)perintah atau [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html)operasi. Anda akan menggunakan salah satunya, bukan `modify-db-cluster` atau `ModifyDBCluster`.
**catatan**
Anda tidak dapat menentukan grup parameter kustom untuk klaster basis data global saat Anda melakukan peningkatan versi mayor basis data global Aurora tersebut. Buat grup parameter kustom Anda di setiap Wilayah klaster global. Kemudian, terapkan secara manual ke klaster Regional setelah peningkatan.
Untuk meng-upgrade versi utama dari sebuah cluster database global MySQL Aurora dengan menggunakan AWS CLI, gunakan [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html)perintah dengan parameter yang diperlukan berikut:
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
Contoh berikut meningkatkan cluster database global ke Aurora MySQL versi 3.04.2.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.2 \
--allow-major-version-upgrade
```
Untuk Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.04.2 ^
--allow-major-version-upgrade
```
## Upgrade di tempat untuk cluster DB dengan replika baca lintas wilayah
Anda dapat memutakhirkan cluster Aurora DB yang memiliki replika baca lintas wilayah menggunakan prosedur peningkatan di tempat, tetapi ada pertimbangan tertentu:
+ Anda harus memutakhirkan cluster DB replika baca terlebih dahulu. Jika Anda mencoba memutakhirkan klaster utama terlebih dahulu, Anda akan menerima pesan kesalahan seperti berikut ini:
Tidak dapat memutakhirkan cluster DB test-xr-primary-cluster karena replika Aurora Cross-region terkait test-xr-replica-cluster belum ditambal. Tingkatkan replika Aurora Cross-region dan coba lagi.
Ini berarti bahwa cluster DB primer tidak dapat memiliki versi mesin DB yang lebih tinggi daripada cluster replika.
+ Sebelum Anda memutakhirkan cluster DB primer, hentikan beban kerja tulis dan nonaktifkan permintaan koneksi baru apa pun ke instance DB penulis dari cluster utama.
+ Saat Anda memutakhirkan klaster utama, pilih grup parameter cluster DB kustom dengan `binlog_format` parameter yang disetel ke nilai yang mendukung replikasi logging biner, seperti`MIXED`.
Untuk informasi selengkapnya tentang menggunakan pencatatan log biner dengan Aurora MySQL, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). Untuk informasi selengkapnya tentang memodifikasi parameter konfigurasi Aurora MySQL, lihat [Parameter konfigurasi Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) dan [](USER_WorkingWithParamGroups.md).
+ Jangan menunggu lama untuk memutakhirkan cluster DB utama setelah Anda memutakhirkan cluster replika. Kami menyarankan untuk tidak menunggu lebih lama dari jendela pemeliharaan berikutnya.
+ Setelah Anda memutakhirkan cluster DB primer, reboot instance DB penulisnya. Grup parameter cluster DB kustom yang memungkinkan replikasi binlog tidak berlaku sampai instance DB penulis di-boot ulang.
+ Jangan melanjutkan beban kerja tulis atau mengaktifkan koneksi ke instans DB penulis sampai Anda mengonfirmasi bahwa replikasi lintas wilayah telah dimulai ulang, dan bahwa jeda replika di sekunder adalah 0. Wilayah AWS
# Aurora Tutorial peningkatan di tempat SQL saya
Contoh Linux berikut menunjukkan cara Anda dapat melakukan langkah-langkah umum untuk prosedur peningkatan di tempat menggunakan AWS CLI.
Contoh pertama ini membuat cluster Aurora DB yang menjalankan Aurora My versi 2.x. SQL Klaster ini mencakup instans DB penulis dan instans DB pembaca. Perintah `wait db-instance-available` dijeda hingga instans DB penulis tersedia. Pada saat itulah, klaster siap untuk ditingkatkan.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Versi Aurora My SQL 3.x yang dapat Anda tingkatkan cluster agar bergantung pada versi 2.x yang sedang dijalankan cluster dan di Wilayah AWS mana cluster berada. Perintah pertama, dengan `--output text`, hanya menunjukkan versi target yang tersedia. Perintah kedua menunjukkan JSON output penuh dari respons. Dalam respons tersebut, Anda dapat melihat detail seperti nilai `aurora-mysql` yang Anda gunakan untuk parameter `engine`. Anda juga dapat melihat fakta bahwa memutakhirkan ke 3.04.0 merupakan peningkatan versi utama.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
Contoh ini menunjukkan bahwa jika Anda memasukkan nomor versi target yang bukan merupakan target peningkatan yang valid untuk klaster, Aurora tidak akan melakukan peningkatan. Aurora juga tidak melakukan peningkatan versi mayor kecuali jika Anda menyertakan parameter `--allow-major-version-upgrade`. Dengan demikian, Anda tidak dapat tanpa disengaja melakukan peningkatan yang berpotensi akan memerlukan pengujian dan perubahan ekstensif terhadap kode aplikasi Anda.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
Dibutuhkan beberapa saat hingga status klaster dan instans DB terkait berubah menjadi `upgrading`. Nomor versi untuk klaster dan instans DB hanya berubah saat peningkatan selesai. Sekali lagi, Anda dapat menggunakan perintah `wait db-instance-available` untuk instans DB penulis untuk menunggu hingga peningkatan selesai sebelum melanjutkan.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Pada tahap ini, nomor versi untuk klaster akan cocok dengan nomor versi yang ditentukan untuk peningkatan.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
Contoh sebelumnya melakukan peningkatan langsung dengan menentukan parameter `--apply-immediately`. Agar peningkatan terjadi pada waktu yang tepat saat klaster diperkirakan tidak sibuk, Anda dapat menentukan parameter `--no-apply-immediately`. Tindakan ini akan membuat peningkatan dimulai selama periode pemeliharaan berikutnya untuk klaster. Periode pemeliharaan menentukan periode saat operasi pemeliharaan dapat dimulai. Operasi yang berjalan lama mungkin tidak selesai selama periode pemeliharaan. Dengan demikian, Anda tidak perlu menentukan periode pemeliharaan yang lebih panjang bahkan jika Anda memperkirakan bahwa peningkatan mungkin akan memakan waktu lama.
Contoh berikut memutakhirkan cluster yang awalnya menjalankan Aurora SQL My versi 2.11.2. Dalam output `describe-db-engine-versions`, nilai `False` dan `True` merepresentasikan properti `IsMajorVersionUpgrade`. Dari versi 2.11.2, Anda dapat meningkatkan ke beberapa versi 2.\$1 lainnya. Peningkatan tersebut tidak dianggap sebagai peningkatan versi mayor sehingga tidak memerlukan peningkatan di tempat. Peningkatan di tempat hanya tersedia untuk peningkatan ke versi 3.\$1 yang ditampilkan dalam daftar.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
Ketika sebuah klaster dibuat tanpa periode pemeliharaan yang ditentukan, Aurora akan memilih hari acak dalam seminggu. Dalam hal ini, perintah `modify-db-cluster` dikirimkan pada hari Senin. Dengan demikian, kita mengubah periode pemeliharaan menjadi Selasa pagi. Semua waktu diwakili dalam zona UTC waktu. Periode `tue:10:00-tue:10:30` sama dengan 02.00-02.30 waktu Pasifik. Perubahan periode pemeliharaan akan langsung berlaku.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
Contoh berikut menunjukkan cara mendapatkan laporan dari peristiwa yang dihasilkan oleh peningkatan. Argumen `--duration` merepresentasikan jumlah menit untuk mengambil informasi peristiwa. Argumen ini diperlukan, karena secara default `describe-events` hanya mengembalikan peristiwa dari jam terakhir.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Menemukan alasan Aurora Kegagalan peningkatan versi SQL utama saya
Dalam [tutorial](AuroraMySQL.Upgrading.Tutorial.md), upgrade dari Aurora My SQL versi 2 ke versi 3 berhasil. Tetapi jika pemutakhiran gagal, Anda pasti ingin tahu alasannya.
Anda dapat mulai dengan menggunakan `describe-events` AWS CLI perintah untuk melihat peristiwa cluster DB. Contoh ini menunjukkan peristiwa `mydbcluster` selama 10 jam terakhir.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
Dalam hal ini, kami mengalami kegagalan precheck upgrade.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
Untuk mendiagnosis penyebab pasti masalah, periksa log database untuk instance DB penulis. Ketika upgrade ke Aurora My SQL version 3 gagal, instance writer berisi file log dengan nama. `upgrade-prechecks.log` Contoh ini menunjukkan cara mendeteksi keberadaan log tersebut lalu mengunduhnya ke file lokal untuk diperiksa.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
`upgrade-prechecks.log`File dalam JSON format. Kami mengunduhnya menggunakan `--output text` opsi untuk menghindari pengkodean JSON output dalam JSON pembungkus lain. Untuk upgrade Aurora My SQL versi 3, log ini selalu menyertakan pesan informasi dan peringatan tertentu. Log ini hanya berisi pesan kesalahan jika peningkatan gagal. Jika peningkatan berhasil, file log tidak dibuat sama sekali.
Untuk meringkas semua kesalahan dan menampilkan bidang objek dan deskripsi terkait, Anda dapat menjalankan perintah `grep -A 2 '"level": "Error"'` pada isi `upgrade-prechecks.log` file. Tindakan ini akan menampilkan setiap baris kesalahan dan dua baris setelahnya. Baris ini berisi nama objek basis data yang sesuai dan panduan tentang cara memperbaiki masalahnya.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
Dalam contoh ini, Anda dapat menjalankan SQL perintah berikut pada tabel yang menyinggung untuk mencoba memperbaiki masalah, atau Anda dapat membuat ulang tabel tanpa indeks yang menggantung.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
Kemudian coba lagi upgrade.
# Pemecahan masalah untuk Aurora Peningkatan di tempat saya SQL
Gunakan tips berikut untuk membantu memecahkan masalah dengan peningkatan Aurora My in-place. SQL Tips ini tidak berlaku untuk Aurora Serverless klaster DB.
| Alasan peningkatan di tempat dibatalkan atau lambat | Efek | Solusi untuk memungkinkan peningkatan di tempat selesai dalam periode pemeliharaan |
| --- | --- | --- |
| Replika Lintas wilayah Aurora Terkait belum ditambal | Aurora membatalkan peningkatan. | Tingkatkan replika Aurora Cross-region dan coba lagi. |
| Klaster memiliki transaksi XA dalam status siap | Aurora membatalkan peningkatan. | Komit atau kembalikan semua transaksi XA yang disiapkan. |
| Cluster memproses pernyataan bahasa definisi data (DDL) apa pun | Aurora membatalkan peningkatan. | Pertimbangkan untuk menunggu dan melakukan peningkatan setelah semua DDL pernyataan selesai. |
| Klaster memiliki perubahan yang tidak dikomit untuk banyak baris | Peningkatan mungkin memerlukan waktu lama. | Proses peningkatan mengembalikan perubahan yang tidak dikomit. Indikator untuk kondisi ini adalah nilai `TRX_ROWS_MODIFIED` dalam tabel `INFORMATION_SCHEMA.INNODB_TRX`. Pertimbangkan untuk melakukan peningkatan hanya setelah semua transaksi besar dilakukan atau dikembalikan. |
| Klaster memiliki jumlah catatan undo yang tinggi | Peningkatan mungkin memerlukan waktu lama. | Bahkan jika transaksi yang tidak dikomit tidak memengaruhi sejumlah besar baris, transaksi ini mungkin berkaitan dengan volume besar data. Misalnya, Anda mungkin memasukkan besarBLOBs. Aurora tidak akan secara otomatis mendeteksi atau menghasilkan peristiwa untuk jenis aktivitas transaksi ini. Indikator untuk kondisi ini adalah panjang daftar riwayat (HLL). Proses peningkatan mengembalikan perubahan yang tidak dikomit. Anda dapat memeriksa HLL output dari `SHOW ENGINE INNODB STATUS` SQL perintah, atau langsung dengan menggunakan SQL query berikut: SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
Anda juga dapat memantau `RollbackSegmentHistoryListLength` metrik di Amazon CloudWatch. Pertimbangkan untuk melakukan upgrade hanya setelah HLL lebih kecil. |
| Klaster sedang dalam proses melakukan komit transaksi log biner besar | Peningkatan mungkin memerlukan waktu lama. | Proses peningkatan menunggu sampai perubahan log biner diterapkan. Lebih banyak transaksi atau DDL pernyataan dapat dimulai selama periode ini, yang selanjutnya memperlambat proses peningkatan. Jadwalkan proses peningkatan saat klaster tidak sibuk menghasilkan perubahan replikasi log biner. Aurora tidak akan secara otomatis mendeteksi atau membuat peristiwa untuk kondisi ini. |
| Inkonsistensi skema yang dihasilkan dari penghapusan atau kerusakan file | Aurora membatalkan peningkatan. | Ubah mesin penyimpanan default untuk tabel sementara dari My ISAM ke InnoDB. Lakukan langkah-langkah berikut ini: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| Pengguna master dihapus | Aurora membatalkan peningkatan. | Jangan hapus pengguna master. Namun, jika karena alasan tertentu Anda kebetulan menghapus pengguna master, kembalikan menggunakan SQL perintah berikut: CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
Untuk detail selengkapnya tentang masalah pemecahan masalah yang menyebabkan precheck upgrade gagal, lihat blog berikut:
+ [Amazon Aurora SQL Versi saya 2 (dengan kompatibilitas SQL 5.7 Saya) ke versi 3 (dengan kompatibilitas SQL 8.0 Saya) daftar periksa pemutakhiran, Bagian 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Amazon Aurora SQL Versi saya 2 (dengan kompatibilitas SQL 5.7 Saya) ke versi 3 (dengan kompatibilitas SQL 8.0 Saya) daftar periksa pemutakhiran, Bagian 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
Anda dapat menggunakan langkah-langkah berikut untuk melakukan pemeriksaan Anda sendiri untuk beberapa kondisi di tabel sebelumnya. Dengan demikian, Anda dapat menjadwalkan peningkatan pada saat Anda mengetahui basis data dalam keadaan yang memungkinkan peningkatan berhasil diselesaikan dengan cepat.
+ Anda dapat memeriksa transaksi XA terbuka dengan menjalankan pernyataan `XA RECOVER`. Anda kemudian dapat meng-commit atau mengembalikan transaksi XA sebelum memulai peningkatan.
+ Anda dapat memeriksa DDL pernyataan dengan mengeksekusi `SHOW PROCESSLIST` pernyataan dan mencari`CREATE`,,`DROP`, `ALTER``RENAME`, dan `TRUNCATE` pernyataan dalam output. Izinkan semua DDL pernyataan selesai sebelum memulai peningkatan.
+ Anda dapat memeriksa jumlah total baris yang tidak dikomit dengan mengueri tabel `INFORMATION_SCHEMA.INNODB_TRX`. Tabel ini berisi satu baris untuk setiap transaksi. Kolom `TRX_ROWS_MODIFIED` berisi jumlah baris yang diubah atau dimasukkan oleh transaksi.
+ Anda dapat memeriksa panjang daftar riwayat InnoDB dengan menjalankan pernyataan `SHOW ENGINE INNODB STATUS SQL` dan mencari `History list length` dalam output. Anda juga dapat memeriksa nilai secara langsung dengan menjalankan kueri berikut:
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
Panjang daftar riwayat sesuai dengan jumlah informasi undo yang disimpan oleh database untuk menerapkan kontrol konkurensi multi-versi (). MVCC
# Pembersihan pasca-upgrade untuk Aurora Versi saya 3 SQL
Setelah Anda selesai memutakhirkan klaster Aurora SQL My version 2 ke SQL Aurora My version 3, Anda dapat melakukan tindakan pembersihan lainnya:
+ Buat versi baru yang SQL kompatibel dengan My 8.0 dari grup parameter kustom apa pun. Terapkan nilai parameter kustom yang diperlukan ke grup parameter baru.
+ Perbarui CloudWatch alarm, skrip penyiapan, dan sebagainya untuk menggunakan nama baru untuk metrik apa pun yang namanya dipengaruhi oleh perubahan bahasa inklusif. Untuk daftar metrik tersebut, lihat [Perubahan bahasa inklusif untuk Aurora Versi saya 3 SQL](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
+ Perbarui apa saja CloudFormation template untuk menggunakan nama baru untuk parameter konfigurasi apa pun yang namanya dipengaruhi oleh perubahan bahasa inklusif. Untuk daftar parameter tersebut, lihat [Perubahan bahasa inklusif untuk Aurora Versi saya 3 SQL](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## Indeks spasial
Setelah memutakhirkan ke Aurora SQL My versi 3, periksa apakah Anda perlu menjatuhkan atau membuat ulang objek dan indeks yang terkait dengan indeks spasial. Sebelum My SQL 8.0, Aurora dapat mengoptimalkan kueri spasial menggunakan indeks yang tidak berisi pengenal sumber daya spasial (). SRID Aurora SQL Versi saya 3 hanya menggunakan indeks spasial yang berisi. SRIDs Selama peningkatan, Aurora secara otomatis menjatuhkan indeks spasial apa pun tanpa SRIDs dan mencetak pesan peringatan di log database. Jika Anda mengamati pesan peringatan tersebut, buat indeks spasial baru SRIDs setelah pemutakhiran. Untuk informasi selengkapnya tentang perubahan fungsi spasial dan tipe data di My SQL 8.0, lihat [Perubahan pada SQL 8.0 Saya di Manual SQL](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) *Referensi Saya*.
# Pembaruan dan perbaikan mesin database untuk Amazon Aurora MySQL
Anda dapat menemukan informasi berikut di *Catatan rilis untuk Amazon Aurora Edisi yang kompatibel dengan MySQL*:
+ [Pembaruan mesin database untuk Amazon Aurora MySQL versi 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)
+ [Pembaruan mesin database untuk Amazon Aurora MySQL versi 2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html)
+ [Pembaruan mesin database untuk Amazon Aurora MySQL versi 1 (Usang)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.11Updates.html)
+ [Bug MySQL diperbaiki oleh pembaruan mesin database Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.MySQLBugs.html)
+ [Kerentanan keamanan diperbaiki di Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.CVE_list.html)