mysql主從伺服器複製操作

標籤：檔案拷貝   src   搭建   方式   span   多級   高效能   停止   databases   

master主機ip：192.168.1.19  使用者名稱sunzy 密碼123456
slave主機ip：192.168.1.20

1.配置master
1)接下來對master進行配置，包括開啟二進位日誌，指定唯一的servr ID。例如，在設定檔加入如下值：
    [mysql]
    log-bin=mysql-bin   #二進位變更日值,[必須]啟用二進位日誌
    server-id=1    #為主服務master的ID值
2)重啟master服務，運行SHOW MASTER STATUS,查看配置情況。

2.建立複製帳號
    在Master的資料庫中建立一個備份帳戶：每個slave使用標準的MySQL使用者名稱和密碼串連master。進行複製操作的使用者會授予REPLICATION SLAVE許可權。使用者名稱的密碼都會儲存在文字檔master.info中。
命令如下：
    mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* ‘TO backup‘@‘192.168.1.20‘ IDENTIFIED BY ‘1234‘;
建立一個帳戶backup，並且只能允許從192.168.1.20這個地址上來登陸，密碼是1234。

3.配置slave
Slave的配置與master類似，你同樣需要重啟slave的MySQL。如下：
    log_bin           = mysql-bin
    server_id         = 2             #server_id是必須的，而且唯一
    relay_log         = mysql-relay-bin
    log_slave_updates = 1
    read_only         = 1
　　slave沒有必要開啟二進位日誌，但是在一些情況下，必須設定，例如，如果slave為其它slave的master，必須設定bin_log。在這裡，我們開啟了二進位日誌，而且顯示的命名(預設名稱為hostname，但是，如果hostname改變則會出現問題)。
　　relay_log配置中繼日誌
　　log_slave_updates表示slave將複製事件寫進自己的二進位日誌(後面會看到它的用處)。
　　有些人開啟了slave的二進位日誌，卻沒有設定log_slave_updates，然後查看slave的資料是否改變，這是一種錯誤的配置。所以，盡量使用read_only，它防止改變資料(除了特殊的線程)。但是，read_only並是很實用，特別是那些需要在slave上建立表的應用。

 

4.配置從伺服器slave
1)接下來就是讓slave串連master，並開始重做master二進位日誌中的事件。你不應該用設定檔進行該操作，而應該使用CHANGE MASTER TO語句，該語句可以完全取代對設定檔的修改，而且它可以為slave指定不同的master，而不需要停止伺服器。如下：
　　mysql> CHANGE MASTER TO MASTER_HOST=‘192.168.1.19‘,
   　   　 -> MASTER_USER=‘sunzy‘,
   　   　 -> MASTER_PASSWORD=‘123456‘,
  　　     -> MASTER_LOG_FILE=‘mysql-bin.000001‘,
  　　     -> MASTER_LOG_POS=0;          #MASTER_LOG_POS的值為0，因為它是日誌的開始位置。
2)啟動從伺服器複製功能
　　mysql>start slave; 
3）你可以用SHOW SLAVE STATUS語句查看slave的設定是否正確。
     mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
              Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.19
                  Master_User: sunzy
                   Master_Port: 3306
               Connect_Retry: 60
             Master_Log_File: mysql-bin.000001
     Read_Master_Log_Pos: 164
     Relay_Master_Log_File: mysql-bin.000001
                Relay_Log_Pos: 164
                Relay_Log_File: mysql-relay-bin.000001
           Slave_IO_Running: Yes
         Slave_SQL_Running: Yes
                             ...omitted...
      Seconds_Behind_Master: 0

在這裡主要是看:
                   Slave_IO_Running=Yes
                   Slave_SQL_Running=Yes
slave的I/O和SQL線程都已經開始運行，而且Seconds_Behind_Master不再是NULL。日誌的位置增加了，意味著一些事件被擷取並執行了。如果你在master上進行修改，你可以在slave上看到各種記錄檔的位置的變化，同樣，你也可以看到資料庫中資料的變化。

