MySQL主從複製解決數據庫單點問題

1、單個數據庫服務器的缺點

 

• 數據庫服務器存在單點問題；

• 數據庫服務器資源沒法知足增加的讀寫請求；

• 高峯時數據庫鏈接數常常超過上限。

 

2、如何解決單點問題

 

• 增長額外的數據庫服務器，組建數據庫集羣；

• 同一集羣中的數據庫服務器須要具備相同的數據；

• 集羣中的任一服務器宕機後，其它服務器能夠取代宕機服務器。

 

3、MySQL主從複製架構

 

一、主庫將變動寫入到主庫的binlog中

 

• 一些MySQL版本並不會開啓二進制日誌，因此必定要檢查是否開啓；

• 若是剛開始沒有開啓，後面再進行開啓的話，須要重啓數據庫才能生效，並且數據庫的重啓每每會對業務形成很大的影響；

• 儘管二進制日誌對性能有稍許的影響，因此仍是建議你們不管是否使用複製功能，都要開啓MySQL二進制日誌，由於增量備份也須要二進制日誌。

 

二、從庫的IO線程在指定位置讀取主庫binlog內容存儲到本地的中繼日誌（Relay Log）中

 

要完成二進制日誌的傳輸過程，MySQL會在從服務器上啓動一個工做線程，稱爲IO線程，這個IO線程會跟主數據庫創建一個普通的客戶端鏈接，而後在主服務器上啓動一個特殊的二進制轉儲線程稱爲binlogdown線程。

 

從庫上的IO線程經過這個二進制轉儲線程來讀取主庫上的二進制事件，若是該事件追遇上主庫，則會進入sleep狀態，直到主庫發起信號通知有新事件產生時，纔會被喚醒，relay log的格式和binlog格式是徹底相同的，

 

可使用mysqlbinlog來讀取relay log中的內容。

 

三、從庫的SQL線程讀取Relay Log日誌中的內容，並在從庫中重放

 

SQL線程所執行的事件，咱們能夠經過配置選項來決定是否要寫入到從服務器的二進制日誌中。

 

目前MySQL支持兩種複製類型：

 

• 基於二進制日誌點的複製

• 基於GTID的複製（MySQL>=5.7推薦使用）

 

4、MySQL主從配置步驟

 

一、配置主從數據庫服務器參數

 

有些參數配置後須要數據庫重啓才能生效，爲了避免影響數據庫的正常使用，咱們最好在服務器上線的同時就把參數都配置好。特別是master服務器的參數，更應該做爲服務器初始參數來進行配置。

 

master服務器：

 

 

slave 服務器：

 

 

二、在master服務器上建立用於複製的數據庫帳號

 

用於IO線程鏈接master服務器獲取binlog日誌，須要* REPLICATION SLAVE** 權限：

create user 'repl'@'ip段' identified by 'password';
grant replication slave on *.* to 'repl'@'ip段';

三、備份master服務器上的數據並初始化slave服務器數據

 

• 建議主從數據庫服務器採用相同的MySQL版本；

• 建議使用全庫備份的方式初始化slave數據。

 

採用相同版本的好處：

 

• 咱們可使用全備的方式來初始化slave數據，還能夠避免不一樣版本之間的差別形成數據庫同步失敗的問題。

• 若是咱們使用的主從複製的服務器MySQL版本不一樣，則必定要注意master上的版本必定要低於slave服務器，否則同步的時候就可能出現錯誤。

 

因爲咱們演示過程當中的MySQL服務器都是使用的MySQL5.7，因此咱們可使用全備的方式進行：

mysqldump --master-data=2 -uroot -p -A --single-transaction -R --triggers

 

 

四、啓動基於日誌點的複製鏈路

 

在slave服務器上運行，MySQL命令：

CHANGE MASTER TO

MASTER_HOST= 'master_host_ip',

MASTER_USER= 'repl',

MASTER_PASSWORD = 'password',

MASTER_LOG_FILE='mysql_log_file_name',

MASTER_LOG_POS=xxxxxx;

 

 

五、啓動基於GTID的複製鏈路

 

GTID：全局事務ID，GTID能夠保證每個在主上提交的事務，在複製集羣中能夠生成一個惟一的ID值，要使用基於GTID的複製，咱們要在主從複製的配置文件中同時加入如下配置項。

 

MySQL配置：

gtid_mode=on 
# 是否啓動gtid模式，啓動了此模式會在二進制日誌中會額外記錄每一個事務的GTID標識符

