mysql複製是將主數據庫的DDL和DML操做經過二進制日誌傳到複製服務器(也叫從服務器)上,而後在從服務器上對這些日誌從新執行(也叫重作),從而使從服務器和豬服務器的數據保持同步。
mysql複製的優勢主要包括如下3個方面:
1)若是主服務器出現問題,能夠快速切換到從服務器提供服務。
2)能夠在從服務上執行查詢操做,下降主服務器的訪問壓力。只有更新不頻繁的數據和對實時性要求不高的數據能夠經過從服務器查詢。
3)能夠在從服務器上執行備份,以免備份期間影響主服務器的服務。
1、安裝配置。
確保主從服務器安裝相同版本的mysql,推薦安裝最新穩定版本。
1. 在主服務器上設置一個複製使用的帳戶,並授予REPLICATION SLAVE 權限,這裏建立一個複製用戶repl 能夠從ip爲172.16.27.21的主機進
行鏈接:
引用
mysql>GRANT REPLICATION SLAVE ON * . * TO 'repl' @ ' 172.16.27.21' IDENTIFIED BY '123456';
2. 修改主服務器的my.cnf文件 開啓binlog 並設置server-id值。這兩個參數須要重啓mysql才能生效。
引用
[mysqld]
log-bin = mysql-bin
server-id =1
3. 而後在主數據上設置讀鎖定有效,這個操做是爲了確保沒有數據庫操做,以便獲取得一個一致性快照。
引用
mysql> flush tables with read lock;
4. 而後獲得住數據庫當前二進制日誌名和偏移量值。這個操做的目的是爲了從數據庫啓動後從這個點開始進行數據的恢復。
引用
mysql > show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000069 | 194548 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
5. 將主數據庫備份恢復到從數據庫上,主數據庫能夠恢復寫操做,剩下的操做只須要在從數據庫執行;
引用
mysql > unlock tables;
6. 修改從數據庫的配置文件my.cnf 增長server-id 參數 注意server-id的值必須是惟一的不能和主服務器配置相同。若是有多個從服務器每
個從服務器必須有本身惟一的server-id值。
引用
[mysqld]
server-id = 2
#使從服務器把複製的事件記錄到本身的二進制日誌中
log_slave_updates = 1
master-host = 172.16.27.23
master-port = 3306
master-user = repl
master-password = 123456
replicate-do-db = my_blog
7.在從服務上使用--skip-slave-start 選項啓動從數據庫,這樣不會當即啓動從數據庫上的複製進程,方便咱們對從數據庫的服務進行進一步
的配置制定從服務器開始執行復制的日誌文件和位置:
引用
/usr/local/mysql/bin/mysqld_safe --skip-slave-start &
引用
mysql> CHANGE MASTER TO
-> MASTER_LOG_FILE='mysql-bin.000069',
-> MASTER_LOG_POS=194548;
Query OK, 0 rows affected (0.02 sec)
8. 從服務器上啓動slave線程
9. 查看從服務器狀態
引用
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.27.23
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000069
Read_Master_Log_Pos: 194548
Relay_Log_File: test-relay-bin.000002
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000069
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: my_blog
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: 194548
Relay_Log_Space: 405
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 和Slave_SQL_Running 這兩個線程的狀態是不是yes 這兩個線程的含義分別以下:
Slave_IO_Running 此線程負責從服務器從主服務器上讀取binlog日誌,並寫入從服務器上的中繼日誌中
Slave_SQL_Running 此線程負責讀取並執行中繼日誌中的binlog日誌,
只要其中有一個狀態時no ,則表示複製線程中止,錯誤緣由能夠從Last_Errno字段的值中看到。
2、主從服務器同步維護。
在某些繁忙的OLTP(在線事物處理)系統上,因爲主服務器更新頻繁,而從服務器因爲各類緣由致使更新速度較慢,從而使主從服務器之間的數據差距愈來愈大,在這種狀況下,咱們就須要按期的進行主從服務器的數據同步,使得主從數據差距能減小到最小,經常使用的方法是在負載較低的時候阻塞主數據庫的更新,強制主從數據庫更新同步。
1.在主服務器上 執行如下語句(注意,會阻塞主數據庫的全部更新操做)
引用
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000069 | 226897 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
記錄show 語句的輸出日誌名和偏移量,這些是從服務器複製的目的座標。
2. 在從服務器上執行下面的語句.
引用
mysql> select MASTER_POS_WAIT('mysql-bin.000069',' 226897 ');
+----------------------------------------------+
| MASTER_POS_WAIT('mysql-bin.000069',' 226897 ') |
+----------------------------------------------+
| 0 |
+----------------------------------------------+
1 row in set (0.01 sec)
其中MASTER_POS_WAIT()函數的參數就是前面的步驟中獲得的複製座標值。這個select 語句會阻塞直到從服務器達到指定的日誌文件和偏移量後返回0 若是返回-1則表示超時退出,查詢返回0時則從服務器與主服務器同步。
3. 在主服務器上執行下面的語句容許主服務器從新開始處理更新。
引用
mysql>UNLOCK TABLES; Query OK, 0 rows affected (0.00 sec)