咱們通常使用 MySQL 的時候,若是數據量不大,只使用一臺 MySQL 服務器,備份的時候使用 mysqldump 工具就能夠了,可是隨着業務不斷髮展,問題出現了:數據量直線上升,單獨一臺數據庫服務器開始出現性能的瓶頸,數據訪問愈來愈慢。備份也變得困難了,由於 mysqldump 是導出一份文本文件,而數據量特別大的時候,這樣的備份每每須要很長時間。
若是你遇到了相似上面的問題,你就可使用創建 MySQL 主從服務器的複製方式來解決,MySQL 的複製有如下幾個優點:主服務器/從服務器設置增長了健壯性,主服務器出現問題時,你能夠切換到從服務器繼續提供服務。經過在從服務器上執行查詢操做來下降客戶查詢的負荷,能夠獲得更好的客戶響應時間,可是不要同時在主從服務器上進行更新,這樣可能引發衝突。使用複製的另外一個好處是可使用一個從服務器執行備份,而不會干擾主服務器。在備份過程當中主服務器能夠繼續處理更新。node
MySQL 複製的原理:
MySQL使用3個線程來執行復制功能,其中1個在主服務器上,另兩個在從服務器上。當發出START SLAVE時,從服務器建立一個I/O線程,以鏈接主服務器並讓主服務器發送二進制日誌。主服務器建立一個線程將二進制日誌中的內容發送到從服務器。從服務器I/O線程讀取主服務器Binlog Dump線程發送的內容並將該數據拷貝到從服務器數據目錄中的本地文件中,即中繼日誌。第3個線程是SQL線程,從服務器使用此線程讀取中繼日誌並執行日誌中包含的更新。SHOW PROCESSLIST語句能夠查詢在主服務器上和從服務器上發生的關於複製的信息。
默認中繼日誌使用host_name-relay-bin.nnnnnn形式的文件名,其中host_name是從服務器主機名,nnnnnn是序列號。用連續序列號來建立連續中繼日誌文件,從000001開始。從服務器跟蹤中繼日誌索引文件來識別目前正使用的中繼日誌。默認中繼日誌索引文件名爲host_name-relay-bin.index。在默認狀況,這些文件在從服務器的數據目錄中被建立。中繼日誌與二進制日誌的格式相同,而且能夠用mysqlbinlog讀取。當SQL線程執行完中繼日誌中的全部事件後,中繼日誌將會被自動刪除。mysql
設置 MySQL 主從複製:
注意:MySQL 主從服務器最好使用相同的軟件版本,以免不不可預期的故障。
軟件環境:系統 rhel4u8,MySQL-5.1.44,
主服務器ip:192.168.0.1 hostname:node1
從服務器ip:192.168.0.2 hostname:node2sql
設置主服務器數據庫
一、編輯 /etc/hosts (此步非必須)
增長如下內容:服務器
192.168.0.2 node2 |
二、在主服務器上創建一個爲從服務器進行復制使用的用戶。該帳戶必須授予 REPLICATION SLAVE 權限,因爲僅僅是進行復制使用因此不須要再授予任何其它權限。ide
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'192.168.0.2' IDENTIFIED BY 'slavepasswd'; mysql> FLUSH PRIVILEGES; |
三、編輯主服務器的配置文件:/etc/my.cnf的[ mysqld ] 部分:
server-id = 本機數據庫 ID 標示,該部分還應有一個server-id=Master_id選項,其中master_id必須爲1到232之間的一個正整數值
log-bin = 二進制日誌的位置和名稱
binlog-do-db = 須要備份的數據庫名,若是備份多個數據庫,重複設置這個選項便可
binlog-ignore-db = 不須要備份的數據庫苦命,若是備份多個數據庫,重複設置這個選項便可工具
個人主服務器設置爲:性能
server-id = 1 log-bin=/usr/local/mysql/data/mysql-bin.000001 binlog-do-db = wapnews binlog-ignore-db = mysql binlog-ignore-db = test binlog-ignore-db = information_schema |
四、主服務器執行FLUSH TABLES WITH READ LOCK語句清空全部表和塊寫入語句:spa
mysql> FLUSH TABLES WITH READ LOCK; |
五、保持mysql客戶端程序不要退出。開啓另外一個終端對主服務器數據目錄作備份。線程
[root@node1 ~]# cd /usr/local/mysql/data [root@node1 ~]# tar -zcvf /tmp/mysql-wapnews.tar.gz ./wapnews |
把備份完畢的數據庫備份複製到從服務器上。
六、當FLUSH TABLES WITH READ LOCK所置讀鎖定有效時(即mysql客戶端程序不退出),讀取主服務器上當前的二進制日誌名和偏移量值:
mysql > SHOW MASTER STATUS; +-----------------------------+---------------+-------------------------+--------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------------------+---------------+-------------------------+--------------------------------------------+ | mysql-bin.000001 | 73 | wapnews | test,mysql,information_schema | +------------------------------+---------------+-------------------------+--------------------------------------------+ |
File列顯示日誌名,而Position顯示偏移量。在該例子中,二進制日誌值爲mysql-bin.000001,偏移量爲73。記錄該值。之後設置從服務器時須要使用這些值。它們表示複製座標,從服務器應從該點開始從主服務器上進行新的更新。
取得快照並記錄日誌名和偏移量後,回到前一中端從新啓用寫活動:
mysql> UNLOCK TABLES; |
設置從服務器:
一、編輯/etc/hosts (此步非必要)
增長如下內容:
192.168.0.1 node1 |
二、中止從服務器上的mysqld服務並編輯從服務器的配置文件:/etc/my.cnf 的[ mysqld ] 部分:
server-id = 本機數據庫 ID 標示,該部分還應有一個server-id=Master_id選項,其中master_id必須爲1到232之間的一個正整數值
[root@node2 ~]# service mysqld stop |
個人從服務器配置
server-id=2 |
三、將主服務器數據庫備份恢復到從服務器的數據目錄中。確保對這些文件和目錄的權限正確。服務器 MySQL運行的用戶必須可以讀寫文件,如同在主服務器上同樣。
[root@node2 ~]# cd /usr/local/mysql/data [root@node2 ~]# tar -zxvf mysql-wapnews.tar.gz [root@node2 ~]# chown -R mysql:mysql /usr/local/mysql/data/wapnews |
四、啓動從服務器。在從服務器上執行下面的語句,用你的系統的實際值替換選項值:
mysql> CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
個人從服務器設置:
mysql> change master to -> master_host='192.168.0.1', -> master_user='replication', -> master_password='slavepass', -> master_port=3306 -> master_log_file='mysql-bin.000001', -> master_log_pos=73, -> master_connect_retry=30; |
五、啓動從服務器線程:
mysql> START SLAVE; |
執行這些程序後,從服務器應鏈接主服務器,並補充自從快照以來發生的任何更新。
檢查主從複製是否正常運行
在從服務器上運行 show processlist 命令,檢查是否啓動兩個複製進程。
mysql> show processlist \G; *************************** 1. row *************************** Id: 44 User: system user Host: db: NULL Command: Connect Time: 490 State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 45 User: system user Host: db: NULL Command: Connect Time: 390 State: Has read all relay log; waiting for the slave I/O thread to update it Info: NULL 3 rows in set (0.00 sec) |
在從服務器上運行 show slave status 命令,檢查複製進程是否正確。
mysql> show slave status \G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.1 Master_User: replication Master_Port: 3306 Connect_Retry: 30 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 73 Relay_Log_File: localhost-relay-bin.000002 Relay_Log_Pos: 251 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: 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: 106 Relay_Log_Space: 410 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 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: 1 row in set (0.00 sec) |
上面出現: Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 表示複製正常,若是有一個顯示是NO,請檢查以上的主從設置步驟是否正確。若是出現複製錯誤,從服務器的錯誤日誌(HOSTNAME.err)中也會出現錯誤消息。
注意:從服務器複製時,會在其數據目錄中發現文件master.info和HOSTNAME-relay-log.info。狀態文件保存在硬盤上,從服務器關閉時不會丟失。下次從服務器啓動時,讀取這些文件以肯定它已經從主服務器讀取了多少二進制日誌,以及處理本身的中繼日誌的程度。不要移除或編輯這些文件,除非你確切知你正在作什麼並徹底理解其意義。即便這樣,最好是使用CHANGE MASTER TO語句。