熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> MySQL >> 正文

MYSQL主從同步故障一例及解決過程!

2022-06-13   來源: MySQL 

  公司裡有兩個mysql服務器做主從同步某天Nagios發來報警短信mysqla is down趕緊聯系機房機房的人反饋來的信息是 HARDWARE ERROR 後面信息省略讓機房記下錯誤信息後讓他們幫忙重啟下看是不是能正常起來結果竟然正常起來了趕緊導出所有數據

  問題又出現了nagios 又報警mysql_AB error檢查從庫

  show slave status \G; 果然

  Slave_IO_Running: Yes

  Slave_SQL_Running: No

  而且出現了錯誤還提示

  Last_SQL_Error: Error Duplicate entry for key PRIMARY on query Default database: bug Query: insert into misdata (uidmidpidstatemtime) values ()

  很顯然由於主庫重啟導致 從庫數據不同步而且主鍵沖突查看error 日志發現error日志文件變得好大比以前大了將近好幾倍

  tail f mysql_errorlog 最開始查看到的是這條信息

  發現這條信息

  [ERROR] Slave SQL: Error Duplicate entry for key PRIMARY on query Default database: ufo Query: insert into misdata (uidmidpidsta

  temtime) values () Error_code:

   :: [Warning] Slave: Duplicate entry for key PRIMARY Error_code:

   :: [ERROR] Error running query slave SQL thread aborted Fix the problem and restart the slave SQL thread with SLAVE START We stopped at log ufolog

   position

  報錯和上面的意思差不多

  最先想到的就是首先手動同步一下從庫上首先 stop slave;停止同步

  進入主庫鎖表

  FLUSH TABLES WITH READ LOCK

  mysql> show master status;

  +++++

  | File              | Position  | Binlog_Do_DB | Binlog_Ignore_DB |

  +++++

  | ufo | |              |                  |

  +++++

   row in set ( sec)

  進入從庫

  mysql>change master to master_host= master_user=slave

  master_password=xxx

  master_port=

  master_log_file=ufo

  master_log_pos=;

  完成上面這些後

  start slave;

  回到主庫

  unlock tables; 解鎖

  回到從庫 查看

  show slave status \G;

  發現正常了長處了一口氣可是還沒過一分鐘發現又開始報錯了還是最開始那個錯誤這是怎麼回事

  於是又想到了跳過錯誤的辦法(不過我不太喜歡用這種方法)馬上進入從庫

  stop slave;

  set global sql_slave_skip_counter=; (是指跳過一個錯誤)

  slave start;

  再show slave status \G;查看

  還是報錯 只不過 原來的 變成了 連續執行了幾次後

  除了上面的數值 在變錯誤依然還在

  郁悶了看來只能先強制跳過 錯誤了於是修改從庫的/etc/f文件

  在裡面的[mysqld]下面加入了一行

  slaveskiperrors = (忽略所有的錯誤)

  重啟下從庫的mysql /etc/initd/mysqld restart

  再 show slave status \G;一下發現正常了但是我知道這時的數據可能已經不同步了

  再次查看一下日志讓我感到意外的是tail f mysql_errorlog 出現大量的

  

   :: [Warning] Statement may not be safe to log in statement format Statement: delete from `system_message_` where `to_uid` = ORDER BY `id` ASC LIMIT

  

  日志裡面有大量的這種警告意思應該是statement 格式不安全用vim 打開他看了一下發現好多這類警告我說為什麼錯誤日志怎麼變這麼大了呢!!

  statement format 應該是 binlog的一種格式進入從庫查看一下

  show global variables like binlog_format;

  果然當前的格式為statement

  我需要把格式改為 mixed格式

  修改從庫的 mycfg

  在[mysqld]下面加入下面這行

  binlog_format=mixed

  然後重啟mysql服務發現錯誤日志裡的 警告 都停止了這回清靜多了~~

  我突然想起一件事記得有朋友說過 RBR 模式可以解決很多因為主鍵沖突導致的主從無法同步情況想到這裡我就想要不要把 slaveskiperrors = 去掉再試試

  於是就進入到f 裡在注釋掉了 slaveskiperrors =

  再次重新啟動 mysql服務

  進入從庫

  show slave status \G;

  

  Slave_IO_Running: Yes

  Slave_SQL_Running: Yes

  

  恢復了!!!有觀察了一段時間沒有出現問題這才放心

  看來導致 mysql 主從復制出錯的原因還真不少修復的辦法也不止一個binlog的格式也是其中之一

  希望遇到和這次一樣問題的朋友看到這篇文章後會得到 一些啟發和解決問題的方法~~


From:http://tw.wingwit.com/Article/program/MySQL/201311/29391.html
  • 上一篇文章:

  • 下一篇文章:
  • 推薦文章
    Copyright © 2005-2022 電腦知識網 Computer Knowledge   All rights reserved.