mysql主從複製

mysql之主從複製
在實際企業應用環境當中，單臺mysql數據庫是不足以滿足日後業務需求的。譬如服務器發生故障，沒有備份服務器來提供服務的話，業務就得停止。介於這種情況，我們來學習一下mysql主從複製。
使用mysql主從複製的好處有：
1、採用主從服務器這種架構，穩定性得以提升。如果主服務器發生故障，我們可以使用從服務器來提供服務。
2、在主從服務器上分開處理用戶的請求，可以提升數據處理效率。
3、將主服務器上的數據複製到從服務器上，保護數據免受意外的損失。

環境
我使用的是percona 5.5
主機IP：192.168.1.110
從機IP：192.168.1.111
一. MySQL主服務器配置
   1.編輯配置文件/etc/my.cnf
    server_id = 1
    log-bin=mysql-bin
   #只輸入以上兩行表示實例下的數據庫都進行復制
   binlog-do-db=mysql #需要備份的數據庫名，如果備份多個數據庫，重複設置這個選項即可
    binlog-ignore-db=mysql #不需要備份的數據庫名，如果備份多個數據庫，重複設置這個選項即可
    log-slave-updates #這個參數一定要加上，否則不會給更新的記錄些到二進制文件裏
    slave-skip-errors #是跳過錯誤，繼續執行復制操作    #注意我使用的版本添加此項後啓動mysql失敗

   2.建立用戶
    mysql> grant replication slave on *.* to [email protected] identified by ‘123456′;
   3.鎖主庫表
    mysql> FLUSH TABLES WITH READ LOCK;
   #在線上服務器，因爲用戶數據不斷的寫入，如果不鎖表，可能照成主從數據庫不同步
   4.顯示主庫信息
    記錄File和Position，從庫設置將會用到
    =====================
    mysql> SHOW MASTER STATUS;
    +------------------+----------+--------------+------------------+
    | File             | Position | Binlog_do_db | Binlog_ignore_db |
    +------------------+----------+--------------+------------------+
    | mysql-bin.000001 | 106      |              |                  |
    +------------------+----------+--------------+------------------+
   5.將數據庫備份，


二，MySQL從服務器配置
   1,還原數據此步驟省略
   2,編輯 /etc/my.cnf
        server-id=2
       log-bin=mysql-bin
   設置後最好重啓一下mysql，不然會出現讀取server_id爲1，照成同步錯誤
   3、在SLAVE上設置同步
   mysql> slave stop;
    mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.110',MASTER_USER='slave',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=106;
   6、啓動SLAVE服務
    mysql> slave start;

    7、查看SLAVE狀態
    mysql> SHOW SLAVE STATUS\G;
    其中 Slave_IO_Running 和 Slave_SQL_Running 兩列的值都爲 "Yes"，表明 Slave 的 I/O 和 SQL 線程
    都在正常運行。
    8、解鎖主庫表
    mysql> UNLOCK TABLES;
    到此主從庫搭建成功。可以在主庫上插入數據測試同步是否正常。



三、常見錯誤及解決方法：
1：在從庫上面show slave status\G;出現下列情況，
              Slave_IO_Running: Yes
              Slave_SQL_Running: No
              Seconds_Behind_Master: NULL

    原因：
    a.程序可能在slave上進行了寫操作
    b.也可能是slave機器重起後，事務回滾造成的.

    解決方法：

    進入master

    mysql> show master status;
    +----------------------+----------+--------------+------------------+
    | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +----------------------+----------+--------------+------------------+
    | mysql-bin.000040 | 324 | | |
    +----------------------+----------+--------------+------------------+
    然後到slave服務器上執行手動同步

    slave stop;
    change master to
    master_host='192.168.1.110',
    master_user='slave',
    master_password='123456',
    master_port=3306,
    master_log_file='mysql-bin.000040',
    master_log_pos=324;
    slave start;
    show slave status\G;

    2、現象：從數據庫無法同步，show slave status顯示Slave_IO_Running爲No,Seconds_Behind_Master
    爲null

           解決：重啓主數據庫,server-id需要不同
