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 My SQL
Prakecek pemutakhiran untuk Aurora SQL My dijelaskan di sini secara rinci.
Daftar Isi
Kesalahan
Prececks berikut menghasilkan kesalahan saat precheck gagal, dan pemutakhiran tidak dapat dilanjutkan.
SQLPrecheck saya yang melaporkan kesalahan
Precheck berikut berasal dari Community MySQL:
- checkTableMysqlSkema
-
Tingkat precheck: Kesalahan
Masalah yang dilaporkan oleh
check table x for upgrade
perintah untukmysql
skemaSebelum memulai upgrade ke Aurora My SQL versi 3,
check table for upgrade
dijalankan pada setiap tabel dalammysql
skema pada instance DB.check table for upgrade
Perintah memeriksa tabel untuk setiap potensi masalah yang mungkin timbul selama peningkatan ke versi My yang lebih baru. SQL 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 target Versi saya SQL
-
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 CHECKTABLEpernyataan
di SQL dokumentasi Saya. 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
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang baru. -
- circularDirectoryCheck
-
Tingkat precheck: Kesalahan
Referensi direktori melingkar di jalur file data tablespace
Pada My SQL 8.0.17
, CREATE TABLESPACE ... ADD DATAFILE
klausa tidak lagi mengizinkan referensi direktori melingkar. Untuk menghindari masalah pemutakhiran, hapus referensi direktori melingkar dari jalur file data tablespace sebelum memutakhirkan ke Aurora My version 3. SQLContoh 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
. Gunakan jalur file default untuk semua definisi tablespace dan tabel. catatan
Aurora My SQL tidak mendukung ruang meja atau perintah umum.
CREATE TABLESPACE
Sebelum membangun kembali ruang tabel, lihat DDLOperasi online
di SQL dokumentasi Saya 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 SQL 8.0.13,,,
BLOB
TEXT
GEOMETRY
, danJSON
kolom Saya tidak dapat memiliki nilai default. Hapus klausa default apa pun pada kolom ini sebelum memutakhirkan ke Aurora My version 3. SQL Untuk informasi selengkapnya tentang perubahan penanganan default untuk tipe data ini, lihat Nilai default tipe data dalam SQL dokumentasi Saya. 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 dalamtest.test_blob_default
tabel menggunakanBLOB
,,TEXT
GEOMETRY
, atau tipeJSON
data dengan nilai default yang ditentukan.Melihat definisi tabel, kita dapat melihat bahwa
geo_col
kolom didefinisikan sebagaigeo_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.
catatan
Sebelum menjalankan
ALTER TABLE
pernyataan atau membangun kembali ruang tabel, lihat DDLOperasi onlinedi SQL dokumentasi Saya 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
SQL8.0 saya telah menghapus cache kueri
. Akibatnya, beberapa SQL sintaks khusus cache kueri telah dihapus. Jika salah satu objek database Anda berisi QUERY CACHE
,SQL_CACHE
, atauSQL_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 menggunakanSQL_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, precheck ini memverifikasi bahwa metadata tabel di My SQL konsisten sebelum melanjutkan dengan peningkatan.
Jika Anda menemukan kesalahan dengan precheck ini, buka kasus dengan AWS Support
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang 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 definisiSET
kolom yang mengandung elemen yang lebih panjang dari 255 karakterTabel dan prosedur yang disimpan tidak boleh memiliki
ENUM
atau elemenSET
kolom melebihi 255 karakter atau 1020 byte. Sebelum My SQL 8.0, panjang gabungan maksimum adalah 64K, tetapi 8.0 membatasi elemen individu menjadi 255 karakter atau 1020 byte (mendukung multibyte). Jika Anda mendapatkan kegagalan precheckenumSetElementLengthCheck
, 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
dalamtest.large_set
tabel berisiSET
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, sebagaimana diuraikan dalam dokumentasi Saya SQL
. Karena masalah 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 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, My SQL 8.0 tidak mendukung pemicu peka huruf besar/kecil 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
dalam SQL dokumentasi Saya. 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
menjaditest.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 SQL akun Saya 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, jikaDEFINER
tidak ditentukan, defaultnya adalah pengguna yang membuat objek.Saat memutakhirkan ke My SQL 8.0, Anda tidak dapat memiliki objek tersimpan yang memiliki definer
null
atau kosong di kamus data SayaSQL. 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
acarakarena 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.
catatan
Sebelum menjatuhkan atau mendefinisikan ulang
DEFINER
, tinjau dan periksa aplikasi dan persyaratan hak istimewa Anda dengan cermat. Untuk informasi selengkapnya, lihat Kontrol akses objek tersimpandi SQL dokumentasi Saya. 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, precheck ini memverifikasi bahwa metadata tabel di My SQL konsisten sebelum melanjutkan dengan peningkatan. Dalam hal ini, precheck memverifikasi bahwa definisi kolom cocok antara kamus data InnoDB dan definisi tabel Saya. SQL Jika ketidakcocokan jika terdeteksi, pemutakhiran tidak dilanjutkan.
Jika Anda menemukan kesalahan dengan precheck ini, buka kasus dengan AWS Support
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang 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, SQL metadata Saya memiliki nama kolom sebagaiiD
, sedangkan InnoDB memilikinya sebagai.id
- getTriggersWithNullDefiner
-
Tingkat precheck: Kesalahan
Kolom definer untuk tidak
information_schema.triggers
bisanull
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.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 dalamtest
skema memiliki definer.null
Untuk memperbaiki masalah ini, perbaiki definer dengan membuat ulang pemicu dengan pengguna yang valid, atau lepaskan pelatuknya. Untuk informasi selengkapnya, lihat contoh di getEventsWithNullDefiner.catatan
Sebelum menjatuhkan atau mendefinisikan ulang
DEFINER
, tinjau dan periksa aplikasi dan persyaratan hak istimewa Anda dengan cermat. Untuk informasi selengkapnya, lihat Kontrol akses objek tersimpandi SQL dokumentasi Saya. - 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 My SQL 8.0, nama database, nama tabel, dan objek lain berhubungan dengan file di direktori data, seperti metadata berbasis file (.frm). Variabel sistem lower_case_table_names
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 My SQL 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 My SQL 8.0, nilai yang ditetapkan untuk
lower_case_table_names
pertama kalinya kamus data dimulai di MySQL, digunakan untuk seumur hidup database itu. Pembatasan ini diberlakukan sebagai bagian dari implementasi implementasi Atomic Data Dictionary, di mana objek database dimigrasikan dari metadata berbasis file ke tabel InnoDB internal dalam skema. mysql
Untuk informasi selengkapnya, lihat Perubahan kamus data
dalam SQL dokumentasi Saya. 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, tetapilower_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.catatan
Uji dan tinjau dokumentasi sensitivitas huruf besar/kecil
di My dengan cermatSQL, dan bagaimana perubahan tersebut dapat memengaruhi aplikasi Anda. Juga tinjau dokumentasi My SQL 8.0 tentang bagaimana lower_case_table_names ditangani
secara berbeda di My 8.0. SQL - groupByAscSyntaxCheck
-
Tingkat precheck: Kesalahan
Penggunaan
GROUP BY ASC/DESC
sintaks yang dihapusPada My SQL 8.0.13, usang
ASC
atauDESC
sintaks untuk klausa telah dihapus.GROUP BY
Kueri yang mengandalkanGROUP BY
penyortiran sekarang dapat menghasilkan hasil yang berbeda. Untuk mendapatkan urutan pengurutan tertentu, gunakanORDER BY
klausa sebagai gantinya. Jika ada objek yang ada dalam database Anda menggunakan sintaks ini, Anda harus membuat ulang mereka menggunakanORDER BY
klausa sebelum mencoba kembali upgrade. Untuk informasi selengkapnya, lihat SQLperubahandalam SQL dokumentasi Saya. 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
.<table>
sintaks usang yang digunakan dalam rutinitas.Di My SQL 8.0, rutinitas tidak dapat lagi berisi sintaks pengenal usang ().
\".<table>\"
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 SayaSQL. Contoh keluaran:
{ "id": "mysqlEmptyDotTableSyntaxCheck", "title": "Check for deprecated '.<table>' syntax used in routines.", "status": "OK", "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), 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 dalamtest
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 SQL versi Saya 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 SQL Versi saya 5.7.35 ini dimungkinkan. Untuk informasi selengkapnya, lihat catatan rilis My SQL 5.7.35
. Indeks apa pun yang terpengaruh oleh bug ini akan menjadi tidak dapat diakses setelah memutakhirkan ke My 8.0. SQL Precheck ini mengidentifikasi indeks yang menyinggung yang harus dibangun kembali sebelum upgrade diizinkan untuk melanjutkan.
{ "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 My SQL 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
diatur ke Barracuda
.dynamic
Ini adalah default di My 5.7. SQL Untuk informasi selengkapnya, lihat format baris InnoDB dan manajemen formatfile InnoDB di dokumentasi Saya. SQL catatan
Sebelum membangun kembali ruang tabel, lihat DDLOperasi online
di SQL dokumentasi Saya 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": [] },
-
- mysqlInvalid57 NamesCheck
-
Tingkat precheck: Kesalahan
Periksa nama tabel dan skema yang tidak valid yang digunakan di My 5.7 SQL
Saat bermigrasi ke kamus data baru di My SQL 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 mysqlcheckterhadap skema dan tabel yang dikembalikan. catatan
Pastikan Anda menggunakan versi My SQL 5.7
mysqlcheck
, karena -- fix-db-names dan -- fix-table-namestelah dihapus dari My SQL 8.0 . 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 My SQL 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 dalamdropped_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 My 8.0 SQLKamus Data Atom
baru yang diperkenalkan di My SQL 8.0 menyimpan semua metadata dalam satu set tabel InnoDB internal dalam skema. mysql
Selama upgrade, tabel kamus data internalbaru dibuat dalam mysql
skema. Untuk menghindari tabrakan penamaan, yang akan mengakibatkan kegagalan pemutakhiran, precheck memeriksa semua nama tabel dalammysql
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
dalammysql
skema. Ini adalah salah satu nama tabel kamus data internal baru di My SQL 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
Menurut dokumentasi My SQL 8.0
, dua mesin penyimpanan saat ini menyediakan dukungan partisi asli: InnoDB dan. NDB Dari jumlah tersebut, hanya InnoDB yang didukung di Aurora My SQL versi 3, kompatibel dengan My 8.0. SQL Setiap upaya untuk membuat tabel yang dipartisi di My SQL 8.0 menggunakan mesin penyimpanan lain 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 ISAM tabel Saya menggunakan partisi, yang memerlukan tindakan sebelum peningkatan dapat dilanjutkan.
- oldTemporalCheck
-
Tingkat precheck: Kesalahan
Penggunaan tipe temporal lama
“Temporal lama” mengacu pada kolom tipe temporal (seperti
TIMESTAMP
danDATETIME
) yang dibuat dalam SQL versi Saya 5.5 dan yang lebih rendah. Di My SQL 8.0, dukungan untuk tipe data temporal lama ini dihapus, yang berarti bahwa peningkatan di tempat dari My SQL 5.7 ke 8.0 tidak dimungkinkan jika database berisi tipe temporal lama ini. Untuk memperbaikinya, Anda harus membangun kembalitabel yang berisi jenis tanggal temporal lama seperti itu, sebelum melanjutkan dengan peningkatan. Untuk informasi lebih lanjut tentang penghentian tipe data temporal lama di My SQL 5.7, lihat blog ini.
Untuk informasi lebih lanjut tentang penghapusan tipe data temporal lama di My SQL 8.0, lihat blog ini. catatan
Sebelum membangun kembali ruang tabel, lihat DDLOperasi online
di SQL dokumentasi Saya 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 <table_name> 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 tabeltest.55_temporal_table
, karena menggunakan format penyimpanan disk temporal lama yang tidak lagi didukung.Untuk mengatasi masalah ini dan memungkinkan pemutakhiran dilanjutkan, buat kembali tabel untuk mengonversi format penyimpanan disk temporal lama ke format baru yang diperkenalkan di My SQL 5.6. Untuk informasi lebih lanjut dan prasyarat sebelum melakukannya, lihat Mengonversi antara set karakter Unicode 3-byte dan 4-byte
dalam dokumentasi Saya. SQL 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 ALTERTABLEpernyataan
di SQL dokumentasi Saya. 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": [] }
-
Tingkat precheck: Kesalahan
Penggunaan tabel yang dipartisi di ruang tabel bersama
Pada My SQL 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. catatan
Sebelum membangun kembali ruang tabel, lihat Mempartisi operasi
dalam SQL dokumentasi Saya 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 tabeltest.partInnoDBTable
ada di tablespace sistem.Untuk mengatasi masalah ini, buat kembali
test.partInnodbTable
tabel, tempatkan partisi yang menyinggungp1
di tablespace. file-per-tablemysql > 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 SQL versi Saya terbaru
Di My SQL 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
, yang telah diganti dengan ST_*
fungsi yang setara. Dalam kasus ini, Anda memodifikasi objek database untuk menggunakan penamaan prosedur baru. Untuk informasi selengkapnya, lihat Fitur yang dihapus di SQL 8.0Saya di SQL dokumentasi Saya. 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: POLYGONFROMTEXTdan POINTFROMTEXT . Ini juga menyarankan agar Anda menggunakan ST_ POLYGONFROMTEXT dan ST_ baru POINTFROMTEXT sebagai pengganti . Setelah membuat ulang prosedur menggunakan saran, precheck selesai dengan sukses. { "id": "removedFunctionsCheck", "title": "Usage of removed functions", "status": "OK", "detectedProblems": [] },
catatan
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 SQL sintaks saya untuk objek seperti rutinitas
SQL8.0 saya memperkenalkan kata kunci cadangan
yang tidak dipesan 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 literaldalam dokumentasi SayaSQL. 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 My SQL 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
Ketidakkonsistenan skema yang dihasilkan dari penghapusan file atau korupsi
Seperti dijelaskan sebelumnya, My SQL 8.0 memperkenalkan Atomic Data Dictionary
, yang menyimpan semua metadata dalam satu set tabel InnoDB internal dalam skema. mysql
Arsitektur baru ini menyediakan cara transaksional ACIDyang sesuai untuk mengelola metadata database, memecahkan masalah “atomDDL” dari pendekatan berbasis file lama. Sebelum My SQL 8.0, objek skema mungkin menjadi yatim piatu jika operasi tiba-tiba terputus. DDL 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
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang 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 Saya SQL ().information_schema.TABLES
Aurora My SQL precheck yang melaporkan kesalahan
Precheck berikut khusus untuk SQL Aurora My:
- auroraCheckDDLRecovery
-
Tingkat precheck: Kesalahan
Periksa artefak yang terkait dengan fitur pemulihan DDL Aurora
Sebagai bagian dari implementasi pemulihan Data Definition Language (DDL) di Aurora MySQL, metadata pada DDL pernyataan dalam penerbangan dipertahankan dalam
ddl_log_md_table
danddl_log_table
tabel dalam skema.mysql
Implementasi DDL pemulihan Aurora tidak didukung untuk versi 3 dan seterusnya, karena fungsinya adalah bagian dari implementasi Atomic Data Dictionarybaru di My SQL 8.0. Jika Anda memiliki DDL pernyataan yang berjalan selama pemeriksaan kompatibilitas, precheck ini mungkin gagal. Kami menyarankan Anda mencoba upgrade sementara tidak ada DDL pernyataan yang berjalan. Jika precheck ini gagal tanpa DDL pernyataan yang berjalan, buka kasus dengan AWS Support
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang baru. Jika ada DDL pernyataan 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 penerbangan DDL berjalan bersamaan dengan pemeriksaan kompatibilitas. Kami menyarankan Anda mencoba lagi upgrade tanpa DDLs berjalan.
- auroraCheckRdsUpgradePrechecksTable
-
Tingkat precheck: Kesalahan
Periksa keberadaan
mysql.rds_upgrade_prechecks
tabelIni 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
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang baru. { "id": "auroraCheckRdsUpgradePrechecksTable", "title": "Check existence of mysql.rds_upgrade_prechecks table", "status": "OK", "detectedProblems": [] }
- auroraFODUpgradeMemeriksa
-
Tingkat precheck: Kesalahan
Periksa artefak yang terkait dengan fitur cepat DDL Aurora
DDLPengoptimalan Cepat diperkenalkan dalam mode lab pada Aurora My SQL versi 2 untuk meningkatkan efisiensi beberapa DDL operasi. Di Aurora My SQL versi 3, mode lab telah dihapus, dan DDL implementasi Cepat telah digantikan oleh fitur My SQL 8.0 yang disebut Instan. DDL
Sebelum memutakhirkan ke Aurora SQL My versi 3, tabel apa pun yang menggunakan DDL Fast in lab mode harus dibangun kembali dengan menjalankan
OPTIMIZE TABLE
perintahALTER TABLE ... ENGINE=InnoDB
or untuk memastikan kompatibilitas dengan Aurora My versi 3. SQLPrecheck 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 <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again." } ] }
Precheck melaporkan bahwa tabel
test.test
memiliki DDL operasi Cepat yang tertunda.Untuk memungkinkan pemutakhiran dilanjutkan, Anda dapat membangun kembali tabel, lalu coba lagi pemutakhiran.
catatan
Sebelum membangun kembali ruang tabel, lihat DDLOperasi online
di SQL dokumentasi Saya 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 menggantungSebelum My SQL 5.6.26, ada kemungkinan bahwa setelah menjatuhkan indeks pencarian teks lengkap,
FTS_DOC_ID_INDEX
kolom tersembunyiFTS_DOC_ID
dan akan menjadi yatim piatu. Untuk informasi selengkapnya, lihat Bug #76012. Jika Anda memiliki tabel yang dibuat pada versi My sebelumnya SQL di mana ini terjadi, itu dapat menyebabkan peningkatan ke Aurora SQL My 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 My 8.0. SQL 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. GunakanOPTIMIZE TABLE test.table_with_fts_index
atauALTER 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
filePrecheck ini hanya berlaku untuk Aurora SQL My versi 3.03.0 dan yang lebih rendah. Jika Anda mengalami kesalahan dengan precheck ini, tingkatkan ke Aurora SQL My 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, ketika Anda menambahkan indeks teks lengkap
ke tabel InnoDB, sejumlah ruang tabel indeks tambahan dibuat. Karena bug di versi My sebelumnyaSQL, yang diperbaiki di versi 5.6.20, ada kemungkinan bahwa tabel indeks tambahan ini dibuat di tablespace sistem, bukan ruang meja 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 tambahan (FTS) di tablespace sistem.Setelah Anda menjatuhkan dan membuat ulang FTS indeks yang terkait dengan tabel ini, precheck berhasil.
catatan
Sebelum membangun kembali ruang tabel, lihat Mempartisi operasi
dalam SQL dokumentasi Saya 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 instans Aurora My SQL version 2 DB mengalami shutdown yang bersih
. 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 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 SQLpernyataan transaksi XAdalam dokumentasi SayaSQL. Untuk informasi selengkapnya tentang status transaksi XA, lihat status transaksi XA di dokumentasi SayaSQL. 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
dan output untuk informasi lebih lanjut. XA RECOVER
penting
Sebelum melakukan atau mengembalikan transaksi, kami sarankan Anda meninjau SQLdokumentasi Saya
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 Versi SQL saya 2.12.0 atau 2.12.1, di mana kelas instans DB penulis adalah db.r6i.32xlarge, saat ini tidak didukung. Dalam hal ini, precheck mengembalikan kesalahan. Untuk memungkinkan peningkatan dilanjutkan, Anda dapat mengubah kelas instans DB Anda menjadi db.r6i.24xlarge atau lebih kecil. Atau Anda dapat meningkatkan ke Aurora My SQL versi 2.12.2 atau lebih tinggi, di mana upgrade di tempat ke Aurora SQL My 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 di Aurora My versi 2.12.1. SQL
- auroraUpgradeCheckForInternalUsers
-
Tingkat precheck: Kesalahan
Periksa 8.0 pengguna internal
Precheck ini hanya berlaku untuk Aurora SQL My versi 3.03.0 dan yang lebih rendah. Jika Anda mengalami kesalahan dengan precheck ini, tingkatkan ke Aurora SQL My versi 3.04 atau lebih tinggi.
Contoh keluaran:
{ "id": "auroraUpgradeCheckForInternalUsers", "title": "Check for 8.0 internal users.", "status": "OK", "detectedProblems": [] }
- auroraUpgradeCheckForMasterUser
-
Tingkat precheck: Kesalahan
Periksa apakah pengguna RDS master ada
SQL8 saya telah menambahkan model hak istimewa baru dengan dukungan untuk peran
dan hak istimewa dinamis untuk membuat manajemen hak istimewa lebih mudah dan lebih halus. Sebagai bagian dari perubahan ini, Aurora My SQL telah memperkenalkan yang baru rds_superuser_role
, yang secara otomatis diberikan kepada pengguna master database pada peningkatan dari Aurora My SQL versi 2 ke versi 3.Untuk informasi selengkapnya tentang peran dan hak istimewa yang diberikan kepada pengguna utama di Aurora SQL My, lihat. Hak akses akun pengguna master Untuk informasi lebih lanjut tentang model hak istimewa berbasis peran di Aurora My SQL versi 3, lihat. Model hak akses berbasis peran
Precheck ini memverifikasi bahwa pengguna master ada dalam database. Jika pengguna master tidak ada, precheck gagal. Untuk memungkinkan peningkatan 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, lihatMengubah kata sandi untuk pengguna master database.
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-passwordmy-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
Mulai My SQL 8.0.12
, Anda tidak dapat lagi membuat indeks awalan pada kolom menggunakan tipe data. GEOMETRY Untuk informasi lebih lanjut, lihat WL #11808 . Jika ada indeks seperti itu, upgrade 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 My SQL 8.0, nama database, nama tabel, dan objek lain berhubungan dengan file di direktori data, yaitu metadata berbasis file. Sebagai bagian dari upgrade ke My SQL 8.0, semua objek database dimigrasikan ke tabel kamus data internal baru yang disimpan dalam
mysql
skema untuk mendukung Kamus Data Atomyang baru diimplementasikan. Sebagai bagian dari migrasi prosedur tersimpan, definisi prosedur dan isi untuk setiap prosedur divalidasi karena dimasukkan ke dalam kamus data baru. Sebelum My SQL 8, dalam beberapa kasus dimungkinkan untuk membuat rutinitas yang disimpan, atau memasukkan langsung ke dalam
mysql.proc
tabel, prosedur yang berisi karakter khusus. Misalnya, Anda dapat membuat prosedur tersimpan yang berisi komentar dengan karakter spasi yang tidak sesuai dan tidak melanggar. \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
dalamtest
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
adalah sekumpulan objek dan tampilan dalam SQL database Saya yang membantu pengguna memecahkan masalah, mengoptimalkan, dan memantau instance DB mereka. Saat melakukan peningkatan versi utama dari Aurora My SQL versi 2 ke versi 3, tampilan sys
skema dibuat ulang dan diperbarui ke definisi Aurora My versi 3 yang baru. SQLSebagai bagian dari peningkatan, jika ada objek dalam
sys
skema yang didefinisikan menggunakan mesin penyimpanan (sys_config/BASE TABLE
di INFORMATION_SCHEMA. TABLES), daripada tampilan, peningkatan 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 InnoDB atau tabel Saya. ISAM 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
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
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
di My SQL adalah 64 karakter. Sebelum My SQL 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 kolomcol2_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 ditentukan dengan panjang awalan lebih besar dari 255 byte pada kolom kecil
Saat membuat indeks pada kolom menggunakan tipe data biner
di MySQL, Anda harus menambahkan panjang awalan dalam definisi indeks. Sebelum My SQL 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
danTINYBLOB
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 InnoDBdi dokumentasi SayaSQL. Jika precheck ini gagal, jatuhkan indeks yang menyinggung atau kurangi panjang awalan
TINYTEXT
danTINYBLOB
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 IndeksPRIMARY
yang memiliki awalan lebih besar dari 255 byte pada kolom atau. TINYTEXT TINYBLOBMelihat definisi untuk tabel ini, kita dapat melihat bahwa kunci utama memiliki awalan 65 pada
TINYTEXT
kolomcol1
. Karena tabel didefinisikan menggunakan setutf8mb4
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
untuk meminta agar inkonsistensi metadata diselesaikan. Atau, Anda dapat mencoba lagi pemutakhiran dengan melakukan dump logis, lalu memulihkan ke cluster DB Aurora My SQL versi 3 yang baru.
Peringatan
Prechecks berikut menghasilkan peringatan ketika precheck gagal, tetapi upgrade dapat dilanjutkan.
SQLPrecheck saya yang melaporkan peringatan
Precheck berikut berasal dari Community MySQL:
- defaultAuthenticationPlugin
-
Tingkat precheck: Peringatan
Pertimbangan plugin otentikasi default baru
Di My SQL 8.0, plugin
caching_sha2_password
otentikasi diperkenalkan, menyediakan enkripsi kata sandi yang lebih aman dan kinerja yang lebih baik daripada plugin yang tidak digunakan lagi.mysql_native_password
Untuk Aurora My SQL 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 dalam dokumentasi Saya. SQL 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 My SQL 8.0, sejumlah opsi variabel sistem sql_mode yang tidak digunakan
lagi telah dihapus, salah satunya adalah. MAXDB
Precheck ini memeriksa semua sesi yang terhubung saat ini, bersama dengan rutinitas dan pemicu, untuk memastikan bahwa tidak ada yangsql_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 didukungsql_mode
.Setelah masuk ke database, Anda dapat melihat dalam definisi rutin yang
sql_mode
berisiMAXDB
.> 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.catatan
Menurut SQLdokumentasi Saya
, My SQL menyimpan sql_mode
pengaturan yang berlaku ketika rutinitas dibuat atau diubah. Itu selalu menjalankan rutinitas dengan pengaturan ini, terlepas darisql_mode
pengaturan ketika rutinitas dimulai.Sebelum mengubah
sql_mode
, lihat SQLMode serverdi SQL dokumentasi Saya. 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 My SQL 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 My SQL 8.4pengidentifikasi seperti 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 dalamtest
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, 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 ke My 8.0. SQL Tinjau aplikasi Anda untuk mengonfirmasi, menguji klon atau snapshot klaster Aurora My SQL DB 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
karakterDi My SQL 8.0 set
utf8mb3
karakter tidak digunakan lagi, dan akan dihapus di versi My major future. SQL Precheck ini diimplementasikan untuk memunculkan peringatan jika ada objek database yang menggunakan set karakter ini terdeteksi. Meskipun ini tidak akan memblokir peningkatan untuk melanjutkan, kami sangat menyarankan Anda berpikir tentang memigrasikan tabel ke setutf8mb4
karakter, yang merupakan default pada My SQL 8.0. Untuk informasi selengkapnya tentang utf8mb3 dan utf8mb4, lihat Mengonversi antara set karakter Unicode 3-byte dan 4-byte dalam dokumentasi Saya. SQL 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 lebih lanjut dan prasyarat sebelum melakukannya, lihat Mengonversi antara set karakter Unicode 3-byte dan 4-byte
dalam dokumentasi Saya. SQL - zeroDatesCheck
-
Tingkat precheck: Peringatan
Nilai tanggal nol, datetime, dan stempel waktu
SQLSekarang saya memberlakukan aturan yang lebih ketat mengenai penggunaan nilai nol di kolom tanggal, datetime, dan stempel waktu. Kami menyarankan Anda menggunakan
NO_ZERO_DATE SQL
modeNO_ZERO_IN_DATE
dan dalam hubungannya denganstrict
mode, karena mereka akan digabungkan denganstrict
mode di rilis Saya SQL 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 My SQL precheck yang melaporkan peringatan
Precheck berikut khusus untuk SQL Aurora My:
- auroraUpgradeCheckForRollbackSegmentHistoryLength
-
Tingkat precheck: Peringatan
Memeriksa apakah panjang daftar riwayat segmen rollback untuk cluster tinggi
Seperti disebutkan dalam auroraUpgradeCheckForIncompleteXATransactions, saat menjalankan proses peningkatan versi utama, penting bahwa instans Aurora My SQL version 2 DB menjalani shutdown yang bersih
. 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 yang tinggi (HLL), itu dapat memperpanjang jumlah waktu yang dibutuhkan InnoDB untuk menyelesaikan pembersihan catatan log undo, 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 dengan cermat HLL pada cluster DB Anda. Menjaga pada tingkat rendah mengurangi waktu henti yang diperlukan selama peningkatan versi utama. Untuk informasi lebih lanjut tentang pemantauanHLL, lihatPanjang daftar riwayat InnoDB meningkat secara signifikan.
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 HLL undo InnoDB 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 pada cluster DB Anda sebelum menjalankan upgrade dalam produksi, untuk memastikan Anda HLL disimpan pada ukuran yang dapat dikelola.
- auroraUpgradeCheckForUncommittedRowModifications
-
Tingkat precheck: Peringatan
Memeriksa apakah ada banyak modifikasi baris yang tidak berkomitmen
Seperti disebutkan dalam auroraUpgradeCheckForIncompleteXATransactions, saat menjalankan proses peningkatan versi utama, penting bahwa instans Aurora My SQL version 2 DB menjalani shutdown yang bersih
. 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
. 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 SQL dokumentasi Saya 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 lebih lanjut tentang mengoptimalkan manajemen transaksi InnoDB, dan dampak potensial dari menjalankan dan memutar kembali transaksi besar pada instans database SQL Saya, lihat Mengoptimalkan manajemen transaksi InnoDB
dalam dokumentasi Saya. SQL
Pemberitahuan
Precheck berikut menghasilkan pemberitahuan ketika precheck gagal, tetapi upgrade dapat dilanjutkan.
- sqlModeFlagMemeriksa
-
Tingkat precheck: Pemberitahuan
Penggunaan bendera usang
sql_mode
Selain itu
MAXDB
, sejumlahsql_mode
opsi lain telah dihapus: DB2
,,MSSQL
,MYSQL323
,MYSQL40
,ORACLE
,POSTGRESQL
,NO_FIELD_OPTIONS
NO_KEY_OPTIONS
, danNO_TABLE_OPTIONS
. Pada My SQL 8.0, tidak satu pun dari nilai-nilai ini dapat ditetapkan ke variabelsql_mode
sistem. Jika precheck ini menemukan sesi terbuka menggunakansql_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 Saya. SQLContoh keluaran:
{ "id": "sqlModeFlagCheck", "title": "Usage of obsolete sql_mode flags", "status": "OK", "detectedProblems": [] }
Untuk mengatasi salah satu kegagalan precheck ini, lihat 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
perintahSebelum memulai upgrade ke Aurora My SQL versi 3,
check table for upgrade
dijalankan pada setiap tabel dalam skema pengguna di cluster DB Anda. Precheck ini tidak sama dengan checkTableMysqlSchema.check table for upgrade
Perintah memeriksa tabel untuk setiap potensi masalah yang mungkin timbul selama peningkatan ke versi My yang lebih baru. SQL 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 target Versi saya SQL
-
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 CHECKTABLEpernyataandi SQL dokumentasi Saya. 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 kuncifk_pname
asing dalamtest.child
tabel, yang mereferensikantest.parent
tabel, memiliki indeks yang hilang atau ketidakcocokan tipe data. SQLDokumentasi saya tentang batasan kunci asingmenyatakan bahwa kolom yang direferensikan dalam kunci asing harus memiliki indeks terkait, dan kolom induk/anak harus menggunakan tipe data yang 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.
Setelah melakukannya, kita dapat melihat bahwa batasan anak di question ( fk_pname
) digunakanp_name varchar(20) CHARACTER SET latin1 DEFAULT NULL
untuk mereferensikan tabel induk.name varchar(20) NOT NULL
Tabel induk menggunakanDEFAULT CHARSET=utf8
, tetapip_name
kolom tabel anak menggunakanlatin1
, 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 definisip_name
kolom, kami menjalankanALTER 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 ditest.orders
atas meja karena tidak memilikiCREATED
atribut. Menurut Memeriksa kompatibilitas versidalam SQL dokumentasi Saya, pesan ini bersifat informasi, dan dicetak untuk pemicu yang dibuat sebelum My SQL 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": [] },
-