Referensi deskripsi precheck untuk Aurora My SQL - Amazon Aurora

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.

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 untuk mysql skema

Sebelum memulai upgrade ke Aurora My SQL versi 3, check table for upgrade dijalankan pada setiap tabel dalam mysql skema pada instance DB. check table for upgradePerintah 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. SQL

Contoh keluaran:

{ "id": "circularDirectory", "title": "Circular directory references in tablespace data file paths", "status": "OK", "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.", "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes", "detectedProblems": [ { "level": "Error", "dbObject": "ts2", "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'", "dbObjectType": "Tablespace" } ] }

Jika Anda menerima kesalahan ini, buat kembali tabel Anda menggunakan file-per-table tablespace. 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 TEXTGEOMETRY, dan JSON 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 dalam test.test_blob_default tabel menggunakanBLOB,, TEXTGEOMETRY, atau tipe JSON 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 online di 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 berisiQUERY CACHE,SQL_CACHE, atau SQL_NO_CACHE kata kunci, kesalahan precheck dikembalikan. Untuk mengatasi masalah ini, buat ulang objek ini, hapus kata kunci yang disebutkan.

Contoh keluaran:

{ "id": "depreciatedSyntaxCheck", "title": "Usage of depreciated keywords in definition", "status": "OK", "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.", "detectedProblems": [ { "level": "Error", "dbObject": "test.no_query_cache_check", "description": "PROCEDURE uses depreciated words in definition" } ] }

Precheck melaporkan bahwa prosedur yang test.no_query_cache_check disimpan menggunakan salah satu kata kunci yang dihapus. Melihat definisi prosedur, kita dapat melihat bahwa ia 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

ENUMdan definisi SET kolom yang mengandung elemen yang lebih panjang dari 255 karakter

Tabel dan prosedur yang disimpan tidak boleh memiliki ENUM atau elemen SET kolom melebihi 255 karakter atau 1020 byte. Sebelum 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 dalam test.large_set tabel berisi SET elemen yang lebih besar dari 255 karakter.

Setelah mengurangi SET ukuran untuk kolom ini, precheck berlalu, memungkinkan peningkatan untuk melanjutkan.

{ "id": "enumSetElementLenghtCheck", "title": "ENUM/SET column definitions containing elements longer than 255 characters", "status": "OK", "detectedProblems": [] },
foreignKeyLengthMemeriksa

Tingkat precheck: Kesalahan

Nama kendala kunci asing lebih panjang dari 64 karakter

Di MySQL, panjang pengidentifikasi dibatasi hingga 64 karakter, 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.

DEFINERAtribut 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, jika DEFINER 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 acara karena memiliki null definer.

Untuk mengatasi ini, Anda dapat memeriksa definisi acara. Seperti yang Anda lihat, definernya kosong null atau kosong.

mysql> select db,name,definer from mysql.event where name='get_version'; +------+-------------+---------+ | db | name | definer | +------+-------------+---------+ | test | get_version | | +------+-------------+---------+ 1 row in set (0.00 sec)

Jatuhkan atau buat ulang acara dengan definer yang valid.

catatan

Sebelum menjatuhkan atau mendefinisikan ulangDEFINER, tinjau dan periksa aplikasi dan persyaratan hak istimewa Anda dengan cermat. Untuk informasi selengkapnya, lihat Kontrol akses objek tersimpan di 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 bisa null atau kosong.

Precheck memvalidasi bahwa database Anda tidak memiliki pemicu yang didefinisikan dengan null atau definer kosong. Untuk informasi selengkapnya tentang persyaratan definer untuk objek yang disimpan, lihat getEventsWithNullDefiner.

Contoh keluaran:

{ "id": "getTriggersWithNullDefiner", "title": "The definer column for information_schema.triggers cannot be null or blank.", "status": "OK", "detectedProblems": [ { "level": "Error", "dbObject": "test.example_trigger", "description": "Set definer for trigger example_trigger in Schema test" } ] }

Precheck mengembalikan kesalahan karena example_trigger pemicu dalam test skema memiliki definer. null Untuk memperbaiki masalah ini, perbaiki definer dengan membuat ulang pemicu dengan pengguna yang valid, atau lepaskan pelatuknya. Untuk informasi selengkapnya, lihat contoh di getEventsWithNullDefiner.

catatan

Sebelum menjatuhkan atau mendefinisikan ulangDEFINER, tinjau dan periksa aplikasi dan persyaratan hak istimewa Anda dengan cermat. Untuk informasi selengkapnya, lihat Kontrol akses objek tersimpan di 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 ketikalower_case_table_names = 1, semua tabel disimpan di disk dalam huruf kecil. Jika tidak, kesalahan precheck dikembalikan, dan Anda harus memperbaiki metadata sebelum melanjutkan dengan peningkatan.