查看server-id
mysql> show variables like 'server_id';
手動修改server-id
mysql> set global server_id=2; #此處的數值和my.cnf裏設置的一樣就行
mysql> slave start;

#service mysql restart

mysql> show master status;
    +------------------+----------+--------------+------------------+
    | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +------------------+----------+--------------+------------------+
    | mysql-bin.000001 | 98 | | |
    +------------------+----------+--------------+------------------+
    slave stop;
    change master to Master_Log_File='mysql-bin.000001',Master_Log_Pos=98
    slave start;
    或是這樣：
    stop slave;
    set global sql_slave_skip_counter =1;
    start slave;

    這個現象主要是master數據庫存在問題，我在實際的操作中先重啓master後重啓slave即可解決這問題，
    出現此問題，必須要要重啓master數據庫。

    1.主輔庫同步主要是通過二進制日誌來實現同步的。
    2.在啓動輔庫的時候必須先把數據同步，並刪除日誌目錄下的：master.info文件。因爲master.info記錄
    了上次要連接主庫的信息，如果不刪除，即使my.cnf裏進行了修改，也不起作用。因爲讀取的還是
    master.info文件裏的信息。

    在mysql複製環境中,有8個參數可以讓我們控制,需要複製或需要忽略不進行復制的DB或table分別爲:
    下面二項需要在Master上設置：
    Binlog_Do_DB:設定哪些數據庫需要記錄Binlog
    Binlog_Ignore_DB:設定哪裏數據庫不需要記錄Binlog

    優點是Master端的Binlog記錄所帶來的Io量減少，網絡IO減少，還會讓slave端的IO線程,SQL線程減少，
    從而大幅提高複製性能,
    缺點是mysql判斷是否需要複製某個事件不是根據產生該事件的查詢所在的DB,而是根據執行查詢時刻所在
    的默認數據庫（也就是登錄時指定的庫名或運行"use database"中指定的DB）,只有當前默認DB和配置中
    所設定的DB完全吻合時IO線程纔會將該事件讀取給slave的IO線程.所以,如果在默認 DB和設定須要複製的
    DB不一樣的情況下改變了須要複製的DB中某個Table中的數據,該事件是不會被複制到Slave中去的,這樣就
    會造成Slave端的數據和Master的數據不一致.同樣,在默認的數據庫下更改了不須要複製的數據庫中的數據,
    則會被複制到slave端,當slave端並沒有該數據庫時,則會造成複製出錯而停止.

    下面六項需要在slave上設置：
    Replicate_Do_DB:設定需要複製的數據庫,多個DB用逗號分隔
    Replicate_Ignore_DB:設定可以忽略的數據庫.
    Replicate_Do_Table:設定需要複製的Table
    Replicate_Ignore_Table:設定可以忽略的Table
    Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但可以帶通配符來進行設置。
    Replicate_Wild_Ignore_Table:功能同Replicate_Do_Table,功能同Replicate_Ignore_Table,可以帶通配符。

    優點是在slave端設置複製過濾機制,可以保證不會出現因爲默認的數據庫問題而造成Slave和Master數據
    不一致或複製出錯的問題.
    缺點是性能方面比在Master端差一些.原因在於:不管是否須要複製,事件都會被IO線程讀取到Slave端,
    這樣不僅增加了網絡IO量,也給Slave端的IO線程增加了Relay Log的寫入量.
    同步原理說明
    MySQL的Replication基於主服務器在二進制日誌中跟蹤所有對數據庫的更改(更新、刪除等)。
    MySQL使用3個線程來完成Replication工作，具體分佈是主上1個相關線程、從上2個相關線程；
    主的相關線程可以理解爲主服務器上SHOW PROCESSLIST的輸出中的Binlog Dump線程、從服務器分別爲IO和
    SQL線程;
    主服務器創建將binlog中的內容發送到從服務器。從服務器I/O線程讀取主服務器Binlog Dump線程發送的
    內容並將該數據拷貝到從服務器數據目錄中的中繼日誌文件（relay-log）裏，SQL線程用於讀取中繼日誌
    並執行日誌中包含的更新。
    MySQL的Replication是單向，異步同步
    MySQL同步機制基於master把所有對數據庫的更新、刪除等)都記錄在二進制日誌裏。因此，想要啓用同步
    機制，在master就必須啓用二進制日誌。每個slave接受來自master上在二進制日誌中記錄的更新操作，
    因此在slave上執行了這個操作的一個拷貝。應該非常重要地意識到，二進制日誌只是從啓用二進制日誌開
    始的時刻才記錄更新操作的。所有的 slave必須在啓用二進制日誌時把master上已經存在的數據拷貝過來。
    如果運行同步時slave上的數據和master上啓用二進制日誌時的數據不一致的話，那麼slave同步就會失敗。
    把master上的數據拷貝過來的方法之一實在slave上執行 LOAD DATA FROM MASTER 語句。不過要注意，LOAD DATA FROM MASTER是從MySQL 4.0.0之後纔開始可以用的，而且只支持master上的 MyISAM 類型表。同樣地，
    這個操作需要一個全局的讀鎖，這樣的話傳送日誌到slave的時候在master上就不會有更新操作了。當實現了
    自由鎖表熱備份時(在 MySQL 5.0中)，全局讀鎖就沒必要了。由於有這些限制，因此我們建議只在master上
    相關數據比較小的時候才執行 LOAD DATA FROM MASTER 語句，或者在master上允許一個長時間的讀鎖。
    由於每個系統之間 LOAD DATA FROM MASTER 的速度各不一樣，一個比較好的衡量規則是每秒能拷貝1MB數據。
    這只是的粗略的估計，不過master和slave都是奔騰700MHz的機器且用 100MBit/s網絡連接時就能達到這個
    速度了。slave上已經完整拷貝master數據後，就可以連接到master上然後等待處理更新了。如果 master
    當機或者slave連接斷開，slave會定期嘗試連接到master上直到能重連並且等待更新。重試的時間間隔由 –master-connect-retry 選項來控制，它的默認值是60秒。每個slave都記錄了它關閉時的日誌位置。
    master是不知道有多少個slave連接上來或者哪個slave從什麼時候開始更新。

    MySQL同步功能由3個線程(master上1個，slave上2個)來實現。執行 START SLAVE 語句後，slave就創建
    一個I/O線程。I/O線程連接到master上，並請求master發送二進制日誌中的語句。master創建一個線程來把
    日誌的內容發送到slave上。這個線程在master上執行 SHOW PROCESSLIST 語句後的結果中的 Binlog Dump
    線程便是。slave上的I/O線程讀取master的 Binlog Dump 線程發送的語句，並且把它們拷貝到其數據目錄
    下的中繼日誌(relay logs)中。第三個是SQL線程，salve用它來讀取中繼日誌，然後執行它們來更新數據。
    如上所述，每個mster/slave上都有3個線程。每個 master上有多個線程，它爲每個slave連接都創建一個線程，每個slave只有I/O和SQL線程。在MySQL 4.0.2以前，同步只需2個線程(master和slave各一個)。slave上的I/O
    和SQL線程合併成一個了，它不使用中繼日誌。slave上使用2個線程的優點是，把讀日誌和執行分開成2個
    獨立的任務。執行任務如果慢的話，讀日誌任務不會跟着慢下來。例如，如果slave停止了一段時間，那麼
    I/O線程可以在slave啓動後很快地從master上讀取全部日誌，儘管SQL線程可能落後I/O線程好幾的小時。
    如果slave在SQL線程沒全部執行完就停止了，但I/O線程卻已經把所有的更新日誌都讀取並且保存在本地的中
    繼日誌（relay-log）中了，因此在slave再次啓動後就會繼續執行它們了。這就允許在 master上清除二進制
    日誌，因爲slave已經無需去master讀取更新日誌了。執行 SHOW PROCESSLIST 語句就會告訴我們所關心的master和slave上發生的情況。

    注：
如果主服務器重啓了，那麼需要將從服務器上的slave重啓才能進行復制

zabbix自定義監控

sed命令詳解

Atlas 安裝和配置

我的友情鏈接

mysql主從複製

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結