免费观看又色又爽又黄的小说免费_美女福利视频国产片_亚洲欧美精品_美国一级大黄大色毛片

MySQL數據庫常見錯誤及解決方案

2021-03-16    分類: 解決方案

老張我在剛開始學習數據庫的時候,沒少走彎路。經常會遇到各種稀奇古怪的 error 信息,遇到報錯會很慌張,急需一個解決問題的辦法。跟無頭蒼蠅一樣,會不加思索地把錯誤粘到百度上,希望趕緊查找一下有沒有好的處理問題的方法。

MySQL數據庫

我想上述這個應該是剛從事數據庫的小白都會遇到的窘境。今天就給大家列舉 MySQL 數據庫中,最經典的十大錯誤案例,并附有處理問題的解決思路和方法。

希望能給剛入行,或數據庫愛好者一些幫助,今后再遇到任何報錯,我們都可以很淡定地去處理。

學習任何一門技術的同時,其實就是自我修煉的過程。沉下心,嘗試去擁抱數據的世界!

Top

1

Too many connections(連接數過多,導致連接不上數據庫,業務無法正常進行)

問題還原:


  1. mysql> show variables like '%max_connection%'; 
  2. | Variable_name   | Value | 
  3. max_connections | 151   |  
  4. mysql> set global max_connections=1;Query OK, 0 rows affected (0.00 sec) 
  5. [root@node4 ~]# mysql -uzs -p123456 -h 192.168.56.132 
  6. 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 隨著連接數的增加性能是會下降的,在 MySQL 5.7 之前都需要讓開發配合設置 thread pool,連接復用。MySQL 5.7 之后數據庫自帶 thread pool 了,連接數問題也得到了相應的解決。

另外對于有的監控程序會讀取 information_schema 下面的表,可以考慮關閉下面的參數:

  • innodb_stats_on_metadata=0
  • set global innodb_stats_on_metadata=0

Top

2

(主從復制報錯類型)


  1. Last_Errno: 1062 
  2.    Last_Error: Could not execute Write_rows event on table test.t;  
  3.    Duplicate entry '4' for key 'PRIMARY',  
  4.    Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY;  
  5.    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
  • 2017-07-20T14:05:30 p=...,u=root node4-relay-bin.000002 1506 1062

之后最好在從庫中開啟 read_only 參數,禁止在從庫進行寫入操作。

Last_IO_Errno: 1593(server-id沖突)


  1. Last_IO_Error:  
  2.  Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;  
  3.  these ids must be different for replication to work  
  4.  (or the --replicate-same-server-id option must be used on slave but this  
  5.  does not always make sense; please check the manual before using it) 

這個報錯出現之后,就能一目了然看到兩臺機器的 server-id 是一樣的。

在搭建主從復制的過程中,我們要確保兩臺機器的 server-id 是唯一的。這里再強調一下 server-id 的命名規則(服務器 ip 地址的最后一位+本 MySQL 服務的端口號)。

解決方法:

在主從兩臺機器上設置不同的 server-id。

Last_SQL_Errno: 1032(從庫少數據,主庫更新的時候,從庫報錯)


  1. Last_SQL_Error: 
  2. Could not execute Update_rows event on table test.t; Can't find record  
  3. in 't', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the  
  4. event's master log mysql-bin.000014, end_log_pos 1708 

解決問題的辦法:

根據報錯信息,我們可以獲取到報錯日志和position號,然后就能找到主庫執行的哪條sql,導致的主從報錯。

在主庫執行:


  1. /usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /data/mysql/mysql-bin.000014 |grep -A 10 1708 > 1.log  
  2. 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 語句之后,就可以在從庫反向執行 sql 語句。把從庫缺少的 sql 語句補全,解決報錯信息。

    在從庫依次執行:

    
    
    1. mysql> insert into t (b) values ('ddd'); 
    2. Query OK, 1 row affected (0.01 sec) 
    3. mysql> stop slave; 
    4. Query OK, 0 rows affected (0.00 sec) 
    5. mysql> exit 
    6. Bye 
    7. [root@node4 bin]# ./pt-slave-restart -uroot -proot123 
    8. 2017-07-20T14:31:37 p=...,u=root node4-relay-bin.000005         283 1032  

    Top

    3

    MySQL安裝過程中的報錯

    
    
    1. [root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &[1] 3758 
    2. [root@zs data]# 170720 14:41:24 mysqld_safe Logging to '/data/mysql/error.log'. 
    3. 170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql170720  
    4. 14:41:25 mysqld_safe mysqld from pid file /data/mysql/node4.pid ended 
    5. 170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql2017-07-20  
    6. 14:41:25 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. 
    7. Please use --explicit_defaults_for_timestamp server option  
    8. (see documentation for more details)./usr/local/mysql/bin/mysqld:  
    9. 網頁名稱:MySQL數據庫常見錯誤及解決方案
      文章路徑:http://m.newbst.com/news/105300.html

      網站建設、網絡推廣公司-創新互聯,是專注品牌與效果的網站制作,網絡營銷seo公司;服務項目有解決方案

      廣告

      聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯

    h5響應式網站建設