之前一直沒有對資料庫的主從做過配置,業務主庫挂了一次後手忙腳亂。現整理一下問題的描述以及解決方案。
問題定位:
1)用連接配接主庫,提示too many connections,修改主庫最大連接配接數無效,此時用root帳号能連上主庫
2)一段時間後,普通帳号和root帳号均無法連上主庫。檢視程序,mysql 程序仍然存在
3)關閉mysql程序,重新開機主庫,無法啟動
4)檢視err.log,提示磁盤已滿
主庫伺服器空間不足,日志把磁盤打滿,導緻主庫無法連接配接。(需要重視報警郵件)
解決步驟:
一 重新開機主庫
1)檢視磁盤空間df -h,将3306檔案夾移到磁盤空間較大的分區
2)建立新路徑到原路徑的軟連結
3)重新開機主庫mysql
二 主從同步
1)主庫重新開機後,檢查主從是否同步
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
從庫不同步
2)忽略錯誤,繼續同步(此方法适用于主從庫資料相差不大,或者要求資料可以不完全統一的情況,資料要求不嚴格的情況)
stop slave;
重複執行以下三個步驟:
#表示跳過一步錯誤,後面的數字可變
set global sql_slave_skip_counter =1;
start slave;
show slave status\G;
直到出現以下内容,表示從庫已同步。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
注:此時仍需關注一個參數(如果此參數不為0表示主從同步之間存在延時。)
Seconds_Behind_Master: 0
以上,問題得以解決。
上網搜了一下,解決主從不同步還有一種方法:重建主從。
此适用于主從庫資料相差較大,或者要求資料完全統一的情況(注:沒有親自試過~~)
解決步驟如下:
1.先進入主庫,進行鎖表,防止資料寫入
使用指令:
mysql> flush tables with read lock;
注意:該處是鎖定為隻讀狀态,語句不區分大小寫
2.進行資料備份
#把資料備份到mysql.bak.sql檔案
[[email protected] mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql
這裡注意一點:資料庫備份一定要定期進行,可以用shell腳本或者python腳本,都比較友善,確定資料萬無一失
3.檢視master 狀态
mysql> show master status;
+-------------------+----------+--------------+-------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+-------------------------------+
| mysqld-bin.000001 | 3260 | | mysql,test,information_schema |
+-------------------+----------+--------------+-------------------------------+
1 row in set (0.00 sec)
4.把mysql備份檔案傳到從庫機器,進行資料恢複
#使用scp指令
[ro[email protected] mysql]# scp mysql.bak.sql [email protected]:/tmp/
5.停止從庫的狀态
mysql> stop slave;
6.然後到從庫執行mysql指令,導入資料備份
mysql> source /tmp/mysql.bak.sql
7.設定從庫同步,注意該處的同步點,就是主庫show master status資訊裡的| File| Position兩項
change master to master_host = '192.168.128.100', master_user = 'rsync', master_port=3306, master_password='', master_log_file = 'mysqld-bin.000001', master_log_pos=3260;
8.重新開啟從同步
mysql> stop slave;
9.檢視同步狀态
mysql> show slave status\G 檢視:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
好了,同步完成啦。
方法二轉載自:http://www.jb51.net/article/33052.htm