mysql主從日常管理維護

1)查看從服務器狀態

為了防止復制過程中出現故障從而導致復制進程停止，我們需要經常檢查從服務器的復制狀態。

一般使用show slave status命令來檢查。

例如：

mysql> show slave status \G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.1.109

Master_User: mysql

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql3306-bin.000024

Read_Master_Log_Pos: 438065348

Relay_Log_File: mysql-relay.000751

Relay_Log_Pos: 438065489

Relay_Master_Log_File: mysql3306-bin.000024

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB: mysql,test

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 438065348

Relay_Log_Space: 438065489

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

1 row in set (0.00 sec)

ERROR:

No query specified

在顯示 的這些信息中，我們主要關心 Slave_IO_Running 和Slave_SQL_Running 這兩個進程狀態是否是“yes”，這兩個進程的含義分表如下：

Slave_IO_Running：此進程負責從服務器(slave)從主服務器(master)上讀取BINLOG日志，并寫入從服務器上的中繼日志中。

Slave_SQL_Running：此進程負責讀取并且執行中繼日志中的BINLOG日志。

只要其中有一個進程是no，則表示復制進程停止，錯誤原因可以從“Last_Errno”字段的值中看到。

除了查看上面的信息，用戶還可以通過這個命令了解從服務器的配置情況以及當前和主服務器的同步情況，包括指向那個主服務器，主服務器的端口，復制使用的用戶，當前日志恢復到位置等。這些信息都是記錄在從服務器這一端的，主服務器上并沒有相應的信息。

2) 主從服務器同步維護

在某些繁忙的OLTP(在線事務處理)系統上，由于主服務器更新頻繁，而從服務器由于各種原因(比如硬件性能較差)導致更新速度較慢，從而使得主從服務器之間的數據差距越來越大最終對某些應用產生影響。在這種情況下，我們需要定期的進行主從服務器的數據同步，使得主

從數據差距能減到最小。常用的方法是：在負責較低的時候暫時阻塞主數據庫的更新，強制主從數據庫更新同步。

具體步驟如下：

1.在主服務器上，執行以下語句(注意，會阻塞主數據庫的所有更新操作)

Mysql>flush tables with read lock;

Mysql>show master status \G;

記錄show語句的輸出的日志名和偏移量，這些都是從服務器復制的目的坐標。

2.在從服務器上，執行下面語句，其中master_pos_wait()函數的參數是前面步驟中得到的復制坐標值。

Mysql> select master_pso_wait('mysql-bin.0001','974');

這個select語句會阻塞直到從服務器達到指定的日志文件和偏移量后，返回0，如果返回-1，則表示超時退出。查詢返回0時，則從服務器與主服務器同步。

3.在主服務器上，執行下面的語句允許主服務器重新開始處理更新

Mysql> unlock tables;

1、在主上 flush tables with read lock;

2、在從上slave stop

3、在主上show master status

4、在從上CHANGE MASTER TO ?MASTER_HOST='192.168.1.109', Master_User='mysql', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql3306-bin.000002', MASTER_LOG_POS=98;

5、從上slave start

6、主上 unlock tables;

3)從服務器復制出錯的處理

從服務器更新失敗時，首先需要確定是否是從服務器的表與主服務器的不同造成的。如果是表結構不同導致的，則修改從服務器的表與主服務器的相同，然后重新運行start slave語句。

如果不是表結構不同導致的更新失敗，則需要確認手動更新是否安全，然后護士來之主服務器的更新失敗的語句。跳過來自主服務器的命令：SET GLOBAL SQL_SLAVE_SKIP_COUNTER = ?n ,其中n的取值為1或者2。如果來自主服務器的更新語句不使用AUTO_INCREMENT或LAST_INSERT_ID()，n值應為1，否則，值為2.原因是使用AUTO_INCREMENT或LAST_INSERT_ID()的語句需要從二進制日志中取兩個事件。以下例子就是在從服務器端牟尼跳過主服務器的兩個更新語句的效果。

1.首先在從服務器上停止slave線程

Mysql> stop slave;

Mysql > SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2

2.然后在主服務器上插入數據

3.從服務器端啟動復制進程，檢查測試的表，首先發現插入的兩條記錄唄跳過了，只執行了第3條插入語句。

4) log event entry exceeded max_allowed_packet的處理

如果應用中使用大的BLOG列或者長字符串，那么在從服務器上恢復的時候，可能出現“log event entry exceeded max_allowed_packet”錯誤，這個因為含有大文本的記錄無法通過網絡進行傳輸導致。解決的辦法就是在主從服務器上增加max_allowed_packet參數的大小，這個參數的默認值是1MB，可以按照實際需要進行修改，比如下列中將其增大為512MB。

mysql> show variabl

es like 'max_allowed_packet';

+--------------------+-----------+

| Variable_name ? ? ?| Value ? ? |

+--------------------+-----------+

| max_allowed_packet | 536870912 |

+--------------------+-----------+

1 row in set (0.00 sec)

可以在配置文件中寫入

[mysqldump]

quick

max_allowed_packet = 512M

5)多主復制時的自增長 變量沖突問題

在大多數情況下，一般只使用單主復制(一臺主服務器對一臺或者多臺從服務器)。但是在某些情況下，可能會需要使用多主復制(多臺主服務器對一臺從服務器)。這個時候，如果主服務器的表采用自動增長變量，那么復制到從服務器的同一張表后很可能會引起主鍵沖突，因為系統參數auto_increment_increment和auto_increment_offset默認值為1，這樣多臺主服務器的自增變量列遲早會發生沖突。在單數復制時，可以采用默認設置，不會有主鍵沖突發生。但是使用多主復制時，就需要定制auto_increment_increment和auto_increment_offset的設置，保證多主之間復制到從數據庫不會有重復沖突，比如兩個master的情況可以按照以下設置：

Master1：auto_increment_increment = 2 ，auto_increment_offset =1：(1,3,5,7………)

Master2:auto_increment_increment = 2 , auto_increment_offset =0 (0,2,4,6……..)

查看：

show variables like 'auto_inc%';

6)查看從服務器的復制進度

很多情況下，我們都想知道從服務器復制的進如何。知道了這個差距，可以幫助我們判斷是否需要手工來做主從的同步工作，也可以幫助我們判斷從服務器上做統計的數據精度如果。這個值可以通過show processlist中的slave_SQL_running線程的time值得到，它記錄了從服務器當期執行sql時間戳與系統時間之間的差距，單位是秒。

mysql> show processlist \G;

*************************** 1. row ***************************

Id: 1

User: system user

Host:

db: NULL

Command: Connect

Time: 4636437

State: Waiting for master to send event

Info: NULL

*************************** 2. row ***************************

Id: 2

User: system user

Host:

db: NULL

Command: Connect

Time: 2 ? ?這個time值就是最后執行的復制操作大概是在主服務器上2秒鐘前得更新

State: Has read all relay log; waiting for the slave I/O thread to update it

Info: NULL

*************************** 3. row ***************************

Id: 625916

User: root

Host: localhost

db: NULL

Command: Query

Time: 0

State: NULL

Info: show processlist

3 rows in set (0.00 sec)

ERROR:

No query specified

總結

以上是生活随笔為你收集整理的mysql主从维护_mysql主从日常管理维护的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。