Contoh keluaran:

{ "id": "getValueOfVariablelower_case_table_names", "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.", "status": "OK", "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.", "detectedProblems": [ { "level": "Error", "dbObject": "test.TEST", "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1" } ] }

Kesalahan dikembalikan karena tabel test.TEST berisi huruf besar, tetapi lower_case_table_names diatur ke. 1

Untuk mengatasi masalah ini, Anda dapat mengganti nama tabel untuk menggunakan huruf kecil, atau memodifikasi lower_case_table_names parameter pada cluster DB sebelum memulai pemutakhiran.

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 dihapus

Pada My SQL 8.0.13, usang ASC atau DESC sintaks untuk klausa telah dihapus. GROUP BY Kueri yang mengandalkan GROUP BY penyortiran sekarang dapat menghasilkan hasil yang berbeda. Untuk mendapatkan urutan pengurutan tertentu, gunakan ORDER BY klausa sebagai gantinya. Jika ada objek yang ada dalam database Anda menggunakan sintaks ini, Anda harus membuat ulang mereka menggunakan ORDER BY klausa sebelum mencoba kembali upgrade. Untuk informasi selengkapnya, lihat SQLperubahan dalam 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 dalam test database karena berisi sintaks usang.

Setelah Anda memperbaiki rutinitas, precheck berhasil, dan Anda dapat mencoba lagi upgrade.

mysqlIndexTooLargeCheck

Tingkat precheck: Kesalahan

Periksa indeks yang terlalu besar untuk bekerja pada 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 keBarracuda. dynamic Ini adalah default di My 5.7. SQL Untuk informasi selengkapnya, lihat format baris InnoDB dan manajemen format file 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 mysqlcheck terhadap skema dan tabel yang dikembalikan.

catatan

Pastikan Anda menggunakan versi My SQL 5.7mysqlcheck, karena -- fix-db-names dan -- fix-table-names telah 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 dalam dropped_db database adalah yatim piatu.

Untuk membersihkan prosedur ini, Anda dapat membuat ulang skema yang hilang.

mysql> create database dropped_db; Query OK, 1 row affected (0.01 sec)

Setelah skema dibuat ulang, Anda dapat menghentikan prosedur untuk memungkinkan peningkatan dilanjutkan.

{ "id": "mysqlOrphanedRoutinesCheck", "title": "Check for orphaned routines in 5.7", "status": "OK", "detectedProblems": [] },
mysqlSchemaCheck

Tingkat precheck: Kesalahan

Nama tabel dalam mysql skema yang bertentangan dengan tabel baru di My 8.0 SQL

Kamus 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 internal baru dibuat dalam mysql skema. Untuk menghindari tabrakan penamaan, yang akan mengakibatkan kegagalan pemutakhiran, precheck memeriksa semua nama tabel dalam mysql skema untuk memastikan bahwa tidak ada nama tabel baru yang sudah digunakan. Jika ya, kesalahan dikembalikan, dan pemutakhiran tidak diizinkan untuk dilanjutkan.

Contoh keluaran:

{ "id": "mysqlSchema", "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.", "status": "OK", "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.", "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html", "detectedProblems": [ { "level": "Error", "dbObject": "mysql.tablespaces", "description": "Table name used in mysql schema.", "dbObjectType": "Table" } ] }

Kesalahan dikembalikan karena ada tabel bernama tablespaces dalam mysql skema. Ini adalah salah satu nama tabel kamus data internal baru di 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 kembali tabel 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": [] }
partitionedTablesInBerbagi TablespaceCheck

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 tabel test.partInnoDBTable ada di tablespace sistem.

