您好,登錄后才能下訂單哦!
大家應該知道,mysql比起其他數據庫,最大的特色是就是主從復制,不過5.7之前的版本最多就只支持一主多從的復制方式,對于一些統計類的需求,就需要跨庫,這是比較麻煩的事情,以往只能交由數據庫中間件(mycat等)去做這種事情,還有備份操作,也只能一個個庫的用腳本去輪詢或并發備份,不可謂不費時費力。然后,多源復制的概念出來了。
多源復制的概念最早是mariadb社區提出的,后來mysql官方積極引入到5.7的版本中來(5.6最新版也是沒有這個功能的),percona就不說了,也是隨后推出。這個功能很好的解決了上面說的問題,最直接的當然是省事省錢了,如果把并發復制也開啟,在內網環境下,延時幾乎是可以忽略的。
個人建議,多源復制不宜做唯一的從庫,而是做第二/三從庫或層級從庫比較好,主要目的應該是統計庫或備份庫。因為通常來說,多源復制為了避免某些數據沖突是會忽略某些數據庫和表的復制的,而為了提高數據庫高可用,是需要整庫同步的,例如MHA和PXC環境幾乎就是要主從是一致的,這樣就有沖突而導致不能做高可用了,所以,做第二/三從庫或層級從庫才可以避免。
前置環境說明
現在測試的架構是主庫1的work1和主庫2的work2,進行多源復制到從庫3中,而且忽略系統庫mysql庫,這么簡單我就不打算畫圖了,估計網上也有很多,因為后面內容不少,我也不想占版面了,所以隨便說一下就算了。
主庫1:mysql版本:阿里云rdsmysql5.6.34,ip地址:10.2.0.5
主庫2:mysql版本:自建percona-server5.7.18,ip地址:10.2.0.6
從庫3:mysql版本:自建percona-server5.7.18,ip地址:10.2.0.7
目的就是:
主庫1---work1\
從庫3
主庫2---work2/
怎么搭建mysql數據庫我就不說了,這點各位自行研究,我想要看這篇文章的人估計在搭建方面至少是沒壓力的,同時也假設是有一定業務的數據庫存在,其實沒有也可以,模擬就行。
然后,看下面的操作。
導出與導入數據庫
就算不是做多源復制,普通的主從復制環境都需要把數據導出和導入數據,畢竟binlog不是一直都有記錄的(保留策略問題),數據量多起來的話,讓他從新跑也是不現實的。
而由于我們多源復制的原意是只復制有需求的數據庫,如果使用xtrabackup就不太合適了,因為默認也是會備份mysql庫的,這個時候用mysqldump就合適一些了,除非前面一個庫用xtrabackup,下一個用mysqldump就可以。我覺得mysqlpump和mydumper也是可以嘗試一下。
下面來看看操作
#從主庫導出數據庫 mysqldump -uroot -p'******' -h20.2.0.5 -P3306 --triggers -R --single-transaction \ --no-autocommit --master-data=2 -q -e --databases work1 >work1.sql mysqldump -uroot -p'******' -h20.2.0.6 -P3306 --triggers -R --single-transaction \ --no-autocommit --master-data=2 -q -e --databases work2 >work2.sql
可能導出的時候會有個warnings的警告,說會導出設定GTID的sql,不過這個正是我們后面需要的東西,所以可以忽略。
然后,就導入到目的從庫環境吧,只要數據不沖突,都可以導進去。理論上,多源復制要禁止一切同名數據庫的存在,不然就不是多源復制了。不過,有一種情況我覺得可以嘗試下,我個人還沒試過,就是同一個庫名,多源復制不同的數據表,各位有興趣可以自行嘗試,這里不展開。
#導入數據庫到從庫 mysql -uroot -p'******' -h20.2.0.7 -P3306 >create database work1 >use work1 >source work1.sql >create database work2 >use work2 >source work2.sql #也可以這樣 mysql -uroot -p'******' -h20.2.0.7 -P3306 -e "create database work1;use work1;source work1.sql;" mysql -uroot -p'******' -h20.2.0.7 -P3306 -e "create database work2;use work2;source work2.sql;"
導完之后,如果嚴謹一些,就看看數據表是不是全都導進去了,其他就等下一步開始配置了。
配置多源復制環境
以下操作,大部分都是在從庫執行的,主庫最多就是授權一下,如果已經做過了主從架構,一般這個也是早就授權過的了,直接拿來用就可以的了。
如果配過主從復制環境,應該知道舊模式是要確定pos位置,新模式則是要設置GTID的編號。至于怎么確定,直接more看一下就知道了。
#看以下sql的備份文件 more work1.sql . . . -- GTID state at the beginning of the backup -- SET @@GLOBAL.GTID_PURGED='3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758, 4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-38813008'; -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001284', MASTER_LOG_POS=3954096; . . .
這里不打算詳細解析,有興趣的可以看我另一篇關于搭建普通主從架構的文章,里面有詳細解析。現在這里可以看到gtid和pos值,后面我們拿來用就可以了。
然后,進入正題:
首先,我們要把從庫配置文件改一下,添加些東西。
#在從庫的my.cnf配置文件中添加配置項,需要重啟mysql實例 vim my.cnf [mysqld] master_info_repository=TABLE relay_log_info_repository=TABLE replicate_wild_do_table=work1.% replicate_wild_do_table=work2.% read-only #5.6以上參數,并行復制線程數 slave_parallel_workers = 4 #5.7新參數,并行復制模式選擇,5.6沒用 #slave_parallel_type = LOGICAL_CLOCK #當然也可以在線實現設置,目的就是把主從配置信息改為記錄到表 mysql>SET GLOBAL master_info_repository = 'TABLE'; mysql>SET GLOBAL relay_log_info_repository = 'TABLE'; mysql>change replication filter REPLICATE_IGNORE_DB=(mysql) ;
需要特別注意replicate_wild_do_table這個參數,這個參數的意思是只執行某個庫或某個表的同步語句,其他庫和表都不處理,從而達到選擇性復制業務庫的目的,這就不會有無用的數據了,也不會互相干擾。官方文檔解析只能一個參數標記一個庫,而且這個參數是全局通用,也就是說多源復制下,所有源頻道都通用這個配置。
開啟只讀read-only就不用多說了,多源復制一般就只有讀的需求,就不要讓他們有寫庫的可能了。
并發復制多線程slave_parallel_workers是5.6,5.7新出的功能,能有效加快復制的效率,特別5.7是支持事務并發復制的,速度相當可觀,這里設置了每個復制連接有4個并發線程。
而slave_parallel_type是選擇并發復制方式,默認是為了兼容5.6以庫模式的并發復制,這里是改成5.7新出的以組提交事務的方式并發復制,并發效果更佳,但是要特別注意如果主從服務器數據庫版本不一致的話,最好還是不要改,因為只有mysql5.7是默認開啟組提交功能的。
--------------------------------------------------------------------
然后,在主庫授權復制的賬號,已做過同類賬戶授權的可以忽略
#在主庫授權,已做過的可以忽略 mysql -uroot -p'******' -h20.2.0.5 -P3306 grant replication slave on *.* to 'rep'@'%' identified by '123123'; mysql -uroot -p'******' -h20.2.0.6 -P3306 grant replication slave on *.* to 'rep'@'%' identified by '123123';
---------------------------------------------------------------------
好了,開始正式配置多源復制,這個GTID模式其實比起傳統pos的模式更復雜一些,不過,未來都是用GTID多的了,所以我就拿GTID模式來做演示為主。
#登錄進從庫數據庫 mysql -uroot -p'******' -h20.2.0.7 -P3306 #先清空所有主從結構的記錄 reset slave all; #配置阿里云的數據庫,這是GTID模式 change master to master_host='10.2.0.5', master_user='rep', master_password='123123', master_port=3306, MASTER_AUTO_POSITION = 1 FOR CHANNEL 'al_RDS'; #配置自建的數據庫,這是GTID模式 change master to master_host='10.2.0.6', master_user='rep', master_password='123123', master_port=3306, MASTER_AUTO_POSITION = 1 FOR CHANNEL 'me_mysql'; #重置GTID值 reset master; #設置GTID值 SET @@GLOBAL.GTID_PURGED='09cb91bf-2669-11e7-8b70-00163e0835ff:1-486646,3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758, 4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-38813008';
需要特別注意的兩點是,多源復制提供了channel的標識,區分了不同的源頻道,所以配置的時候就需要加上指定頻道名稱FOR CHANNEL 'al_RDS';這樣。而GTID的值和replicate_wild_do_table參數一樣,默認是全局的配置,讓源頻道各取所需,所以,我們的gtid值,應該是所有*.sql文件的gtid值的合集,用‘,’號分隔,最終就出現我這個要設置這么多GTID的情況。
然后都配置完成了,就可以啟動了,啟動和關閉都可以指定特定的源頻道,相當方便,下面列舉一下命令。
#啟動/關閉所有源頻道 start/stop slave; #啟動/關閉單一的源頻道 start/stop slave for channel 'al_RDS'; #當然重置也是可以單獨頻道的 #RESET SLAVE FOR CHANNEL 'al_RDS'; #查看狀態也是可以單獨的,不指定就是全部了 #show slave status for channel 'al_RDS';
然后,看看狀態,show slave status看看。
#在從庫上執行命令 mysql -uroot -p'******' -h20.2.0.7 -P3306 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.2.0.5 Master_User: rep Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.001297 Read_Master_Log_Pos: 5607291 Relay_Log_File: beifen1-relay-bin-al_rds.000030 Relay_Log_Pos: 5607464 Relay_Master_Log_File: mysql-bin.001297 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: work1.%,work2.% Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 5607291 Relay_Log_Space: 5607767 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: Replicate_Ignore_Server_Ids: Master_Server_Id: 2721321239 Master_UUID: 4cdc2a74-6299-11e6-95ce-008cfaf595bc Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 4cdc2a74-6299-11e6-95ce-008cfaf595bc:38888940-39258544 Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-640645, 1db4cb1b-5e00-11e7-89eb-00163e046b4a:1-8, 3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758, 4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-39258544 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: al_rds Master_TLS_Version: *************************** 2. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.2.0.6 Master_User: rep Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000013 Read_Master_Log_Pos: 246854093 Relay_Log_File: beifen1-relay-bin-me_mysql.000004 Relay_Log_Pos: 155502415 Relay_Master_Log_File: mysql-bin.000013 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: work1.%,work2.% Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 246854093 Relay_Log_Space: 155502632 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: Replicate_Ignore_Server_Ids: Master_Server_Id: 253241 Master_UUID: 817498dc-2676-11e7-a673-00163e024674 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:514003-640645 Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-640645, 1db4cb1b-5e00-11e7-89eb-00163e046b4a:1-8, 3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758, 4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-39258544 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: me_mysql Master_TLS_Version: 2 rows in set (0.00 sec)
很長,我們看到有兩條記錄,其中Replicate_Wild_Do_Table,Executed_Gtid_Set是全局通用,兩邊都有,印證了我說的參數是全局的。然后各自的Retrieved_Gtid_Set是不同的,他們都自行選擇了,相當智能。再看到Channel_Name就是他們不同的頻道名字了。然后可以看到,Slave_IO_Running和Slave_SQL_Running的雙yes,Master_Log_File=Relay_Master_Log_File,Read_Master_Log_Pos=Exec_Master_Log_Pos,Seconds_Behind_Master為0,所以現在是同步的。
--------------------------------------------------------------------------
如果是傳統的模式,反而更簡單,不用設置GTID的值,類似下面這樣指定log文件名和pos即可,不用設置SET @@GLOBAL.GTID_PURGED就可以啟動。
#設置頻道一 change master to master_host='10.2.0.5', master_user='rep', master_password='123123', master_port=3306, MASTER_LOG_FILE='mysql-bin.001284', MASTER_LOG_POS=3954096 FOR CHANNEL 'al_RDS'; #設置頻道二 change master to master_host='10.2.0.6', master_user='rep', master_password='123123', master_port=3306, MASTER_LOG_FILE='mysql-bin.000014', MASTER_LOG_POS=67456 FOR CHANNEL 'me_mysql'; #啟動 start slave;
--------------------------------------------------------------------------
問題匯總
1.在停止多元復制環境時要注意并行復制的進度,例如出現下面這種情況,就先等一等再停止。
#請關注Executed_Gtid_Set:項 show slave status\G . . . Master_Server_Id: 2721321239 Master_UUID: 4cdc2a74-6299-11e6-95ce-008cfaf595bc Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Reading event from the relay log Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 4cdc2a74-6299-11e6-95ce-008cfaf595bc:50007036-50049107 Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-47551250, 3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758, 4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-50010063:50010080-50010093:50010099-50010101:50010108:50010130-50010139:50010145-50010148:50010158:50010179-50010184:50010190-50010200:50010207:50010215-50010221:50010227-50010236:50010243:50010276-50010285:50010291-50010293:50010300:50010308-50010312:50010326-50010328:50010371-50010373:50010391-50010393:50010403-50010405:50010427-50010429:50010464-50010466:50010480-50010482:50010490-50010496:50010518-50010520:50010538-50010540:50010551-50010553:50010574 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: al_rds Master_TLS_Version: *************************** 2. row *************************** Slave_IO_State: Waiting for master to send event . . .
那是因為你這么一停止,并行復制就中途停止了,就有可能出現有些數據回滾不了,或者有些數據復制錯誤,然后后續你還想把他起來就很大可能會報錯了,所以寧愿先等一等,再停止。
當然了,如果是線上環境,究竟要等到什么時候?所以最好就是數據庫不繁忙的時候再做。要么,你就是準備好重做的心態了,那就來吧。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。