老張我在剛開始學(xué)習(xí)數(shù)據(jù)庫的時候,沒少走彎路。經(jīng)常會遇到各種稀奇古怪的 error 信息,遇到報錯會很慌張,急需一個解決問題的辦法。跟無頭蒼蠅一樣,會不加思索地把錯誤粘到百度上,希望趕緊查找一下有沒有好的處理問題的方法。
我想上述這個應(yīng)該是剛從事數(shù)據(jù)庫的小白都會遇到的窘境。今天就給大家列舉 MySQL 數(shù)據(jù)庫中,最經(jīng)典的十大錯誤案例,并附有處理問題的解決思路和方法。
希望能給剛?cè)胄?,或?shù)據(jù)庫愛好者一些幫助,今后再遇到任何報錯,我們都可以很淡定地去處理。
學(xué)習(xí)任何一門技術(shù)的同時,其實就是自我修煉的過程。沉下心,嘗試去擁抱數(shù)據(jù)的世界!
Top
1
Too many connections(連接數(shù)過多,導(dǎo)致連接不上數(shù)據(jù)庫,業(yè)務(wù)無法正常進行)
問題還原:
-
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 數(shù)據(jù)庫參數(shù)文件里面,對應(yīng)的 max_connections 這個參數(shù)值是不是設(shè)置的太小了,導(dǎo)致客戶端連接數(shù)超過了數(shù)據(jù)庫所承受的大值。
-
該值默認大小是 151,我們可以根據(jù)實際情況進行調(diào)整。
-
對應(yīng)解決辦法:set global max_connections=500
但這樣調(diào)整會有隱患,因為我們無法確認數(shù)據(jù)庫是否可以承擔(dān)這么大的連接壓力,就好比原來一個人只能吃一個饅頭,但現(xiàn)在卻非要讓他吃 10 個,他肯定接受不了。反應(yīng)到服務(wù)器上面,就有可能會出現(xiàn)宕機的可能。
所以這又反映出了,我們在新上線一個業(yè)務(wù)系統(tǒng)的時候,要做好壓力測試。保證后期對數(shù)據(jù)庫進行優(yōu)化調(diào)整。
2、其次可以限制 Innodb 的并發(fā)處理數(shù)量,如果 innodb_thread_concurrency = 0(這種代表不受限制) 可以先改成 16 或是 64 看服務(wù)器壓力。
如果非常大,可以先改的小一點讓服務(wù)器的壓力下來之后,然后再慢慢增大,根據(jù)自己的業(yè)務(wù)而定,個人建議可以先調(diào)整為 16 即可。
MySQL 隨著連接數(shù)的增加性能是會下降的,在 MySQL 5.7 之前都需要讓開發(fā)配合設(shè)置 thread pool,連接復(fù)用。MySQL 5.7 之后數(shù)據(jù)庫自帶 thread pool 了,連接數(shù)問題也得到了相應(yīng)的解決。
另外對于有的監(jiān)控程序會讀取 information_schema 下面的表,可以考慮關(guān)閉下面的參數(shù):
-
innodb_stats_on_metadata=0
-
set global innodb_stats_on_metadata=0
Top
2
(主從復(fù)制報錯類型)
-
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
針對這個報錯,我們首先要考慮是不是在從庫中誤操作導(dǎo)致的。結(jié)果發(fā)現(xiàn),我們在從庫中進行了一條針對有主鍵表的 sql 語句的插入,導(dǎo)致主庫再插入相同 sql 的時候,主從狀態(tài)出現(xiàn)異常。發(fā)生主鍵沖突的報錯。
解決方法:
在確保主從數(shù)據(jù)一致性的前提下,可以在從庫進行錯誤跳過。一般使用 percona-toolkit 中的 pt-slave-restart 進行。
在從庫完成如下操作:
-
[root@zs bin]# ./pt-slave-restart -uroot -proot123
-
2017-07-20T14:05:30 p=...,u=root node4-relay-bin.000002 1506 1062
之后最好在從庫中開啟 read_only 參數(shù),禁止在從庫進行寫入操作。
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)
這個報錯出現(xiàn)之后,就能一目了然看到兩臺機器的 server-id 是一樣的。
在搭建主從復(fù)制的過程中,我們要確保兩臺機器的 server-id 是唯一的。這里再強調(diào)一下 server-id 的命名規(guī)則(服務(wù)器 ip 地址的最后一位+本 MySQL 服務(wù)的端口號)。
解決方法:
在主從兩臺機器上設(shè)置不同的 server-id。
Last_SQL_Errno: 1032(從庫少數(shù)據(jù),主庫更新的時候,從庫報錯)
-
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
解決問題的辦法:
根據(jù)報錯信息,我們可以獲取到報錯日志和position號,然后就能找到主庫執(zhí)行的哪條sql,導(dǎo)致的主從報錯。
在主庫執(zhí)行:
-
/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /data/mysql/mysql-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 flags: 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 語句之后,就可以在從庫反向執(zhí)行 sql 語句。把從庫缺少的 sql 語句補全,解決報錯信息。
在從庫依次執(zhí)行:
-
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
-
2017-07-20T14:31:37 p=...,u=root node4-relay-bin.000005 283 1032
Top
3
MySQL安裝過程中的報錯
-
[root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &[1] 3758
-
[root@zs data]# 170720 14:41:24 mysqld_safe Logging to '/data/mysql/error.log'.
-
170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql170720
-
14:41:25 mysqld_safe mysqld from pid file /data/mysql/node4.pid ended
-
170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql2017-07-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:
-
網(wǎng)頁名稱:MySQL數(shù)據(jù)庫常見錯誤及解決方案
文章路徑:http://m.rwnh.cn/news/105300.html
網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián),是專注品牌與效果的網(wǎng)站制作,網(wǎng)絡(luò)營銷seo公司;服務(wù)項目有解決方案等
廣告
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源:
創(chuàng)新互聯(lián)