4)你可查看master和slave上線程的狀態。
　　　在master上輸入show processlist\G;   #在master上，你可以看到slave的I/O線程建立的串連：
        在slave上輸入show processlist\G;    #SQL線程狀態

5.添加新slave伺服器
假如master已經運行很久了，想對新安裝的slave進行資料同步，甚至它沒有master的資料。
此時，有幾種方法可以使slave從另一個服務開始，例如，從master拷貝資料，從另一個slave複製，從最近的備份開始一個slave。Slave與master同步時，需要三樣東西：
　　(1)master的某個時刻的資料快照；
　　(2)master當前的記錄檔、以及產生快照時的位元組位移。這兩個值可以叫做記錄檔座標(log file coordinate)，因為它們確定了一個二進位日誌的位置，你可以用SHOW MASTER STATUS命令找到記錄檔的座標；
　　(3)master的二進位記錄檔。

可以通過以下幾中方法來複製一個slave：
(1)    冷拷貝(cold copy)
　　   停止master，將master的檔案拷貝到slave；然後重啟master。缺點很明顯。
(2)    熱拷貝(warm copy)
　　  如果你僅使用MyISAM表，你可以使用mysqlhotcopy拷貝，即使伺服器正在運行。
(3)    使用mysqldump
　　  使用mysqldump來得到一個資料快照可分為以下幾步：
　　　　<1>鎖表：如果你還沒有鎖表，你應該對錶加鎖，防止其它串連修改資料庫，否則，你得到的資料可以是不一致的。如下：
　　　　　　mysql> FLUSH TABLES WITH READ LOCK;
　　　　<2>在另一個串連用mysqldump建立一個你想進行複製的資料庫的轉儲：
　　　　　　shell> mysqldump --all-databases --lock-all-tables >dbdump.db
　　　　<3>對錶釋放鎖。
　　　　　　mysql> UNLOCK TABLES;

 

附：複製的常用拓撲結構
複製的體繫結構有以下一些基本原則：
　　(1) 每個slave只能有一個master；
　　(2) 每個slave只能有一個唯一的伺服器ID；
　　(3) 每個master可以有很多slave；
　　(4) 如果你設定log_slave_updates，slave可以是其它slave的master，從而擴散master的更新。

MySQL不支援多主伺服器複製(Multimaster Replication)——即一個slave可以有多個master。但是，通過一些簡單的組合，我們卻可以建立靈活而強大的複製體繫結構。
1、單一master和多slave
　　由一個master和一個slave組成複製系統是最簡單的情況。Slave之間並不相互連信，只能與master進行通訊。
　　在實際應用情境中，MySQL複製90%以上都是一個Master複製到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的資料庫端廉價擴充解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，非同步複製的延時一般都很少很少。尤其是自從Slave端的複製方式改成兩個線程處理之後，更是減小了Slave端的延時問題。而帶來的效益是，對於資料即時性要求不是特別Critical的應用，只需要通過廉價的pcserver來擴充Slave的數量，將讀壓力分散到多台Slave的機器上面，即可通過分散單台資料庫伺服器的讀壓力來解決資料庫端的讀效能瓶頸，畢竟在大多數資料庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的資料庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決資料庫瓶頸。
如下：

      

 如果寫操作較少，而讀操作很時，可以採取這種結構。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當slave增加到一定數量時，slave對master的負載以及網路頻寬都會成為一個嚴重的問題。
這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：
　　(1)    不同的slave扮演不同的作用(例如使用不同的索引，或者不同的儲存引擎)；
　　(2)    用一個slave作為備用master，只進行複製；
　　(3)    用一個遠端slave，用於災難恢複；

 

 2、主動模式的Master-Master(Master-Master in Active-Active Mode)
Master-Master複製的兩台伺服器，既是master，又是另一台伺服器的slave。這樣，任何一方所做的變更，都會通過複製應用到另外一方的資料庫中。

