Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Referensi deskripsi precheck untuk Aurora MySQL
Pra-cek pemutakhiran untuk Aurora MySQL dijelaskan di sini secara rinci.
**Contents**
+ [Kesalahan](#precheck-descriptions-errors)
+ [MySQL memeriksa sebelumnya yang melaporkan kesalahan](#precheck-descriptions-errors.mysql)
+ [Aurora MySQL memeriksa sebelumnya yang melaporkan kesalahan](#precheck-descriptions-errors.aurora)
+ [Peringatan](#precheck-descriptions-warnings)
+ [MySQL memeriksa sebelumnya yang melaporkan peringatan](#precheck-descriptions-warnings.mysql)
+ [Aurora MySQL mengecek peringatan laporan itu](#precheck-descriptions-warnings.aurora)
+ [Pemberitahuan](#precheck-descriptions-notices)
+ [Kesalahan, peringatan, atau pemberitahuan](#precheck-descriptions-all)
## Kesalahan
Prececks berikut menghasilkan kesalahan saat precheck gagal, dan pemutakhiran tidak dapat dilanjutkan.
**Topics**
+ [MySQL memeriksa sebelumnya yang melaporkan kesalahan](#precheck-descriptions-errors.mysql)
+ [Aurora MySQL memeriksa sebelumnya yang melaporkan kesalahan](#precheck-descriptions-errors.aurora)
### MySQL memeriksa sebelumnya yang melaporkan kesalahan
Precheck berikut berasal dari MySQL Komunitas:
+ [checkTableMysqlSkema](#checkTableMysqlSchema)
+ [circularDirectoryCheck](#circularDirectoryCheck)
+ [columnsWhichCannotHaveDefaultsCheck](#columnsWhichCannotHaveDefaultsCheck)
+ [depreciatedSyntaxCheck](#depreciatedSyntaxCheck)
+ [engineMixupCheck](#engineMixupCheck)
+ [enumSetElementLengthCheck](#enumSetElementLengthCheck)
+ [foreignKeyLengthMemeriksa](#foreignKeyLengthCheck)
+ [getDuplicateTriggers](#getDuplicateTriggers)
+ [getEventsWithNullDefiner](#getEventsWithNullDefiner)
+ [getMismatchedMetadata](#getMismatchedMetadata)
+ [getTriggersWithNullDefiner](#getTriggersWithNullDefiner)
+ [getValueOfVariableLower\_case\_table\_names](#getValueOfVariable)
+ [groupByAscSyntaxCheck](#groupByAscSyntaxCheck)
+ [mysqlEmptyDotTableSyntaxCheck](#mysqlEmptyDotTableSyntaxCheck)
+ [mysqlIndexTooLargeCheck](#mysqlIndexTooLargeCheck)
+ [MySQLinkValid57 NamesCheck](#mysqlInvalid57NamesCheck)
+ [mysqlOrphanedRoutinesMemeriksa](#mysqlOrphanedRoutinesCheck)
+ [mysqlSchemaCheck](#mysqlSchemaCheck)
+ [nonNativePartitioningMemeriksa](#nonNativePartitioningCheck)
+ [oldTemporalCheck](#oldTemporalCheck)
+ [partitionedTablesInBerbagi TablespaceCheck](#partitionedTablesInSharedTablespace)
+ [removedFunctionsCheck](#removedFunctionsCheck)
+ [routineSyntaxCheck](#routineSyntaxCheck)
+ [schemaInconsistencyCheck](#schemaInconsistencyCheck)
**checkTableMysqlSkema**
**Tingkat precheck: Kesalahan**
**Masalah yang dilaporkan oleh `check table x for upgrade` perintah untuk `mysql` skema**
Sebelum memulai upgrade ke Aurora MySQL versi 3, `check table for upgrade` dijalankan pada setiap tabel dalam skema pada instance DB. `mysql` `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
Untuk informasi selengkapnya, lihat [pernyataan CHECK TABLE](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "checkTableMysqlSchema",
"title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
"status": "OK",
"detectedProblems": []
}
```
Output untuk precheck ini tergantung pada kesalahan yang ditemui, dan ketika ditemui, karena `check table for upgrade` melakukan beberapa pemeriksaan.
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.
**circularDirectoryCheck**
**Tingkat precheck: Kesalahan**
**Referensi direktori melingkar di jalur file data tablespace**
Pada [MySQL](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-17.html) 8.0.17, klausa tidak lagi mengizinkan referensi direktori `CREATE TABLESPACE ... ADD DATAFILE` melingkar. Untuk menghindari masalah peningkatan, hapus referensi direktori melingkar dari jalur file data tablespace sebelum memutakhirkan ke Aurora MySQL versi 3.
**Contoh keluaran:**
```
{
"id": "circularDirectory",
"title": "Circular directory references in tablespace data file paths",
"status": "OK",
"description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
"detectedProblems": [
{
"level": "Error",
"dbObject": "ts2",
"description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
"dbObjectType": "Tablespace"
}
]
}
```
Jika Anda menerima kesalahan ini, buat kembali tabel Anda menggunakan [file-per-table tablespace](https://dev.mysql.com/doc/refman/8.0/en/innodb-file-per-table-tablespaces.html). Gunakan jalur file default untuk semua definisi tablespace dan tabel.
Aurora MySQL tidak mendukung ruang meja atau perintah umum. `CREATE TABLESPACE`
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.
Setelah membangun kembali, precheck berlalu, memungkinkan peningkatan untuk melanjutkan.
```
{
"id": "circularDirectoryCheck",
"title": "Circular directory references in tablespace data file paths",
"status": "OK",
"detectedProblems": []
},
```
**columnsWhichCannotHaveDefaultsCheck**
**Tingkat precheck: Kesalahan**
**Kolom yang tidak dapat memiliki nilai default**
[Sebelum MySQL 8.0.13`BLOB`,,, `TEXT``GEOMETRY`, `JSON` dan kolom tidak dapat memiliki nilai default.](https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html) Hapus klausa default pada kolom ini sebelum memutakhirkan ke Aurora MySQL versi 3. Untuk informasi selengkapnya tentang perubahan penanganan default untuk tipe data ini, lihat [nilai default tipe Data](https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "columnsWhichCannotHaveDefaultsCheck",
"title": "Columns which cannot have default values",
"status": "OK",
"description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.test_blob_default.geo_col",
"description": "geometry"
}
]
},
```
Precheck mengembalikan kesalahan karena `geo_col` kolom dalam `test.test_blob_default` tabel menggunakan`BLOB`,, `TEXT``GEOMETRY`, atau tipe `JSON` data dengan nilai default yang ditentukan.
Melihat definisi tabel, kita dapat melihat bahwa `geo_col` kolom didefinisikan sebagai`geo_col geometry NOT NULL default ''`.
```
mysql> show create table test_blob_default\G
*************************** 1. row ***************************
Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
`geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1
```
Menghapus klausa default ini untuk memungkinkan precheck lulus.
Sebelum menjalankan `ALTER TABLE` pernyataan atau membangun kembali ruang tabel, 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> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> show create table test_blob_default\G
*************************** 1. row ***************************
Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
`geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
```
Precheck berlalu, dan Anda dapat mencoba kembali upgrade.
```
{
"id": "columnsWhichCannotHaveDefaultsCheck",
"title": "Columns which cannot have default values",
"status": "OK",
"detectedProblems": []
},
```
**depreciatedSyntaxCheck**
**Tingkat precheck: Kesalahan**
**Penggunaan kata kunci yang disusutkan dalam definisi**
[MySQL 8.0 telah menghapus cache kueri.](https://dev.mysql.com/doc/refman/5.7/en/query-cache.html) Akibatnya, beberapa sintaks SQL khusus cache kueri telah dihapus. Jika salah satu objek database Anda berisi`QUERY CACHE`,`SQL_CACHE`, atau `SQL_NO_CACHE` kata kunci, kesalahan precheck dikembalikan. Untuk mengatasi masalah ini, buat ulang objek ini, hapus kata kunci yang disebutkan.
**Contoh keluaran:**
```
{
"id": "depreciatedSyntaxCheck",
"title": "Usage of depreciated keywords in definition",
"status": "OK",
"description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
}
]
}
```
Precheck melaporkan bahwa prosedur yang `test.no_query_cache_check` disimpan menggunakan salah satu kata kunci yang dihapus. Melihat definisi prosedur, kita dapat melihat bahwa ia menggunakan`SQL_NO_CACHE`.
```
mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
Procedure: no_query_cache_check
sql_mode:
Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Hapus kata kunci.
```
mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)
mysql> delimiter //
mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)
mysql> delimiter ;
```
Setelah menghapus kata kunci, precheck selesai dengan sukses.
```
{
"id": "depreciatedSyntaxCheck",
"title": "Usage of depreciated keywords in definition",
"status": "OK",
"detectedProblems": []
}
```
**engineMixupCheck**
**Tingkat precheck: Kesalahan**
**Tabel yang diakui oleh InnoDB milik mesin yang berbeda**
Mirip dengan [schemaInconsistencyCheck](#schemaInconsistencyCheck), precheck ini memverifikasi bahwa metadata tabel di MySQL konsisten sebelum melanjutkan dengan peningkatan.
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.
**Contoh keluaran:**
```
{
"id": "engineMixupCheck",
"title": "Tables recognized by InnoDB that belong to a different engine",
"status": "OK",
"description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "mysql.general_log_backup",
"description": "recognized by the InnoDB engine but belongs to CSV"
}
]
}
```
**enumSetElementLengthCheck**
**Tingkat precheck: Kesalahan**
**`ENUM`dan definisi `SET` kolom yang mengandung elemen yang lebih panjang dari 255 karakter**
Tabel dan prosedur yang disimpan tidak boleh memiliki `ENUM` atau elemen `SET` kolom melebihi 255 karakter atau 1020 byte. Sebelum MySQL 8.0, panjang gabungan maksimum adalah 64K, tetapi 8.0 membatasi elemen individu untuk 255 karakter atau 1020 byte (mendukung multibyte). Jika Anda mendapatkan kegagalan precheck`enumSetElementLengthCheck`, ubah elemen apa pun yang melebihi batas baru ini sebelum mencoba kembali pemutakhiran.
**Contoh keluaran:**
```
{
"id": "enumSetElementLengthCheck",
"title": "ENUM/SET column definitions containing elements longer than 255 characters",
"status": "OK",
"description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.large_set.s",
"description": "SET contains element longer than 255 characters"
}
]
},
```
Precheck melaporkan kesalahan karena kolom `s` dalam `test.large_set` tabel berisi `SET` elemen yang lebih besar dari 255 karakter.
Setelah mengurangi `SET` ukuran untuk kolom ini, precheck berlalu, memungkinkan peningkatan untuk melanjutkan.
```
{
"id": "enumSetElementLenghtCheck",
"title": "ENUM/SET column definitions containing elements longer than 255 characters",
"status": "OK",
"detectedProblems": []
},
```
**foreignKeyLengthMemeriksa**
**Tingkat precheck: Kesalahan**
**Nama kendala kunci asing lebih panjang dari 64 karakter**
[Di MySQL, panjang pengidentifikasi dibatasi hingga 64 karakter, seperti yang diuraikan dalam dokumentasi MySQL.](https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html) Karena [masalah](https://bugs.mysql.com/bug.php?id=88118) yang diidentifikasi di mana panjang kunci asing dapat sama atau melebihi nilai ini, yang menyebabkan kegagalan peningkatan, precheck ini diterapkan. Jika Anda mengalami kesalahan dengan precheck ini, Anda harus [mengubah atau mengganti nama](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) kendala Anda sehingga kurang dari 64 karakter sebelum mencoba kembali pemutakhiran.
**Contoh keluaran:**
```
{
"id": "foreignKeyLength",
"title": "Foreign key constraint names longer than 64 characters",
"status": "OK",
"detectedProblems": []
}
```
**getDuplicateTriggers**
**Tingkat precheck: Kesalahan**
**Semua nama pemicu dalam database harus unik.**
Karena perubahan dalam implementasi kamus data, MySQL 8.0 tidak mendukung pemicu case-sensitive dalam database. Precheck ini memvalidasi bahwa cluster DB Anda tidak memiliki satu atau lebih database yang berisi pemicu duplikat. Untuk informasi selengkapnya, lihat [Sensitivitas huruf pengenal](https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "getDuplicateTriggers",
"title": "MySQL pre-checks that all trigger names in a database are unique or not.",
"status": "OK",
"description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test",
"description": "before_insert_product"
},
{
"level": "Error",
"dbObject": "test",
"description": "before_insert_PRODUCT"
}
]
}
```
Precheck melaporkan kesalahan bahwa cluster database memiliki dua pemicu dengan nama yang sama, tetapi menggunakan kasus yang berbeda: `test.before_insert_product` dan. `test.before_insert_PRODUCT`
Sebelum memutakhirkan, ganti nama pemicu atau jatuhkan dan buat ulang dengan nama baru.
Setelah mengganti nama `test.before_insert_PRODUCT` menjadi`test.before_insert_product_2`, precheck berhasil.
```
{
"id": "getDuplicateTriggers",
"title": "MySQL pre-checks that all trigger names in a database are unique or not.",
"status": "OK",
"detectedProblems": []
}
```
**getEventsWithNullDefiner**
**Tingkat precheck: Kesalahan**
**Kolom definer untuk tidak `mysql.event` bisa null atau kosong.**
`DEFINER`Atribut menentukan akun MySQL yang memiliki definisi objek tersimpan, seperti pemicu, prosedur tersimpan, atau peristiwa. Atribut ini sangat berguna dalam situasi di mana Anda ingin mengontrol konteks keamanan di mana objek yang disimpan berjalan. Saat membuat objek tersimpan, jika `DEFINER` tidak ditentukan, defaultnya adalah pengguna yang membuat objek.
Saat memutakhirkan ke MySQL 8.0, Anda tidak dapat memiliki objek tersimpan yang memiliki definer atau kosong dalam kamus `null` data MySQL. Jika Anda memiliki objek yang disimpan seperti itu, kesalahan precheck akan muncul. Anda harus memperbaikinya sebelum upgrade dapat dilanjutkan.
Contoh kesalahan:
```
{
"id": "getEventsWithNullDefiner",
"title": "The definer column for mysql.event cannot be null or blank.",
"status": "OK",
"description": "Error: Set definer column in mysql.event to a valid non-null definer.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.get_version",
"description": "Set definer for event get_version in Schema test"
}
]
}
```
Precheck mengembalikan kesalahan untuk `test.get_version` [acara](https://dev.mysql.com/doc/refman/5.7/en/events-overview.html) karena memiliki `null` definer.
Untuk mengatasi ini, Anda dapat memeriksa definisi acara. Seperti yang Anda lihat, definernya kosong `null` atau kosong.
```
mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db | name | definer |
+------+-------------+---------+
| test | get_version | |
+------+-------------+---------+
1 row in set (0.00 sec)
```
Jatuhkan atau buat ulang acara dengan definer yang valid.
Sebelum menjatuhkan atau mendefinisikan ulang`DEFINER`, tinjau dan periksa aplikasi dan persyaratan hak istimewa Anda dengan cermat. Untuk informasi selengkapnya, lihat [Kontrol akses objek tersimpan](https://dev.mysql.com/doc/refman/5.7/en/stored-objects-security.html) dalam dokumentasi MySQL.
```
mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)
mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
-> ON SCHEDULE
-> EVERY 1 DAY
-> DO
-> ///DO SOMETHING //
-> $$
Query OK, 0 rows affected (0.01 sec)
mysql> DELIMITER ;
mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db | name | definer |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)
```
Sekarang precheck berlalu.
```
{
"id": "getEventsWithNullDefiner",
"title": "The definer column for mysql.event cannot be null or blank.",
"status": "OK",
"detectedProblems": []},
```
**getMismatchedMetadata**
**Tingkat precheck: Kesalahan**
**Ketidakcocokan definisi kolom antara kamus data InnoDB dan definisi tabel aktual**
Mirip dengan [schemaInconsistencyCheck](#schemaInconsistencyCheck), precheck ini memverifikasi bahwa metadata tabel di MySQL konsisten sebelum melanjutkan dengan peningkatan. Dalam hal ini, precheck memverifikasi bahwa definisi kolom cocok antara kamus data InnoDB dan definisi tabel MySQL. Jika ketidakcocokan jika terdeteksi, pemutakhiran tidak dilanjutkan.
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.
**Contoh keluaran:**
```
{
"id": "getMismatchedMetadata",
"title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
"status": "OK",
"description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.mismatchTable",
"description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
}
]
}
```
Precheck melaporkan ketidakcocokan dalam metadata untuk `id` kolom dalam tabel. `test.mismatchTable` Secara khusus, metadata MySQL memiliki nama kolom sebagai`iD`, sedangkan InnoDB memilikinya sebagai. `id`
**getTriggersWithNullDefiner**
**Tingkat precheck: Kesalahan**
**Kolom definer untuk tidak `information_schema.triggers` bisa `null` atau kosong.**
Precheck memvalidasi bahwa database Anda tidak memiliki pemicu yang didefinisikan dengan `null` atau definer kosong. Untuk informasi selengkapnya tentang persyaratan definer untuk objek yang disimpan, lihat [getEventsWithNullDefiner](#getEventsWithNullDefiner).
**Contoh keluaran:**
```
{
"id": "getTriggersWithNullDefiner",
"title": "The definer column for information_schema.triggers cannot be null or blank.",
"status": "OK",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.example_trigger",
"description": "Set definer for trigger example_trigger in Schema test"
}
]
}
```
Precheck mengembalikan kesalahan karena `example_trigger` pemicu dalam `test` skema memiliki definer. `null` Untuk memperbaiki masalah ini, perbaiki definer dengan membuat ulang pemicu dengan pengguna yang valid, atau lepaskan pelatuknya. Untuk informasi lebih lanjut, lihat contoh di [getEventsWithNullDefiner](#getEventsWithNullDefiner).
Sebelum menjatuhkan atau mendefinisikan ulang`DEFINER`, tinjau dan periksa aplikasi dan persyaratan hak istimewa Anda dengan cermat. Untuk informasi selengkapnya, lihat [Kontrol akses objek tersimpan](https://dev.mysql.com/doc/refman/5.7/en/stored-objects-security.html) dalam dokumentasi MySQL.
**getValueOfVariableLower\_case\_table\_names**
**Tingkat precheck: Kesalahan**
**Semua nama database atau tabel harus huruf kecil ketika `lower_case_table_names` parameter diatur ke. `1`**
Sebelum MySQL 8.0, nama database, nama tabel, dan objek lain berhubungan dengan file dalam direktori data, seperti metadata berbasis file (.frm). Variabel sistem [lower\_case\_table\_names](https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html) memungkinkan pengguna untuk mengontrol bagaimana server menangani sensitivitas kasus identifier untuk objek database, dan penyimpanan objek metadata tersebut. Parameter ini dapat diubah pada server yang sudah diinisialisasi setelah reboot.
Namun, di MySQL 8.0, sementara parameter ini masih mengontrol bagaimana server menangani sensitivitas kasus pengenal, itu tidak dapat diubah setelah kamus data diinisialisasi. Saat memutakhirkan atau membuat database MySQL 8.0, nilai yang ditetapkan `lower_case_table_names` untuk pertama kalinya kamus data dimulai di MySQL, digunakan untuk seumur hidup database itu. Pembatasan ini diberlakukan sebagai bagian dari implementasi implementasi [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html), di mana objek database dimigrasikan dari metadata berbasis file ke tabel InnoDB internal dalam skema. `mysql`
Untuk informasi selengkapnya, lihat [Perubahan kamus data](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-data-dictionary-changes) dalam dokumentasi MySQL.
Untuk menghindari masalah selama pemutakhiran saat memperbarui metadata berbasis file ke Kamus Data Atom baru, precheck ini memvalidasi bahwa ketika`lower_case_table_names = 1`, semua tabel disimpan di disk dalam huruf kecil. Jika tidak, kesalahan precheck dikembalikan, dan Anda harus memperbaiki metadata sebelum melanjutkan dengan peningkatan.
**Contoh keluaran:**
```
{
"id": "getValueOfVariablelower_case_table_names",
"title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
"status": "OK",
"description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.TEST",
"description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
}
]
}
```
Kesalahan dikembalikan karena tabel `test.TEST` berisi huruf besar, tetapi `lower_case_table_names` diatur ke. `1`
Untuk mengatasi masalah ini, Anda dapat mengganti nama tabel untuk menggunakan huruf kecil, atau memodifikasi `lower_case_table_names` parameter pada cluster DB sebelum memulai pemutakhiran.
Uji dan tinjau dokumentasi [sensitivitas huruf besar/kecil](https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html) di MySQL dengan cermat, dan bagaimana perubahan tersebut dapat memengaruhi aplikasi Anda.
Juga tinjau dokumentasi MySQL 8.0 tentang [bagaimana](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lower_case_table_names) lower\_case\_table\_names ditangani secara berbeda di MySQL 8.0.
**groupByAscSyntaxCheck**
**Tingkat precheck: Kesalahan**
**Penggunaan `GROUP BY ASC/DESC` sintaks yang dihapus**
Pada MySQL 8.0.13, usang atau sintaks untuk `ASC` klausa telah dihapus`DESC`. `GROUP BY` Kueri yang mengandalkan `GROUP BY` pengurutan sekarang dapat menghasilkan hasil yang berbeda. Untuk mendapatkan urutan pengurutan tertentu, gunakan `ORDER BY` klausa sebagai gantinya. Jika ada objek yang ada dalam database Anda menggunakan sintaks ini, Anda harus membuat ulang mereka menggunakan `ORDER BY` klausa sebelum mencoba kembali upgrade. Untuk informasi selengkapnya, lihat [perubahan SQL](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-sql-changes) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "groupbyAscSyntaxCheck",
"title": "Usage of removed GROUP BY ASC/DESC syntax",
"status": "OK",
"description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
"documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.groupbyasc",
"description": "PROCEDURE uses removed GROUP BY ASC syntax",
"dbObjectType": "Routine"
}
]
}
```
**mysqlEmptyDotTableSyntaxCheck**
**Tingkat precheck: Kesalahan**
**Periksa `.` sintaks usang yang digunakan dalam rutinitas.**
Di MySQL 8.0, rutinitas tidak dapat lagi berisi sintaks pengenal usang (). `\".\"` Jika ada rutinitas atau pemicu yang disimpan berisi pengidentifikasi tersebut, pemutakhiran gagal. Misalnya, `.dot_table` referensi berikut tidak lagi diizinkan:
```
mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
Procedure: incorrect_procedure
sql_mode:
Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Setelah Anda membuat ulang rutinitas dan pemicu untuk menggunakan sintaks pengenal yang benar dan melarikan diri, precheck lolos, dan pemutakhiran dapat dilanjutkan. Untuk informasi selengkapnya tentang pengidentifikasi, lihat [nama objek skema dalam dokumentasi](https://dev.mysql.com/doc/refman/8.0/en/identifiers.html) MySQL.
**Contoh keluaran:**
```
{
"id": "mysqlEmptyDotTableSyntaxCheck",
"title": "Check for deprecated '.' syntax used in routines.",
"status": "OK",
"description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".\"), and should be corrected before upgrade:\n",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.incorrect_procedure",
"description": " routine body contains deprecated identifiers."
}
]
}
```
Precheck mengembalikan kesalahan untuk `incorrect_procedure` rutin dalam `test` database karena berisi sintaks usang.
Setelah Anda memperbaiki rutinitas, precheck berhasil, dan Anda dapat mencoba lagi upgrade.
**mysqlIndexTooLargeCheck**
**Tingkat precheck: Kesalahan**
**Periksa indeks yang terlalu besar untuk bekerja pada versi MySQL yang lebih tinggi dari 5.7**
Untuk format baris yang ringkas atau berlebihan, seharusnya tidak mungkin membuat indeks dengan awalan yang lebih besar dari 767 byte. Namun, sebelum MySQL versi 5.7.35 ini dimungkinkan. Untuk informasi selengkapnya, lihat catatan rilis [MySQL 5.7.35](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-35.html).
Setiap indeks yang terpengaruh oleh bug ini akan menjadi tidak dapat diakses setelah memutakhirkan ke MySQL 8.0. Precheck ini mengidentifikasi indeks yang menyinggung yang harus dibangun kembali sebelum pemutakhiran diizinkan untuk dilanjutkan.
```
{
"id": "mysqlIndexTooLargeCheck",
"title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
"status": "OK",
"description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.table_with_large_idx",
"description": "IDX_2"
}
]
}
```
Precheck mengembalikan kesalahan karena `test.table_with_large_idx` tabel berisi indeks pada tabel menggunakan format baris kompak atau redundan yang lebih besar dari 767 byte. Tabel ini akan menjadi tidak dapat diakses setelah memutakhirkan ke MySQL 8.0. Sebelum melanjutkan dengan upgrade, lakukan salah satu hal berikut:
+ Jatuhkan indeks yang disebutkan dalam precheck.
+ Tambahkan indeks yang disebutkan di precheck.
+ Ubah format baris yang digunakan oleh tabel.
Di sini kita membangun kembali tabel untuk menyelesaikan kegagalan precheck. [Sebelum membangun kembali tabel, pastikan bahwa [innodb\_file\_format diatur ke, dan innodb\_default\_row\_format](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_format) diatur ke`Barracuda`.](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_default_row_format) `dynamic` Ini adalah default di MySQL 5.7. Untuk informasi selengkapnya, lihat [format baris InnoDB dan manajemen format](https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html) [file InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html) dalam dokumentasi MySQL.
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 > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda | dynamic |
+----------------------+-----------------------------+
1 row in set (0.00 sec)
mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status | OK |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)
# Verify FILE_FORMAT and ROW_FORMAT
mysql> select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| 43 | test/table_with_large_idx | 33 | 4 | 26 | Barracuda | Dynamic | 0 | Single |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)
```
Setelah membangun kembali tabel, precheck berlalu, dan peningkatan dapat dilanjutkan.
```
{
"id": "mysqlIndexTooLargeCheck",
"title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
"status": "OK",
"detectedProblems": []
},
```
**MySQLinkValid57 NamesCheck**
**Tingkat precheck: Kesalahan**
**Periksa nama tabel dan skema yang tidak valid yang digunakan di MySQL 5.7**
Saat bermigrasi ke kamus data baru di MySQL 8.0, instance database Anda tidak dapat berisi skema atau tabel yang diawali dengan. `#mysql50#` Jika ada objek seperti itu, pemutakhiran gagal. Untuk mengatasi masalah ini, jalankan [mysqlcheck](https://dev.mysql.com/doc/refman/8.0/en/mysqlcheck.html) terhadap skema dan tabel yang dikembalikan.
[Pastikan Anda menggunakan versi [MySQL 5.7](https://downloads.mysql.com/archives/community/), [karena - fix-db-names - [dan - fix-table-names](https://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html#option_mysqlcheck_fix-table-names)](https://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html#option_mysqlcheck_fix-db-names) - telah dihapus `mysqlcheck` dari MySQL 8.0.](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)
**Contoh keluaran:**
```
{
"id": "mysqlInvalid57NamesCheck",
"title": "Check for invalid table names and schema names used in 5.7",
"status": "OK",
"description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n $ mysqlcheck --check-upgrade --all-databases\n $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
"documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Error",
"dbObject": "#mysql50#fix_db_names",
"description": "Schema name"
}
]
}
```
Precheck melaporkan bahwa skema `#mysql50#fix_db_names` memiliki nama yang tidak valid.
Setelah memperbaiki nama skema, precheck lolos, memungkinkan peningkatan untuk melanjutkan.
```
{
"id": "mysqlInvalid57NamesCheck",
"title": "Check for invalid table names and schema names used in 5.7",
"status": "OK",
"detectedProblems": []
},
```
**mysqlOrphanedRoutinesMemeriksa**
**Tingkat precheck: Kesalahan**
**Periksa rutinitas yatim piatu di 5.7**
Saat bermigrasi ke kamus data baru di MySQL 8.0, jika ada prosedur tersimpan dalam database di mana skema tidak ada lagi, pemutakhiran gagal. Precheck ini memverifikasi bahwa semua skema yang direferensikan dalam prosedur tersimpan pada instans DB Anda masih ada. Untuk memungkinkan pemutakhiran dilanjutkan, jatuhkan prosedur yang disimpan ini.
**Contoh keluaran:**
```
{
"id": "mysqlOrphanedRoutinesCheck",
"title": "Check for orphaned routines in 5.7",
"status": "OK",
"description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "dropped_db.get_version",
"description": "is orphaned"
}
]
},
```
Precheck melaporkan bahwa prosedur yang `get_version` disimpan dalam `dropped_db` database adalah yatim piatu.
Untuk membersihkan prosedur ini, Anda dapat membuat ulang skema yang hilang.
```
mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)
```
Setelah skema dibuat ulang, Anda dapat menghentikan prosedur untuk memungkinkan peningkatan dilanjutkan.
```
{
"id": "mysqlOrphanedRoutinesCheck",
"title": "Check for orphaned routines in 5.7",
"status": "OK",
"detectedProblems": []
},
```
**mysqlSchemaCheck**
**Tingkat precheck: Kesalahan**
**Nama tabel dalam `mysql` skema yang bertentangan dengan tabel baru di MySQL 8.0**
[Kamus Data Atom](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) baru yang diperkenalkan di MySQL 8.0 menyimpan semua metadata dalam satu set tabel InnoDB internal dalam skema. `mysql` Selama upgrade, [tabel kamus data internal](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-schema.html) baru dibuat dalam `mysql` skema. Untuk menghindari tabrakan penamaan, yang akan mengakibatkan kegagalan pemutakhiran, precheck memeriksa semua nama tabel dalam `mysql` skema untuk memastikan bahwa tidak ada nama tabel baru yang sudah digunakan. Jika ya, kesalahan dikembalikan, dan pemutakhiran tidak diizinkan untuk dilanjutkan.
**Contoh keluaran:**
```
{
"id": "mysqlSchema",
"title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
"status": "OK",
"description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "mysql.tablespaces",
"description": "Table name used in mysql schema.",
"dbObjectType": "Table"
}
]
}
```
Kesalahan dikembalikan karena ada tabel bernama `tablespaces` dalam `mysql` skema. Ini adalah salah satu nama tabel kamus data internal baru di MySQL 8.0. Anda harus mengganti nama atau menghapus tabel tersebut sebelum memutakhirkan, dengan menggunakan perintah. `RENAME TABLE`
**nonNativePartitioningMemeriksa**
**Tingkat precheck: Kesalahan**
**Tabel yang dipartisi menggunakan mesin dengan partisi non-asli**
[https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) Dari jumlah tersebut, hanya InnoDB yang didukung di Aurora MySQL versi 3, kompatibel dengan MySQL 8.0. Setiap upaya untuk membuat tabel yang dipartisi di MySQL 8.0 menggunakan mesin penyimpanan lainnya gagal. Precheck ini mencari tabel di cluster DB Anda yang menggunakan partisi non-native. Jika ada yang dikembalikan, Anda harus menghapus partisi atau mengubah mesin penyimpanan ke InnoDB.
**Contoh keluaran:**
```
{
"id": "nonNativePartitioning",
"title": "Partitioned tables using engines with non native partitioning",
"status": "OK",
"description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.partMyisamTable",
"description": "MyISAM engine does not support native partitioning",
"dbObjectType": "Table"
}
]
}
```
Di sini tabel myISAM menggunakan partisi, yang memerlukan tindakan sebelum pemutakhiran dapat dilanjutkan.
**oldTemporalCheck**
**Tingkat precheck: Kesalahan**
**Penggunaan tipe temporal lama**
“Temporal lama” mengacu pada kolom tipe temporal (seperti `TIMESTAMP` dan`DATETIME`) yang dibuat di MySQL versi 5.5 dan lebih rendah. Di MySQL 8.0, dukungan untuk tipe data temporal lama ini dihapus, yang berarti bahwa peningkatan di tempat dari MySQL 5.7 ke 8.0 tidak dimungkinkan jika database berisi tipe temporal lama ini. Untuk memperbaikinya, Anda harus [membangun kembali](https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html) tabel apa pun yang berisi jenis tanggal temporal lama seperti itu, sebelum melanjutkan dengan peningkatan.
[Untuk informasi lebih lanjut tentang penghentian tipe data temporal lama di MySQL 5.7, lihat blog ini.](https://dev.mysql.com/blog-archive/how-to-easily-identify-tables-with-temporal-types-in-old-format/) [Untuk informasi lebih lanjut tentang penghapusan tipe data temporal lama di MySQL 8.0, lihat blog ini.](https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/)
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.
**Contoh keluaran:**
```
{
"id": "oldTemporalCheck",
"title": "Usage of old temporal type",
"status": "OK",
"description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE FORCE' command",
"documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.55_temporal_table.timestamp_column",
"description": "timestamp /* 5.5 binary format */",
"dbObjectType": "Column"
}
]
},
```
Kesalahan dilaporkan untuk kolom `timestamp_column` dalam tabel`test.55_temporal_table`, karena menggunakan format penyimpanan disk temporal lama yang tidak lagi didukung.
Untuk mengatasi masalah ini dan memungkinkan peningkatan untuk melanjutkan, buat kembali tabel untuk mengonversi format penyimpanan disk temporal lama ke yang baru diperkenalkan di MySQL 5.6. 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.
Menjalankan perintah berikut untuk membangun kembali tabel yang disebutkan dalam precheck ini mengubah tipe temporal lama ke format yang lebih baru dengan presisi fraksional-detik.
```
ALTER TABLE ... ENGINE=InnoDB;
```
Untuk informasi selengkapnya tentang membangun kembali tabel, lihat [pernyataan ALTER TABLE dalam dokumentasi](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) MySQL.
Setelah membangun kembali tabel yang dimaksud dan memulai ulang pemutakhiran, pemeriksaan kompatibilitas berlalu, memungkinkan peningkatan untuk melanjutkan.
```
{
"id": "oldTemporalCheck",
"title": "Usage of old temporal type",
"status": "OK",
"detectedProblems": []
}
```
**partitionedTablesInBerbagi TablespaceCheck**
**Tingkat precheck: Kesalahan**
**Penggunaan tabel yang dipartisi di ruang tabel bersama**
Pada [MySQL](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html) 8.0.13, dukungan untuk menempatkan partisi tabel di ruang tabel bersama dihapus. Sebelum memutakhirkan, pindahkan tabel tersebut dari ruang tabel bersama ke file-per-table ruang tabel.
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.
**Contoh keluaran:**
```
{
"id": "partitionedTablesInSharedTablespaceCheck",
"title": "Usage of partitioned tables in shared tablespaces",
"status": "OK",
"description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.partInnoDBTable",
"description": "Partition p1 is in shared tablespace innodb",
"dbObjectType": "Table"
}
]
}
```
Precheck gagal karena partisi `p1` dari tabel `test.partInnoDBTable` ada di tablespace sistem.
Untuk mengatasi masalah ini, buat kembali `test.partInnodbTable` tabel, tempatkan partisi yang menyinggung `p1` di tablespace. file-per-table
```
mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
-> INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
```
Setelah melakukannya, precheck berlalu.
```
{
"id": "partitionedTablesInSharedTablespaceCheck",
"title": "Usage of partitioned tables in shared tablespaces",
"status": "OK",
"detectedProblems": []
}
```
**removedFunctionsCheck**
**Tingkat precheck: Kesalahan**
**Penggunaan fungsi yang telah dihapus dari versi MySQL terbaru**
Di MySQL 8.0, sejumlah fungsi bawaan telah dihapus. Precheck ini memeriksa database Anda untuk objek yang mungkin menggunakan fungsi-fungsi ini. Jika ditemukan, kesalahan akan dikembalikan. Anda harus menyelesaikan masalah sebelum mencoba kembali upgrade.
Mayoritas fungsi yang dihapus adalah [fungsi spasial](https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html), yang telah diganti dengan `ST_*` fungsi yang setara. Dalam kasus ini, Anda memodifikasi objek database untuk menggunakan penamaan prosedur baru. Untuk informasi selengkapnya, lihat [Features removed in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals) dalam dokumentasi MySQL.
**Contoh keluaran:**
```
{
"id": "removedFunctionsCheck",
"title": "Usage of removed functions",
"status": "OK",
"description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.GetLocationsInPolygon",
"description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
"dbObjectType": "Routine"
},
{
"level": "Error",
"dbObject": "test.InsertLocation",
"description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
"dbObjectType": "Routine"
}
]
},
```
[Precheck melaporkan bahwa prosedur yang `test.GetLocationsInPolygon` disimpan menggunakan dua fungsi yang dihapus: [POLYGONFROMTEXT dan POINTFROMTEXT](https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html#function_polyfromtext).](https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html#function_st-mpointfromtext) [Ini juga menyarankan agar Anda menggunakan [ST\_POLYGONFROMTEXT dan ST\_POINTFROMTEXT](https://dev.mysql.com/doc/refman/8.0/en/gis-wkt-functions.html#function_st-polyfromtext) baru sebagai pengganti.](https://dev.mysql.com/doc/refman/8.0/en/gis-wkt-functions.html#function_st-mpointfromtext) Setelah membuat ulang prosedur menggunakan saran, precheck selesai dengan sukses.
```
{
"id": "removedFunctionsCheck",
"title": "Usage of removed functions",
"status": "OK",
"detectedProblems": []
},
```
Meskipun dalam kebanyakan kasus, fungsi yang tidak digunakan lagi memiliki penggantian langsung, pastikan Anda menguji aplikasi dan meninjau dokumentasi untuk setiap perubahan perilaku sebagai akibat dari perubahan tersebut.
**routineSyntaxCheck**
**Tingkat precheck: Kesalahan**
**Pemeriksaan sintaks MySQL untuk objek seperti rutin**
MySQL 8.0 [memperkenalkan kata kunci cadangan yang tidak dicadangkan](https://dev.mysql.com/doc/mysqld-version-reference/en/keywords-8-0.html#keywords-new-in-8-0) sebelumnya. Upgrade prechecker mengevaluasi penggunaan kata kunci yang dicadangkan dalam nama objek database dan dalam definisi dan badannya. Jika mendeteksi kata kunci cadangan yang digunakan dalam objek database, seperti prosedur, fungsi, peristiwa, dan pemicu yang disimpan, pemutakhiran gagal dan kesalahan dipublikasikan ke file. `upgrade-prechecks.log` Untuk mengatasi masalah ini, Anda harus memperbarui definisi objek ini dan melampirkan referensi tersebut dalam tanda kutip tunggal (') sebelum memutakhirkan. Untuk informasi selengkapnya tentang melarikan diri dari kata-kata yang dicadangkan di MySQL, [lihat String literal](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html) dalam dokumentasi MySQL.
Atau, Anda dapat mengubah nama ke nama lain, yang mungkin memerlukan perubahan aplikasi.
**Contoh keluaran:**
```
{
"id": "routineSyntaxCheck",
"title": "MySQL syntax check for routine-like objects",
"status": "OK",
"description": "The following objects did not pass a syntax check with the latest MySQL grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.select_res_word",
"description": "at line 2,18: unexpected token 'except'",
"dbObjectType": "Routine"
}
]
}
```
Untuk memperbaiki masalah ini, periksa definisi rutin.
```
SHOW CREATE PROCEDURE test.select_res_word\G
*************************** 1. row ***************************
Procedure: select_res_word
sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Prosedur ini menggunakan tabel bernama`except`, yang merupakan kata kunci baru di MySQL 8.0. Buat ulang prosedur dengan melarikan diri dari string literal.
```
> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)
> DELIMITER $$
> CREATE PROCEDURE select_res_word()
-> BEGIN
-> SELECT * FROM 'except';
-> END$$
Query OK, 0 rows affected (0.00 sec)
> DELIMITER ;
```
Precheck sekarang berlalu.
```
{
"id": "routineSyntaxCheck",
"title": "MySQL syntax check for routine-like objects",
"status": "OK",
"detectedProblems": []
}
```
**schemaInconsistencyCheck**
**Tingkat precheck: Kesalahan**
**Inkonsistensi skema yang dihasilkan dari penghapusan file atau korupsi**
Seperti dijelaskan sebelumnya, MySQL 8.0 memperkenalkan [Atomic Data](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) Dictionary, yang menyimpan semua metadata dalam satu set tabel InnoDB internal dalam skema. `mysql` Arsitektur baru ini menyediakan cara transaksional, sesuai [ACID](https://en.wikipedia.org/wiki/ACID) untuk mengelola metadata database, memecahkan masalah “DDL atom” dari pendekatan berbasis file lama. Sebelum MySQL 8.0, objek skema mungkin menjadi yatim piatu jika operasi DDL tiba-tiba terganggu. Migrasi metadata berbasis file ke tabel Atomic Data Dictionary baru selama upgrade memastikan bahwa tidak ada objek skema yatim piatu seperti itu dalam instance DB. Jika ada objek yatim piatu yang ditemui, pemutakhiran gagal.
Untuk membantu mendeteksi objek yatim piatu ini sebelum memulai pemutakhiran, `schemaInconsistencyCheck` precheck dijalankan untuk memastikan bahwa semua objek metadata kamus data disinkronkan. Jika ada objek metadata yatim piatu yang terdeteksi, pemutakhiran tidak dilanjutkan. Untuk melanjutkan dengan upgrade, bersihkan objek metadata yatim piatu ini.
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.
**Contoh keluaran:**
```
{
"id": "schemaInconsistencyCheck",
"title": "Schema inconsistencies resulting from file removal or corruption",
"status": "OK",
"description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.schemaInconsistencyCheck_failure",
"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
}
]
}
```
Precheck melaporkan bahwa `test.schemaInconsistencyCheck_failure` tabel memiliki metadata yang tidak konsisten. Dalam hal ini, tabel ada di metadata mesin penyimpanan InnoDB (`information_schema.INNODB_SYS_TABLES`), tetapi tidak di metadata MySQL (). `information_schema.TABLES`
### Aurora MySQL memeriksa sebelumnya yang melaporkan kesalahan
Precheck berikut khusus untuk Aurora MySQL:
+ [AuroraCheck DDLRecovery](#auroraCheckDDLRecovery)
+ [auroraCheckRdsUpgradePrechecksTable](#auroraCheckRdsUpgradePrechecksTable)
+ [Aurora Cek FODUpgrade](#auroraFODUpgradeCheck)
+ [auroraGetDanglingFulltextIndex](#auroraGetDanglingFulltextIndex)
+ [auroraUpgradeCheckForDatafilePathInconsistency](#auroraUpgradeCheckForDatafilePathInconsistency)
+ [auroraUpgradeCheckForFtsSpaceIdZero](#auroraUpgradeCheckForFtsSpaceIdZero)
+ [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions)
+ [auroraUpgradeCheckForInstanceLimit](#auroraUpgradeCheckForInstanceLimit)
+ [auroraUpgradeCheckForInternalUsers](#auroraUpgradeCheckForInternalUsers)
+ [auroraUpgradeCheckForInvalidUtf8mb3 CharacterStringInViews](#auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews)
+ [auroraUpgradeCheckForInvalidUtf8mb3 ColumnComments](#auroraUpgradeCheckForInvalidUtf8mb3ColumnComments)
+ [auroraUpgradeCheckForInvalidUtf8mb3 IndexComments](#auroraUpgradeCheckForInvalidUtf8mb3IndexComments)
+ [auroraUpgradeCheckForInvalidUtf8mb3 TableComments](#auroraUpgradeCheckForInvalidUtf8mb3TableComments)
+ [auroraUpgradeCheckForMasterUser](#auroraUpgradeCheckForMasterUser)
+ [auroraUpgradeCheckForPrefixIndexOnGeometryColumns](#auroraUpgradeCheckForPrefixIndexOnGeometryColumns)
+ [auroraUpgradeCheckForSpecialCharactersInProcedures](#auroraUpgradeCheckForSpecialCharactersInProcedures)
+ [auroraUpgradeCheckForSysSchemaObjectTypeMismatch](#auroraUpgradeCheckForSysSchemaObjectTypeMismatch)
+ [auroraUpgradeCheckForViewColumnNameLength](#auroraUpgradeCheckForViewColumnNameLength)
+ [auroraUpgradeCheckIndexLengthLimitOnTinyColumns](#auroraUpgradeCheckIndexLengthLimitOnTinyColumns)
+ [auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable](#auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable)
**AuroraCheck DDLRecovery**
**Tingkat precheck: Kesalahan**
**Periksa artefak yang terkait dengan fitur pemulihan Aurora DDL**
Sebagai bagian dari implementasi pemulihan Data Definition Language (DDL) di Aurora MySQL, metadata pada pernyataan DDL dalam pesawat dipertahankan dalam dan tabel dalam skema. `ddl_log_md_table` `ddl_log_table` `mysql` Implementasi pemulihan DDL Aurora tidak didukung untuk versi 3 dan seterusnya, karena fungsinya merupakan bagian dari implementasi [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) baru di MySQL 8.0. Jika Anda memiliki pernyataan DDL yang berjalan selama pemeriksaan kompatibilitas, precheck ini mungkin gagal. Kami menyarankan Anda mencoba upgrade sementara tidak ada pernyataan DDL yang berjalan.
Jika precheck ini gagal tanpa menjalankan pernyataan DDL, 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.
Jika ada pernyataan DDL yang berjalan, output precheck mencetak pesan berikut:
```
“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”
```
**Contoh keluaran:**
```
{
"id": "auroraCheckDDLRecovery",
"title": "Check for artifacts related to Aurora DDL recovery feature",
"status": "OK",
"description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
"detectedProblems": [
{
"level": "Error",
"dbObject": "mysql.ddl_log_md_table",
"description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
},
{
"level": "Error",
"dbObject": "mysql.ddl_log_table",
"description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
},
{
"level": "Error",
"dbObject": "information_schema.processlist",
"description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
}
]
}
```
Precheck mengembalikan kesalahan karena DDL dalam pesawat berjalan bersamaan dengan pemeriksaan kompatibilitas. Kami menyarankan Anda mencoba lagi upgrade tanpa DDLs berjalan.
**auroraCheckRdsUpgradePrechecksTable**
**Tingkat precheck: Kesalahan**
**Periksa keberadaan `mysql.rds_upgrade_prechecks` tabel**
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.
```
{
"id": "auroraCheckRdsUpgradePrechecksTable",
"title": "Check existence of mysql.rds_upgrade_prechecks table",
"status": "OK",
"detectedProblems": []
}
```
**Aurora Cek FODUpgrade**
**Tingkat precheck: Kesalahan**
**Periksa artefak yang terkait dengan fitur DDL cepat Aurora**
Optimasi [Fast DDL](AuroraMySQL.Managing.FastDDL.md) diperkenalkan dalam [mode lab](AuroraMySQL.Updates.LabMode.md) pada Aurora MySQL versi 2 untuk meningkatkan efisiensi beberapa operasi DDL. [Di Aurora MySQL versi 3, mode lab telah dihapus, dan implementasi Fast DDL telah digantikan oleh fitur MySQL 8.0 yang disebut Instant DDL.](https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-operations.html)
Sebelum memutakhirkan ke Aurora MySQL versi 3, tabel apa pun yang menggunakan Fast DDL dalam mode lab harus dibangun kembali dengan `ALTER TABLE ... ENGINE=InnoDB` menjalankan perintah or untuk memastikan kompatibilitas dengan `OPTIMIZE TABLE` Aurora MySQL versi 3.
Precheck ini mengembalikan daftar tabel tersebut. Setelah tabel yang dikembalikan telah dibangun kembali, Anda dapat mencoba kembali upgrade.
**Contoh keluaran:**
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.test",
"description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE ' 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 \#76012](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\_schema.innodb\_trx](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. Contoh:
```
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 \#11808](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\_SCHEMA.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\_global\_by\_latency](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\_sha2\_password 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\_mode 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\_schema.innodb\_trx](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\_key\_checks.](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": []
},
```