Untuk mengatasi masalah ini, buat kembali test.partInnodbTable tabel, tempatkan partisi yang menyinggung p1 di tablespace. file-per-table

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1 -> INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table); Query OK, 0 rows affected, 1 warning (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0

Setelah melakukannya, precheck berlalu.

{ "id": "partitionedTablesInSharedTablespaceCheck", "title": "Usage of partitioned tables in shared tablespaces", "status": "OK", "detectedProblems": [] }
removedFunctionsCheck

Tingkat precheck: Kesalahan

Penggunaan fungsi yang telah dihapus dari 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.0 Saya 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 literal dalam 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 bernamaexcept, 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 dan ddl_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 Dictionary baru 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 tabel

Ini adalah precheck internal saja yang dilakukan oleh layanan. RDS Kesalahan apa pun akan ditangani secara otomatis saat upgrade dan dapat diabaikan dengan aman.

Jika Anda menemukan kesalahan dengan precheck ini, buka kasus dengan AWS Support 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 perintah ALTER TABLE ... ENGINE=InnoDB or untuk memastikan kompatibilitas dengan Aurora My versi 3. SQL

Precheck ini mengembalikan daftar tabel tersebut. Setelah tabel yang dikembalikan telah dibangun kembali, Anda dapat mencoba kembali upgrade.

Contoh keluaran:

{ "id": "auroraFODUpgradeCheck", "title": "Check for artifacts related to Aurora fast DDL feature", "status": "OK", "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature", "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2", "detectedProblems": [ { "level": "Error", "dbObject": "test.test", "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <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 menggantung

Sebelum My SQL 5.6.26, ada kemungkinan bahwa setelah menjatuhkan indeks pencarian teks lengkap, FTS_DOC_ID_INDEX kolom tersembunyi FTS_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. Gunakan OPTIMIZE 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 file

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": "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 menggunakanXA RECOVER, lihat SQLpernyataan transaksi XA dalam 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 barurds_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-password my-new-password

Kemudian precheck berhasil.

{ "id": "auroraUpgradeCheckForMasterUser", title": "Check if master user exists", "status": "OK", "detectedProblems": [] }
auroraUpgradeCheckForPrefixIndexOnGeometryColumns

Tingkat precheck: Kesalahan

Periksa kolom geometri pada indeks awalan

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 Atom yang 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 dalam test database yang berisi karakter khusus dalam badan prosedur.

Setelah menjatuhkan dan membuat ulang prosedur yang disimpan, precheck berhasil, memungkinkan peningkatan untuk melanjutkan.

{ "id": "auroraUpgradeCheckForSpecialCharactersInProcedures", "title": "Check for inconsistency related to special characters in stored procedures.", "status": "OK", "detectedProblems": [] },
auroraUpgradeCheckForSysSchemaObjectTypeMismatch

Tingkat precheck: Kesalahan

Periksa ketidakcocokan tipe objek untuk skema sys

Skema sys 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. SQL

Sebagai bagian dari peningkatan, jika ada objek dalam sys skema yang didefinisikan menggunakan mesin penyimpanan (sys_config/BASE TABLEdi 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 kolom col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad yang melebihi panjang kolom maksimum yang diizinkan dari 64 karakter.

Melihat definisi tampilan, kita bisa melihat kolom yang menyinggung.

mysql> desc `test`.`colname_view_test`; +------------------------------------------------------------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------------------------------------------------------+-------------+------+-----+---------+-------+ | col1 | varchar(20) | YES | | NULL | | | col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11) | YES | | NULL | | +------------------------------------------------------------------+-------------+------+-----+---------+-------+ 2 rows in set (0.00 sec)

Untuk memungkinkan pemutakhiran dilanjutkan, buat ulang tampilan, pastikan panjang kolom tidak melebihi 64 karakter.

mysql> drop view `test`.`colname_view_test`; Query OK, 0 rows affected (0.01 sec) mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test; Query OK, 0 rows affected (0.01 sec) mysql> desc `test`.`colname_view_test`; +------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+-------------+------+-----+---------+-------+ | col1 | varchar(20) | YES | | NULL | | | col2_nopad | int(11) | YES | | NULL | | +------------+-------------+------+-----+---------+-------+ 2 rows in set (0.00 sec)

Setelah melakukan ini, precheck berhasil.

{ "id": "auroraUpgradeCheckForViewColumnNameLength", "title": "Check for upperbound limit related to column name in view.", "status": "OK", "detectedProblems": [] }
auroraUpgradeCheckIndexLengthLimitOnTinyColumns

Tingkat precheck: Kesalahan

Periksa tabel dengan indeks yang 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 dan TINYBLOB kolom, di mana ukuran data maksimum yang diizinkan adalah 255 byte, tetapi awalan indeks yang lebih besar dari ini diizinkan. Untuk informasi selengkapnya, lihat batas InnoDB di dokumentasi SayaSQL.

Jika precheck ini gagal, jatuhkan indeks yang menyinggung atau kurangi panjang awalan TINYTEXT dan TINYBLOB kolom indeks menjadi kurang dari 255 byte. Kemudian coba lagi upgrade.

Contoh keluaran:

{ "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns", "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns", "status": "OK", "description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.", "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html", "detectedProblems": [ { "level": "Error", "dbObject": "test.tintxt_prefixed_index.col1", "description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63." } ] }

Precheck melaporkan kesalahan untuk test.tintxt_prefixed_index tabel, karena memiliki Indeks PRIMARY yang memiliki awalan lebih besar dari 255 byte pada kolom atau. TINYTEXT TINYBLOB

Melihat definisi untuk tabel ini, kita dapat melihat bahwa kunci utama memiliki awalan 65 pada TINYTEXT kolomcol1. Karena tabel didefinisikan menggunakan set utf8mb4 karakter, yang menyimpan 4 byte per karakter, awalan melebihi batas 255-byte.

mysql> show create table `test`.`tintxt_prefixed_index`\G *************************** 1. row *************************** Table: tintxt_prefixed_index Create Table: CREATE TABLE `tintxt_prefixed_index` ( `col1` tinytext NOT NULL, `col2` tinytext, `col_id` tinytext, PRIMARY KEY (`col1`(65)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC 1 row in set (0.00 sec)

Memodifikasi awalan indeks ke 63 saat menggunakan set utf8mb4 karakter akan memungkinkan peningkatan untuk melanjutkan.

mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD PRIMARY KEY (`col1`(63)); Query OK, 0 rows affected (0.04 sec) Records: 0 Duplicates: 0 Warnings: 0

Setelah melakukan ini, precheck berhasil.

{ "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns", "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns", "status": "OK", "detectedProblems": [] }
auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable

Tingkat precheck: Kesalahan

Periksa inkonsistensi metadata InnoDB yang hilang untuk tabel mysql.host

Ini adalah precheck internal saja yang dilakukan oleh layanan. RDS Kesalahan apa pun akan ditangani secara otomatis saat upgrade dan dapat diabaikan dengan aman.

Jika Anda menemukan kesalahan dengan precheck ini, buka kasus dengan AWS Support 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 yang sql_mode mengatur kombinasi apa pun yang disertakan. MAXDB

Contoh keluaran:

{ "id": "maxdbFlagCheck", "title": "Usage of obsolete MAXDB sql_mode flag", "status": "OK", "description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.", "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals", "detectedProblems": [ { "level": "Warning", "dbObject": "test.maxdb_stored_routine", "description": "PROCEDURE uses obsolete MAXDB sql_mode", "dbObjectType": "Routine" } ] }

Precheck melaporkan bahwa test.maxdb_stored_routine rutinitas berisi opsi yang tidak 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 dari sql_mode pengaturan ketika rutinitas dimulai.

Sebelum mengubahsql_mode, lihat SQLMode server di 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.4 pengidentifikasi 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 dalam test skema berisi a $ sebagai karakter pertama.

reservedKeywordsCheck

Tingkat precheck: Peringatan

Penggunaan objek database dengan nama yang bertentangan dengan kata kunci baru yang dicadangkan

Pemeriksaan ini mirip dengan routineSyntaxCheck, 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 bernamaexcept, 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 karakter

Di 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 set utf8mb4 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 mode NO_ZERO_IN_DATE dan dalam hubungannya dengan strict mode, karena mereka akan digabungkan dengan strict 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 ituMAXDB, sejumlah sql_mode opsi lain telah dihapus:DB2,,MSSQL,MYSQL323,MYSQL40,ORACLE,POSTGRESQL, NO_FIELD_OPTIONSNO_KEY_OPTIONS, danNO_TABLE_OPTIONS. Pada My SQL 8.0, tidak satu pun dari nilai-nilai ini dapat ditetapkan ke variabel sql_mode sistem. Jika precheck ini menemukan sesi terbuka menggunakan sql_mode pengaturan ini, pastikan bahwa instans DB dan grup parameter cluster DB Anda, serta aplikasi dan konfigurasi klien, diperbarui untuk menonaktifkannya.- Untuk informasi lebih lanjut, lihat dokumentasi Saya. SQL

Contoh 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 perintah

Sebelum 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 upgradePerintah 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 CHECKTABLEpernyataan di 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.logFile 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 ERRORPesan melaporkan bahwa kendala kunci fk_pname asing dalam test.child tabel, yang mereferensikan test.parent tabel, memiliki indeks yang hilang atau ketidakcocokan tipe data. SQLDokumentasi saya tentang batasan kunci asing menyatakan 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) digunakan p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL untuk mereferensikan tabel induk. name varchar(20) NOT NULL Tabel induk menggunakanDEFAULT CHARSET=utf8, tetapi p_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 definisi p_name kolom, kami menjalankan ALTER TABLE untuk memodifikasi set karakter ke. utf8

mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL; Query OK, 0 rows affected (0.06 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> flush tables; Query OK, 0 rows affected (0.01 sec)

Setelah melakukannya, precheck berlalu, dan peningkatan dapat dilanjutkan.

Contoh peringatan:

{ "id": "checkTableOutput", "title": "Issues reported by 'check table x for upgrade' command", "status": "OK", "detectedProblems": [ { "level": "Warning", "dbObject": "test.orders", "description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute." } ] }

Precheck melaporkan peringatan untuk delete_audit_trigg pemicu di test.orders atas meja karena tidak memiliki CREATED atribut. Menurut Memeriksa kompatibilitas versi dalam 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": [] },