1、MySQL數據庫安裝過程中的報錯
[root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &[1] 3758 [root@zs data]# 190320 14:41:24 mysqld_safe Logging to '/data/mysql/error.log'. 190320 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql190320 14:41:25 mysqld_safe mysqld from pid file /data/mysql/node4.pid ended 190320 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql2019-03-20 14:41:25 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details)./usr/local/mysql/bin/mysqld: File '/data/mysql/mysql-bin.index' not found (Errcode: 13 - Permission denied) 2019-03-20 14:41:25 4388 [ERROR] Aborting
解決思路：
遇到這樣的報錯信息，我們要學會時時去關注錯誤日志 error log 里面的內容。看見了關鍵的報錯點Permission denied。證明當前 MySQL 數據庫的數據目錄沒有權限。
解決方法：
[root@zs data]# chown mysql:mysql -R mysql [root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf & [1] 4402 [root@zs data]# 190320 14:45:56 mysqld_safe Logging to '/data/mysql/error.log'. 190320 14:45:56 mysqld_safe Starting mysqld daemon with databases from /data/mysql #啟動成功。
如何避免這類問題，個人建議在安裝MySQL初始化的時候，一定加上–user=mysql，這樣就可以避免權限問題。
即：$ ./mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/ --defaults-file=/
etc/my.cnf --user=mysql
2、忘記MySQL數據庫密碼
[root@zs ~]# mysql -uroot -p Enter password: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) [root@zs ~]# mysql -uroot -p Enter password: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) #我們有可能剛剛接手別人的 MySQL 數據庫，而且沒有完善的交接文檔。root 密碼可以丟失或者忘記了。
解決思路：
目前是進入不了數據庫的情況，所以我們要考慮是不是可以跳過權限。因為在數據庫中，mysql數據庫中user表記錄著我們用戶的信息。
解決方法：
啟動 MySQL 數據庫的過程中，可以這樣執行：
$ /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf --skip-grant-tables & 這樣啟動，就可以不用輸入密碼，直接進入 mysql 數據庫了。然后在修改你自己想要改的root密碼即可。 MySQL [mysql]> update mysql.user set password=password('root123') where user='root';
3、Too many connections（連接數過多，導致連接不上數據庫，業務無法正常進行）
mysql> show variables like '%max_connection%'; | Variable_name | Value | max_connections | 151 | mysql> set global max_connections=1;Query OK, 0 rows affected (0.00 sec) [root@node4 ~]# mysql -uzs -p123456 -h 192.168.56.132 ERROR 1040 (00000): Too many connections
解決問題的思路：
1、首先先要考慮在我們 MySQL 數據庫參數文件里面，對應的 max_connections 這個參數值是不是設置的太小了，導致客戶端連接數超過了數據庫所承受的最大值。
● 該值默認大小是151，我們可以根據實際情況進行調整。
● 對應解決辦法：set global max_connections=500
但這樣調整會有隱患，因為我們無法確認數據庫是否可以承擔這么大的連接壓力，就好比原來一個人只能吃一個饅頭，但現在卻非要讓他吃 10 個，他肯定接受不了。反應到服務器上面，就有可能會出現宕機的可能。
所以這又反應出了，我們在新上線一個業務系統的時候，要做好壓力測試。保證后期對數據庫進行優化調整。
2、其次可以限制Innodb 的并發處理數量 ，如果 innodb_thread_concurrency = 0（這種代表不受限制） 可以先改成 16或是64 看服務器壓力。如果非常大，可以先改的小一點讓服務器的壓力下來之后,然后再慢慢增大,根據自己的業務而定。個人建議可以先調整為 16 即可。
MySQL 隨著連接數的增加性能是會下降的，可以讓開發配合設置 thread pool，連接復用。在MySQL商業版中加入了thread pool這項功能,另外對于有的監控程序會讀取 information_schema 下面的表，可以考慮關閉下面的參數
innodb_stats_on_metadata=0 set global innodb_stats_on_metadata=0
4、主從復制報錯類型
A、Last_SQL_Errno: 1062 （從庫與主庫數據沖突）
Last_Errno: 1062 Last_Error: Could not execute Write_rows event on table test.t; Duplicate entry '4' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000014, end_log_pos 1505
針對這個報錯，我們首先要考慮是不是在從庫中誤操作導致的。結果發現，我們在從庫中進行了一條針對有主鍵表的 sql 語句的插入，導致主庫再插入相同 sql 的時候，主從狀態出現異常。 發生主鍵沖突的報錯。
解決方法：
在確保主從數據一致性的前提下，可以在從庫進行錯誤跳過。一般使用 percona-toolkit 中的 pt-slave-restart 進行。
在從庫完成如下操作
[root@zs bin]# ./pt-slave-restart -uroot -proot123
2019-03-20T14:05:30 p=...,u=root node4-relay-bin.000002 1506 1062
之后最好在從庫中開啟 read_only 參數，禁止在從庫進行寫入操作
B、Last_IO_Errno: 1593（server-id沖突）
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it) #這個報錯出現之后，就看一目了然看到兩臺機器的 server-id 是一樣的。
在搭建主從復制的過程中，我們要確保兩臺機器的 server-id 是唯一的。這里再強調一下 server-id 的命名規則（服務器 ip 地址的最后一位+本 MySQL 服務的端口號）
解決方法：
在主從兩臺機器上設置不同的 server-id。
C、Last_SQL_Errno: 1032（從庫少數據，主庫更新的時候，從庫報錯）
Last_SQL_Error: Could not execute Update_rows event on table test.t; Can't find record in 't', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000014, end_log_pos 1708
解決辦法：
根據報錯信息，我們可以獲取到報錯日志和position號，然后就能找到主庫執行的哪條sql，導致的主從報錯。
在主庫執行：
$ /usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /data/mysql/m
ysql-bin.000014 |grep -A 10 1708 > 1.log cat 1.log #170720 14:20:15 server id 3 end_log_pos 1708 CRC32 0x97b6bdec Update_rows: table id 113 fl
ags: STMT_END_F ### UPDATE `test`.`t` ### WHERE ### @1=4 /* INT meta=0 nullable=0 is_null=0 */ ### @2='dd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */ ### SET ### @1=4 /* INT meta=0 nullable=0 is_null=0 */ ### @2='ddd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */ # at 1708 #170720 14:20:15 server id 3 end_log_pos 1739 CRC32 0xecaf1922 Xid = 654 COMMIT/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
獲取到 sql 語句之后，就可以在從庫反向執行 sql 語句。把從庫缺少的 sql 語句補全，解決報錯信息。
在從庫依次執行：
mysql> insert into t (b) values ('ddd'); Query OK, 1 row affected (0.01 sec) mysql> stop slave; Query OK, 0 rows affected (0.00 sec) mysql> exit Bye [root@node4 bin]# ./pt-slave-restart -uroot -proot123 2019-03-20T14:31:37 p=...,u=root node4-relay-bin.000005 283 1032
5、MySQL 數據庫連接超時的報錯
org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08S01 org.hibernate.util.JDBCExceptionReporter - The last packet successfully received from the server was43200
milliseconds ago.The last packet sent successfully to the server was 43200 milliseconds ago, which is longer
than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing conn
ection validity before use in your application, increasing the server configured values for client timeouts,
or using the Connector/J connection 'autoReconnect=true' to avoid this problem. org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session org.hibernate.exception.JDBCConnectionException: Could not execute JDBC batch update com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Connection.close() has already been call
ed. Invalid operation in this state. org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08003 org.hibernate.util.JDBCExceptionReporter - No operations allowed after connection closed. Connection was implici
tly closed due to underlying exception/error: ** BEGIN NESTED EXCEPTION ** #大多數做 DBA 的同學，可能都會被開發人員告知，你們的數據庫報了這個錯誤了。趕緊看看是哪里的問題。
這個問題是由兩個參數影響的，wait_timeout 和 interactive_timeout。數據默認的配置時間是28800（8小時）意味著，超過這個時間之后，MySQL 數據庫為了節省資源，就會在數據庫端斷開這個連接，Mysql服務器端將其斷開了，但是我們的程序再次使用這個連接時沒有做任何判斷，所以就掛了。
解決思路：
先要了解這兩個參數的特性；這兩個參數必須同時設置，而且必須要保證值一致才可以。
我們可以適當加大這個值，8小時太長了，不適用于生產環境。因為一個連接長時間不工作，還占用我們的連接數，會消耗我們的系統資源。
解決方法：
可以適當在程序中做判斷；強烈建議在操作結束時更改應用程序邏輯以正確關閉連接；然后設置一個比較合理的timeout的值（根據業務情況來判斷）
6、can’t open file (errno:24)
有的時候，數據庫跑得好好的，突然報不能打開數據庫文件的錯誤了。
解決思路：
首先我們要先查看數據庫的error log。然后判斷是表損壞，還是權限問題。還有可能磁盤空間不足導致的不能正常訪問表；操作系統的限制也要關注下；用 perror 工具查看具體錯誤！
linux:/usr/local/mysql/bin # ./perror 24 OS error code 24: Too many open files
超出最大打開文件數限制！ulimit -n查看系統的最大打開文件數是65535，不可能超出！那必然是數據庫的最大打開文件數超出限制！
在 MySQL 里查看最大打開文件數限制命令：show variables like ‘open_files_limit’;
發現該數值過小，改為2048，重啟 MySQL，應用正常
處理方法：
repair table ； chown mysql權限 #清理磁盤中的垃圾數據