enforce-gtid-consistency 
# 強制gtid一致性，用於保證啓動gtid後事務的安全

log-slave-updates = on 
# mysql5.6必定要啓用參數，5.7能夠不啓用

 

 

MySQL命令：

CHANGE MASTER TO

MASTER_HOST= 'master_host_ip',

MASTER_USER= 'repl',

MASTER_PASSWORD = 'password',

MASTER_AUTO_POSITION=1;

 

 

 

GTID複製的限制：

 

• 沒法再使用create table ... select語句創建表，只能先create表，再insert數據；

• 沒法在事務中使用create temporary table創建臨時表；

• 沒法使用關聯更新同時更新事務表和非事務表。

 

4和5中選一個執行便可。

 

五. MySQL主從複製演示

 

1. 先對主服務器進行配置

 

 

因爲主服務器一直在運行着，在生產環境中主服務器是不多會重啓的，若是主服務器重啓，會形成正常的業務訪問的中斷，因此在服務器啓動以前就啓動了二進制日誌。

 

這裏不須要重啓主服務器了，因爲主服務器的默認server_id=1，咱們雖然在配置文件中更改了它的值 ，但實際運行環境中並無改變。

 

咱們能夠查看一下當前server_id：

mysql> show variables like '%server_id%';

 

 

能夠經過如下命令動態的進行修改：

mysql> set global server_id = 100;

 

 

2. 再對從服務器進行配置

 

 

修改完從服務器配置後，重啓MySQL服務器。若是使用的是MySQL5.7版本的須要注意：

 

• MySQL5.7增長了server-uuid值，默認狀況下載auto.cnf文件中，若是是使用的鏡像的方式安裝，可能你們的uuid同樣 ，因此須要把auto.cnf文件刪除掉。MySQL重啓後會自動從新生成uuid的值，這樣就能夠保證不一樣服務器上的MySQL實例的uuid的值是不同的；

• 若是server-uuid的值相同，主從複製會出現問題。

 

以上咱們就完成了主從複製的配置，接下來咱們要在主服務器上創建複製帳號。

 

3. 在MySQL主服務器上創建MySQL複製帳號

mysql> create user 'dba_repl'@'192.168.3.%' identified by '123456';

mysql> grant replication slave on *.* to 'dba_repl'@'192.168.3.%';

 

 

4. 創建好複製帳號之後，經過mysql主服務器上的全備初始化從服務器上數據

 

進行全備：

[root@localhost data]# cd /data/db_backup/

[root@localhost db_backup]# mysqldump -uroot -p --master-data=1 --single-transaction --routines --triggers --events --all-databases > all.sql

Enter password:

 

將其拷貝到從服務器上：

 

[root@localhost db_backup]# scp all.sql root@192.168.3.101:/root

 

 

在從服務器上恢復備份進行初始化：

 

[root@Node2 ~]# mysql -uroot -p < all.sql

 

 

 

初始化完成後，準備。

 

5. 從服務器進行基於日誌點的複製鏈路的配置

 

mysql> change master to 
master_host='192.168.3.100',
master_user='dba_repl',
master_password='123456',
MASTER_LOG_FILE='mysql-bin.000017',
MASTER_LOG_POS=663;

 

MASTER_LOG_FILE和MASTER_LOG_POS的值從全備文件中的CHANGE MASTER中獲取

 

 

以上覆制鏈路的配置完成。

 

啓動slave：

 

mysql> start slave;

 

 

檢查是否啓動成功狀態：

 

mysql> show slave status \G

 

顯示：

Relay_Master_Log_File: mysql-bin.000017

Slave_IO_Running：Yes

Slave_SQL_Running: Yes

 

說明啓動成功了，能夠在主服務器上插入數據，在從服務上查看數據是否同步過來了。

 

六. 主從複製的一些缺點

 

雖然主從複製增長了一個數據庫副本，但從數據庫和主數據庫的數據最終會是一致的。之因此說是最終一致，由於MySQL複製是異步的，正常狀況下主從複製數據之間會有一個微小的延遲。

 

經過這個數據庫副本看似解決了數據庫單點問題，但並不完美：由於這種架構下，若是主服務器宕機，須要手動切換從服務器，業務中斷不能忍受，不能知足應用高可用的要求。

手動切換的問題能夠了解一下keepalived

 

看到了好文章就摘下來了。下面是文章的源出處

文章轉自：https://mp.weixin.qq.com/s/3daDORzzNGphiS_dXd8gGw