mysql從5.7平滑升級到8.0.27的實現(xiàn)
mysql升級過程
上傳到服務(wù)器的/opt/mysql目錄下解壓:
# 文件上傳位置在/opt/mysql/下面 cd /opt/mysql/ # 解壓安裝包 [root@zkmet mysql]# xz -d mysql-8.0.27-linux-glibc2.12-x86_64.tar.xz [root@zkmet mysql]# tar -xvf mysql-8.0.27-linux-glibc2.12-x86_64.tar # 文件夾重命名為mysql8 mv mysql-8.0.27-linux-glibc2.12-x86_64 mysql8 # 安裝包移動(復(fù)制)至原安裝包目錄下,我的是/var/lib/ cp mysql8 /var/lib/ # 更改文件夾所屬 chown -R mysql.mysql /var/lib/mysql8/
更改/etc/my.conf配置,末尾添加關(guān)鍵配置
#for8.0 sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION character-set-server = utf8 collation_server = utf8_general_ci basedir = /var/lib/mysql8 skip_ssl default_authentication_plugin=mysql_native_password
備份數(shù)據(jù)庫、備份數(shù)據(jù)庫、備份數(shù)據(jù)庫。重要的話說三遍
萬事俱備后,按照如下指示進行正式升級。
# 進入原5.7 mysql命令行 正確關(guān)閉數(shù)據(jù)庫 [root@zkmet mysql]# mysql -uroot -p Enter password: mysql> select version(); +------------+ | version() | +------------+ | 5.7.23-log | +------------+ 1 row in set (0.00 sec) mysql> show variables like 'innodb_fast_shutdown'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | innodb_fast_shutdown | 1 | +----------------------+-------+ 1 row in set (0.00 sec) # 確保數(shù)據(jù)都刷到硬盤上,更改成0 mysql> set global innodb_fast_shutdown=0; Query OK, 0 rows affected (0.00 sec) mysql> shutdown; Query OK, 0 rows affected (0.00 sec) mysql> exit Bye
退出至終端 用mysql8.0.19客戶端直接啟動
# 執(zhí)行命令/var/lib/mysql8/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql & [root@zkmet mysql]# /var/lib/mysql8/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql & # 我的一直卡在這個頁面,還以為出錯了,可以另起一個客戶端,登錄到數(shù)據(jù)庫select version();查看數(shù)據(jù)庫版本是否更新成功。 [1] 1787 [root@zkmet mysql]# 2021-11-12T06:32:56.314320Z mysqld_safe Logging to '/var/log/mysqld.log'. 2021-11-12T06:32:56.337533Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 2021-11-12T07:26:29.183302Z mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
卡在上一步可另起客戶端登錄mysql
[root@zkmet etc]# mysql -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 14 Server version: 8.0.27 MySQL Community Server - GPL Copyright (c) 2000, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.27 | +-----------+ 1 row in set (0.01 sec)
到這里其實證明數(shù)據(jù)庫平滑升級成功了。**但是:**再修改一點配置
# 修改PATH變量 [root@zkmet etc]# vi /etc/profile # 將PATH中的/usr/local/mysql/bin改為/usr/local/mysql8/bin # 生效驗證 [root@zkmet etc]# source /etc/profile [root@zkmet etc]# which mysql /var/lib/mysql8/bin/mysql [root@zkmet etc]# mysql -V [root@zkmet etc]# mysql -V mysql Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL)
問題一:
連接數(shù)據(jù)庫報錯:ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2)
[root@zkmet ~]# mysql -uroot -p Enter password: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
解決方式,找到 mysql.sock
[root@zkmet etc]# find / -name mysql.sock /var/lib/mysql/mysql.sock
修改my.conf配置
[mysqld] socket = /var/lib/mysql/mysql.sock [client] socket = /var/lib/mysql/mysql.sock
問題二:
改完my.conf配置后直接重啟mysqld發(fā)現(xiàn)重啟不了
[root@zkmet bin]# service mysqld restart 停止 mysqld: [確定] MySQL Daemon failed to start. 正在啟動 mysqld: [失敗]
查看/var/log/mysqld.log日志
07:47:22 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=151 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68196 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0 thread_stack 0x40000 /usr/sbin/mysqld(my_print_stacktrace+0x35)[0xf559e5] /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x7d4bd4] /lib64/libpthread.so.0[0x3a2fe0f710] /lib64/libc.so.6(gsignal+0x35)[0x3a2fa32925] /lib64/libc.so.6(abort+0x175)[0x3a2fa34105] /usr/sbin/mysqld(_Z18ut_print_timestampP8_IO_FILE+0x0)[0x7c3cf8] /usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0xb3)[0x11610d3] /usr/sbin/mysqld[0x1203338] /usr/sbin/mysqld[0x1203b98] /usr/sbin/mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x29e)[0x120c12e] /usr/sbin/mysqld[0x11bf616] /usr/sbin/mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0x40)[0x11c0090] /usr/sbin/mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0xd21)[0x11a1f01] /usr/sbin/mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x15d)[0x114244d] /usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2981)[0x11185c1] /usr/sbin/mysqld[0x1000e8a] /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x8219f1] /usr/sbin/mysqld[0xd39d26] /usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x3e4)[0xd3af44] /usr/sbin/mysqld[0x7cb006] /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x957)[0x7ce657] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3a2fa1ed1d] /usr/sbin/mysqld[0x7c4ac9] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 2021-11-12T07:56:58.641391Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2021-11-12T07:56:58.641442Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set. 2021-11-12T07:56:58.644936Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.25-log) starting as process 6345 ... 2021-11-12T07:56:58.644998Z 0 [ERROR] Can't find error-message file '/usr/share/mysql/errmsg.sys'. Check error-message file location and 'lc-messages-dir' configuration directive. 2021-11-12T07:56:58.651266Z 0 [Note] InnoDB: PUNCH HOLE support available 2021-11-12T07:56:58.651337Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-11-12T07:56:58.651344Z 0 [Note] InnoDB: Uses event mutexes 2021-11-12T07:56:58.651353Z 0 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier 2021-11-12T07:56:58.651361Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-11-12T07:56:58.651370Z 0 [Note] InnoDB: Using Linux native AIO 2021-11-12T07:56:58.651667Z 0 [Note] InnoDB: Number of pools: 1 2021-11-12T07:56:58.651794Z 0 [Note] InnoDB: Using CPU crc32 instructions 2021-11-12T07:56:58.654249Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2021-11-12T07:56:58.667767Z 0 [Note] InnoDB: Completed initialization of buffer pool 2021-11-12T07:56:58.671260Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2021-11-12T07:56:58.684155Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000! 2021-11-12 15:56:58 0x7f73adfaf720 InnoDB: Assertion failure in thread 140134816872224 in file ut0ut.cc line 942 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 07:56:58 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=151 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68196 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0 thread_stack 0x40000 /usr/sbin/mysqld(my_print_stacktrace+0x35)[0xf559e5] /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x7d4bd4] /lib64/libpthread.so.0[0x3a2fe0f710] /lib64/libc.so.6(gsignal+0x35)[0x3a2fa32925] /lib64/libc.so.6(abort+0x175)[0x3a2fa34105] /usr/sbin/mysqld(_Z18ut_print_timestampP8_IO_FILE+0x0)[0x7c3cf8] /usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0xb3)[0x11610d3] /usr/sbin/mysqld[0x1203338] /usr/sbin/mysqld[0x1203b98] /usr/sbin/mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x29e)[0x120c12e] /usr/sbin/mysqld[0x11bf616] /usr/sbin/mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0x40)[0x11c0090] /usr/sbin/mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0xd21)[0x11a1f01] /usr/sbin/mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x15d)[0x114244d] /usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2981)[0x11185c1] /usr/sbin/mysqld[0x1000e8a] /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x8219f1] /usr/sbin/mysqld[0xd39d26] /usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x3e4)[0xd3af44] /usr/sbin/mysqld[0x7cb006] /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x957)[0x7ce657] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3a2fa1ed1d] /usr/sbin/mysqld[0x7c4ac9] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.
這里我其實是比較蒙的,以為數(shù)據(jù)庫玩崩了。所以一定要記得備份數(shù)據(jù)庫。
# 都準備重裝mysql的,后來死馬當(dāng)活馬醫(yī),嘗試執(zhí)行下面的命令又好了 /var/lib/mysql8/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql &
參考鏈接
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket 解決辦法
到此這篇關(guān)于mysql從5.7平滑升級到8.0.27的實現(xiàn)的文章就介紹到這了,更多相關(guān)mysql5.7平滑升級到8.0.27內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
詳解mysql索引總結(jié)----mysql索引類型以及創(chuàng)建
索引是一種特殊的文件(InnoDB數(shù)據(jù)表上的索引是表空間的一個組成部分),它們包含著對數(shù)據(jù)表里所有記錄的引用指針。這篇文章主要介紹了詳解mysql索引總結(jié)----mysql索引類型以及創(chuàng)建,有興趣的可以了解一下。2016-11-11解決創(chuàng)建主鍵報錯:Incorrect column specifier for
這篇文章主要介紹了解決創(chuàng)建主鍵報錯:Incorrect column specifier for column‘id‘問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-08-08MySQL?數(shù)據(jù)庫?增刪查改、克隆、外鍵?等操作總結(jié)
這篇文章主要介紹了MySQL?數(shù)據(jù)庫?增刪查改、克隆、外鍵?等操作,本文給大家介紹的非常詳細,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-05-05CentOS系統(tǒng)中MySQL5.1升級至5.5.36
有相關(guān)測試數(shù)據(jù)說明從5.1到5.5+,MySQL性能會有明顯的提升,具體的需要自己建立測試環(huán)境去實踐下,今天我們就來操作下,并記錄下來升級的具體步驟2017-07-07Mysql技術(shù)內(nèi)幕之InnoDB鎖的深入講解
這篇文章主要給大家介紹了關(guān)于Mysql技術(shù)內(nèi)幕之InnoDB鎖的相關(guān)資料,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-12-12