MYSQL 8.0 Upgrade &Downgrade的幾點注意
Important
Downgrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to a previous MySQL 8.0 release, is not supported.
The only supported alternative is to restore a backup taken
before
upgrading. It is therefore imperative that you back up your data before starting the upgrade process.
Upgrade Paths
- Upgrade from MySQL 5.7 to 8.0 is supported. However, upgrade is only supported between General Availability (GA) releases. For MySQL 8.0, it is required that you upgrade from a MySQL 5.7 GA release (5.7.9 or higher). Upgrades from non-GA releases of MySQL 5.7 are not supported.
- Upgrading to the latest release is recommended before upgrading to the next version. For example, upgrade to the latest MySQL 5.7 release before upgrading to MySQL 8.0.
- Upgrade that skips versions is not supported. For example, upgrading directly from MySQL 5.6 to 8.0 is not supported.
- Once a release series reaches General Availability (GA) status, upgrade within the release series (from one GA version to another GA version) is supported.
Some changes to the responsibility for step 2 occurred in MySQL 8.0.16:
- Prior to MySQL 8.0.16, upgrades the Performance Schema, the INFORMATION_SCHEMA, and the objects described in step 2. The DBA is expected to invoke manually after starting the server.
- As of MySQL 8.0.16, the server performs all tasks previously handled by . Although upgrading remains a two-step operation, the server performs them both, resulting in a simpler process.
Depending on the version of MySQL to which you are upgrading, the instructions in
and
indicate whether the server performs all upgrade tasks or whether you must also invoke
When upgrading from MySQL 5.7 to MySQL 8.0, any undo tablespaces that exist in the MySQL 5.7 instance are removed and replaced by two new default undo tablespaces.
Due to a regression introduced in MySQL 8.0.14, in-place upgrade on a case-sensitive file system from MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to MySQL 8.0.16 failed for instances with partitioned tables and [lower_case_table_names=1](). The failure was caused by a case mismatch issue related to partitioned table file names. The fix that introduced the regression was reverted, which permits upgrades to MySQL 8.0.17 from MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to function as normal. However, the regression is still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.
Changed Server Defaults
Option/Parameter |
Old Default |
New Default |
Server changes |
|
|
|
latin1 |
utf8mb4 |
|
latin1_swedish_ci |
utf8mb4_0900_ai_ci |
|
OFF |
ON |
|
16KB |
1MB |
|
OFF |
ON |
|
-1 (autosize) changed from : back_log = 50 + (max_connections / 5) |
-1 (autosize) changed to : back_log = max_connections |
|
4194304 (4MB) |
67108864 (64MB) |
|
64 |
1024 |
|
OFF |
ON |
|
2000 |
4000 |
|
3 (Notes) |
2 (Warning) |
InnoDB changes |
|
|
|
0 |
2 |
|
OFF |
ON |
|
NULL |
fsync (Unix), unbuffered (Windows) |
|
1 (consecutive) |
2 (interleaved) |
|
1 (enable) |
0 (disable) |
|
0 (%) |
10 (%) |
|
75 (%) |
90 (%) |
Performance Schema changes |
|
|
performance-schema-instrument='wait/lock/metadata/sql/%=ON' |
OFF |
ON |
performance-schema-instrument='memory/%=COUNTED' |
OFF |
COUNTED |
performance-schema-consumer-events-transactions-current=ON |
OFF |
ON |
performance-schema-consumer-events-transactions-history=ON |
OFF |
ON |
performance-schema-instrument='transaction%=ON' |
OFF |
ON |
Replication changes |
|
|
|
OFF |
ON |
|
0 |
1 |
|
OFF |
ON |
|
0 |
30 |
|
FILE |
TABLE |
|
FILE |
TABLE |
|
OFF |
XXHASH64 |
|
INDEX_SCAN, TABLE_SCAN |
INDEX_SCAN, HASH_SCAN |
|
16M |
128M |
1000 |
0 | |
Group Replication changes |
|
|
|
0 |
3 |
|
ABORT_SERVER |
READ_ONLY |
|
0 |
5 |
- To check for these issues, execute this command:
mysqlcheck -u root -p --all-databases --check-upgrade
If
reports any errors, correct the issues.
Upgrade Troubleshooting
· A schema mismatch in a MySQL 5.7 instance between the .frm file of a table and the
InnoDB
data dictionary can cause an upgrade to MySQL 8.0 to fail. Such mismatches may be due to .frm file corruption. To address this issue, dump and restore affected tables before attempting the upgrade again.
· If problems occur, such as that the new
server does not start, verify that you do not have an old my.cnf file from your previous installation. You can check this with the
option (for example,
). If this command displays anything other than the program name, you have an active my.cnf file that affects server or client operation.
· If, after an upgrade, you experience problems with compiled client programs, such as
Commands out of sync
or unexpected core dumps, you probably have used old header or library files when compiling your programs. In this case, check the date for your mysql.h file and libmysqlclient.a library to verify that they are from the new MySQL distribution. If not, recompile your programs with the new headers and libraries. Recompilation might also be necessary for programs compiled against the shared client library if the library major version number has changed (for example, from libmysqlclient.so.20 to libmysqlclient.so.21).
· If you have created a loadable function with a given name and upgrade MySQL to a version that implements a new built-in function with the same name, the loadable function becomes inaccessible. To correct this, use
to drop the loadable function, and then use
to re-create the loadable function with a different nonconflicting name. The same is true if the new version of MySQL implements a built-in function with the same name as an existing stored function. See
, for the rules describing how the server interprets references to different kinds of functions.
· If upgrade to MySQL 8.0 fails due to any of the issues outlined in
, the server reverts all changes to the data directory. In this case, remove all redo log files and restart the MySQL 5.7 server on the existing data directory to address the errors. The redo log files (ib_logfile*) reside in the MySQL data directory by default. After the errors are fixed, perform a slow shutdown (by setting
) before attempting the upgrade again.
mysqlcheck --repair --databases _db_name
mysqlcheck --repair --all-databases
Downgrading MySQL
Downgrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to a previous MySQL 8.0 release, is not supported. The only supported alternative is to restore a backup taken
before
upgrading. It is therefore imperative that you back up your data before starting the upgrade process.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29863023/viewspace-2838065/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Cisco ACI APIC upgrade downgrade pathAPI
- MYSQL索引建立需要注意以下幾點細節MySql索引
- 把資料從MySQL遷到Oracle的幾點注意事項MySqlOracle
- 分享mysql注意點MySql
- 手機網站的幾點注意網站
- 關於CORS 應該注意的幾點CORS
- 使用Array.prototype.indexOf()的幾點注意Index
- aix 上做rac的幾個注意點AI
- Collectors.toMap的幾個注意點
- spark效能優化幾點注意Spark優化
- MySQL的clone(克隆)要注意的點MySql
- 關於MongoDB的幾點注意事項UMMongoDB
- Python Enum 使用的幾點注意事項Python
- vmware搭建HMC需要注意的幾個點
- Nginx模組fastcgi_cache的幾個注意點NginxAST
- MySQL中explain的幾點用法MySqlAI
- Downgrade the DatabaseDatabase
- Spring事務需要注意的幾個點Spring
- iOS編碼需要注意的幾點問題iOS
- 關於code::blocks的幾點注意 part1BloC
- mysql寫function時的注意點記錄MySqlFunction
- 搭建前後需要注意哪幾點?
- Python面試中需要注意的幾點事項!Python面試
- SEO中網站微創新的幾個注意點網站
- 伺服器打補丁需要注意的幾點伺服器
- 開發者提交產品前需要注意的幾個點
- 選擇硬體防火牆應注意的幾點事宜防火牆
- 成功接專案需要注意的幾個要點
- C#基本型別使用時的幾個注意點C#型別
- 幾點需要注意選擇APP開發外包團隊的注意事項APP
- 網站提示有風險?注意做好這幾點!網站
- Oracle與MySQL的幾點區別(轉)OracleMySql
- 現在做網站時應注意的幾點重要事項?網站
- 也談談規範,JS程式碼的幾個注意點JS
- 構建高效能的介面模組需要注意的幾點
- 應用 Laravel 的軟刪除你需要注意的幾點Laravel
- 不可不知的 MySQL 升級利器及 5.7 升級到 8.0 的注意事項MySql
- MySQL 基礎篇需要注意的點(小白篇)MySql