推薦：使用innodb_force_recovery解決MySQL崩潰無法重啟問題
這篇文章主要介紹了使用innodb_force_recovery解決MySQL崩潰無法重啟問題,這只一個成功案例,并不是萬能的解決方法,需要酌情考慮,需要的朋友可以參考下 一 背景 某一創(chuàng)業(yè)的朋友的主機(jī)因為磁盤陣列損壞機(jī)器crash,重啟MySQL服務(wù)時 報如下錯誤: 代碼如下: InnoDB: Reading

 　　這篇文章主要介紹了MySQL slave_net_timeout參數(shù)解決的一個集群問題案例,問題日志請見正文,本文使用slave_net_timeout參數(shù)解決了這個問題,需要的朋友可以參考下

　　【背景】

　　對一套數(shù)據(jù)庫集群進(jìn)行5.5升級到5.6之后,alter.log 報warning異常。

　　復(fù)制代碼 代碼如下:

　　2015-02-03 15:44:51 19633 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the \'START SLAVE Syntax\' in the MySQL Manual for more information.

　　數(shù)據(jù)庫業(yè)務(wù)壓力 qps 1 tps 幾乎為0 4-10 秒或者更久會有寫入操作。

　　【分析】

　　1 主從復(fù)制信息 主機(jī)地址，端口，復(fù)制用戶，binlog 文件位置等信息是存儲在master.info中的， 5.6 版本在安全性上做了很多改善，不建議在執(zhí)行change master的時候指定密碼。如果在搭建主從時制定密碼，5.6 MySQL 會提示上述warning信息。這也是該集群在5.5版本時不報錯的原因。

　　2 MySQL Replication的重連機(jī)制

　　在一個已經(jīng)建立主從復(fù)制關(guān)系的系統(tǒng)里面,正常情況下,由從庫向主庫發(fā)送一個 COM_BINLOG_DUMP 命令后,主庫有新的binlog event，會向備庫發(fā)送binlog。但是由于網(wǎng)絡(luò)故障或者其他原因?qū)е轮鲙炫c從庫的連接斷開或者主庫長時間沒有向從庫發(fā)送binlog。例如該例子中數(shù)據(jù)庫集群 10s 左右還沒有寫入的情況，超過slave_net_timeout設(shè)置的4s ，從庫會向主庫發(fā)起重連請求。5.6 版本slave 發(fā)起重連請求時，MySQL都會判斷有沒有用明文的用戶名密碼,如果有則發(fā)出上述信息到error.log。

　　【解決方法】

　　在本案例中可以嘗試將slave_net_timeout 調(diào)整大一些 設(shè)置為25 。slave_net_timeout是設(shè)置在多少秒沒收到主庫傳來的Binary Logs events之后,從庫認(rèn)為網(wǎng)絡(luò)超時,Slave IO線程會重新連接主庫。該參數(shù)的默認(rèn)值是3600s ，然而時間太久會造成數(shù)據(jù)庫延遲或者主備庫直接的鏈接異常不能及時發(fā)現(xiàn)。將 slave_net_timeout 設(shè)得很短會造成 Master 沒有數(shù)據(jù)更新時頻繁重連。一般線上設(shè)置為5s 。

　　復(fù)制代碼 代碼如下:

　　set global slave_net_timeout = 25

　　當(dāng)然也可以和業(yè)務(wù)方溝通，對于幾乎沒有訪問量的業(yè)務(wù)線進(jìn)行下線 ，為公司節(jié)省資源

分享：MySQL replace into 語句淺析（二）
這篇文章主要介紹了MySQL replace into 語句淺析(二),本文著重給出了幾個特殊案例分析,需要的朋友可以參考下 一 介紹 上一篇文章介紹了replace into的基本原理。本章內(nèi)容通過一個例子說明 replace into 帶來的潛在的數(shù)據(jù)質(zhì)量風(fēng)險,當(dāng)涉及replace into操作的表含有自增主