　　可能有些讀者朋友會有一個擔心，這樣搭建複製環境之後，難道不會造成兩台MySQL之間的迴圈複製嗎？實際上MySQL自己早就想到了這一點，所以在MySQL的BinaryLog中記錄了當前MySQL的server-id，而且這個參數也是我們搭建MySQLReplication的時候必須明確指定，而且Master和Slave的server-id參數值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之後，MySQL就很容易判斷某個變更是從哪一個MySQLServer最初產生的，所以就很容易避免出現迴圈複製的情況。而且，如果我們不開啟記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄複製過程中的變更到BinaryLog中，就更不用擔心可能會出現迴圈複製的情形了。

如下：
        
主動的Master-Master複製有一些特殊的用處。例如，地理上分布的兩個部分都需要自己的可寫的資料副本。這種結構最大的問題就是更新衝突。假設一個表只有一行(一列)的資料，其值為1，如果兩個伺服器分別同時執行如下語句：
　　在第一個伺服器上執行：
　　　　mysql> UPDATE tbl SET col=col + 1;
　　在第二個伺服器上執行：
　　　　mysql> UPDATE tbl SET col=col * 2;
那麼結果是多少呢？一台伺服器是4，另一個伺服器是3，但是，這並不會產生錯誤。
實際上，MySQL並不支援其它一些DBMS支援的多主伺服器複製(Multimaster Replication)，這是MySQL的複製功能很大的一個限制(多主伺服器的痛點在於解決更新衝突)，但是，如果你實在有這種需求，你可以採用MySQL Cluster，以及將Cluster和Replication結合起來，可以建立強大的高效能的資料庫平台。但是，可以通過其它一些方式來類比這種多主伺服器的複製。

 

 3、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)
這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在於其中一個服務只能進行唯讀操作。

       

 

多級聯複製架構 Master –Slaves - Slaves
　　在有些應用情境中，可能讀寫壓力差別比較大，讀壓力特別的大，一個Master可能需要上10台甚至更多的Slave才能夠支撐注讀的壓力。這時候，Master就會比較吃力了，因為僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端因為複製就會消耗較多的資源，很容易造成複製的延時。
　　遇到這種情況如何解決呢？這時候我們就可以利用MySQL可以在Slave端記錄複製所產生變更的BinaryLog資訊的功能，也就是開啟—log-slave-update選項。然後，通過二級（或者是更多層級）複製來減少Master端因為複製所帶來的壓力。也就是說，我們首先通過少數幾台MySQL從Master來進行複製，這幾台機器我們姑且稱之為第一級Slave叢集，然後其他的Slave再從第一級Slave叢集來進行複製。從第一級Slave進行複製的Slave，我稱之為第二級Slave叢集。如果有需要，我們可以繼續往下增加更多層次的複製。這樣，我們很容易就控制了每一台MySQL上面所附屬Slave的數量。這種架構我稱之為Master-Slaves-Slaves架構。這種多層級聯複製的架構，很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風險。展示了多層級聯複製的Replication架構。

                                            

 當然，如果條件允許，我更傾向於建議大家通過拆分成多個Replication叢集來解決。
　　上述瓶頸問題。畢竟Slave並沒有減少寫的量，所有Slave實際上仍然還是應用了所有的資料變更操作，沒有減少任何寫IO。相反，Slave越多，整個叢集的寫IO總量也就會越多，我們沒有非常明顯的感覺，僅僅只是因為分散到了多台機器上面，所以不是很容易表現出來。
　　此外，增加複製的級聯層次，同一個變更傳到最底層的Slave所需要經過的MySQL也會更多，同樣可能造成延時較長的風險。
　　而如果我們通過分拆叢集的方式來解決的話，可能就會要好很多了，當然，分拆叢集也需要更複雜的技術和更複雜的應用系統架構。

 

mysql主從伺服器複製操作