MySQL鏈式複製加速神器: MaxScale Binlog Server
講師介紹
賀春暘
惠普金融MySQL專家
《MySQL管理之道》第一版、第二版作者，曾任職於中國移動飛信、機鋒安卓市場，擁有豐富的資料庫管理經驗。
目前致力於MySQL、Linux等開源技術的研究。
感謝大家參與我今天的分享，希望今天大家能有所收穫，並能把這項新技術玩起來先。在介紹MaxScaleBinlogServer前，我先把我們這邊的情況大致闡述下。
公司核心資料庫在我15年7月入職第二週，從最原始的MySQL5.5.30社群版全部升級到MariaDB10.0.21企業版，隨後面的機房遷移，版本再次升級為MariaDB10.0.26企業版。
那為啥選用這個版本？對於金融p2p公司來說，換資料庫就意味著風險，因為庫裡都是錢，大多都採用保守的方法。而我之前來機鋒網(安卓市場)的時候，就已經使用MariaDB10.0.17社群版跑了一年半，當時PV是2000萬，資料庫總共8臺，一主7從，前端PHP做的讀寫分離，後端用HaProxy做DB的負載均衡，QPS每秒在15000–20000左右，TPS每秒在300–500左右，至今資料庫穩定的跑著，未出現一次故障。
有了成功經驗，對我換金融資料庫版本就有了足夠的信心保障，因為金融類的公司併發都遠遠低於傳統網際網路公司，事實證明，目前業務穩定跑了1年4個月。
業務場景
好，再回過頭來說下，對接大資料分析部門遇到的痛點以及我們為何上了MaxScalebinlogserver。我們給大資料那邊，是提供一臺單獨的從庫，注意是二級從庫，他們通過阿里巴巴開源的canal連線到Slave從庫上，然後Slave推送binlog給canal，接收完binlog再推送給kafka訊息佇列，最終存入HBase裡，業務部門通過Hive直接寫SQL的方式來實現業務的實時分析，大體的架構就是這樣。
注意剛才我提到的二級從庫，因我們目前線上的從庫一臺是Standby僅提供故障切換用的，另一臺是提供業務讀寫分離用的。所以我在從庫的下面接了一臺二級從庫，提供對接canal使用。因爬蟲的抓取insert寫入量大，從庫的SQL_THREAD執行緒只有commit後才會記本地的binlog裡，然後再推送給二級從庫。這個時候，由於我們是實時分析，延遲5秒也無法接受，被業務方噴了回來，這TMD就尷尬了。
下面進入正題，本次分享將圍繞以下三部分展開：
- MariaDBMaxScale的工作原理
- MaxScaleBinlog伺服器主要功能
- 如何將MaxScale設定為Binlog伺服器
MariaDBMaxScale的工作原理
生產環境中，大多采用的是一主多從架構，即主庫推送三份binlog日誌到S1/S2/S3從庫上。然而，在這個架構中存在了一些問題，當主庫帶了過多的從庫，勢必會增加主庫的網路IO壓力。而鏈式複製（多級複製）通常為M—S1—S2/S3，S1是S2/S3的主，主庫只需要給S1推送binlog日誌即可，S1再推送binlog日誌給S2/S3，在這種場景下，緩解了主庫的網路IO壓力，但其缺點是：S2/S3得到最新的資料，需要再經過一層的複製才到達，期間的延遲比一主多從架構要大。
業界通常的做法是在二級主庫上（S1）選擇黑洞引擎（BLACKHOLE）降低鏈式複製（多級複製）的延遲問題。寫入BLACKHOLE表的資料並不會記錄到磁碟上（本身不儲存資料），永遠為一個空表，因不會將同步的資料寫回到磁碟上，速度遠遠比INNODB引擎快，它僅僅接收主庫推送過來的binlog日誌。
MaxScale對Binlog的收集採用了一個更簡單的方法，其工作在主庫和從庫之間。它不會對binlog進行任何回放操作，自身不儲存資料。它把從主庫接收的binlog放入本地快取，並將其推送給從庫。這意味著從庫總是獲得最新的binlog事件，它們與主庫寫入的binlog事件具有一對一的關係。其延遲主要是新增多臺MaxScale帶來的額外的網路傳輸。
充當主庫代理的MaxScale具有與主庫完全相同的binlog事件，這意味著從庫可以在任意一個MaxScale節點之間CHANGEMSATERTO，無需執行任何特殊處理。MariaDBMaxScaleBinlogServer接收器，工作流程類似黑洞引擎（BLACKHOLE）。
MaxScaleBinlog伺服器主要功能
Binlog伺服器從主庫請求和接收Binlog事件。
接收的二進位制日誌與主庫裡的二進位制日誌完全相同，可以理解為MaxScaleBinlog每秒rsync主庫的binlog事件。
從庫可以與MaxScaleBinlog做CHANGEMSATERTO同步複製，從而不會對主庫網路IO造成過大影響。
如何將MaxScale設定為Binlog伺服器
使用MaxScale作為binlog代理與使用MaxScale作為應用讀寫分離的代理非常相似。
基礎架構為：M—MaxScaleBinlog—S1/S2：
一個主庫
兩個或更多的從庫
一個或兩個MaxScale伺服器配置了binlog接收器
MaxScale binlog配置
# cat /etc/maxscale.cnf
[maxscale]
threads=24
##根據CPU核數設定
[Replication]
type=service
router=binlogrouter
user=repl
passwd=repl
# 使用主庫上的repl複製賬號
# 許可權：
# GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY ‘repl’;
router_options=server_id=1311,heartbeat=30,binlogdir=/data/binlog,transaction_safety=1,mariadb10-compatibility=1,send_slave_heartbeat=1
# server_id設定maxscale的，記得不能與主和從庫重複，要唯一
# heartbeat=30秒，意思為當maxscale在30秒內沒有接收到主庫推送的binlog日誌，傳送心跳檢查
# binlogdir設定接收binlog的存放路徑，目錄屬性chown -R
maxscale.maxscale /data/binlog
# transaction_safety=1此引數用於啟用binlog日誌中的不完整事務檢測。 當MariaDB MaxScale啟動時，如果當前binlog檔案已損壞或找到不完整的事務，則可能會出現錯誤訊息。 在正常工作期間，binlog事件不會分配到從庫，直到事務已經提交。 預設值為off，設定transaction_safety = on以啟用不完全事務檢測。
# send_slave_heartbeat=1開啟心跳檢查
[Replication Listener]
type=listener
service=Replication
protocol=MySQLClient
port=5308
# 後端的從庫CHANGE MASTER TO這個埠，預設5308
[CLI]
type=service
router=cli
[CLI Listener]
type=listener
service=CLI
protocol=maxscaled
port=6603
# MaxScale後臺管理埠
啟動：
# /etc/init.d/maxscale start
使用：
# 連線到MaxScale binlog Server後臺
# mysql -h192.168.17.131 -urepl -prepl -P5308
# 就像平常建立主從複製一樣，執行下面的命令
MySQL [(none)]> CHANGE MASTER TO
MASTER_HOST=’192.168.17.128′,MASTER_USER=’repl’,MASTER_PASSWORD=’repl’,MASTER_PORT=3306,MASTER_LOG_FILE=’mysql-bin.000012′,MASTER_LOG_POS=4;
MySQL [(none)]> start slave;
Query OK, 0 rows affected (0.03 sec)
# 注：這裡MASTER_LOG_POS必須指定4，否則報錯。
# 此外，GTID目前不支援
MySQL [(none)]> set global gtid_slave_pos = ‘0-17128-37′;
ERROR 1064 (42000): You have an error in your SQL syntax; Check the syntax the MaxScale binlog router accepts.
MySQL [(none)]>
MySQL [(none)]> CHANGE MASTER TO
MASTER_HOST=’192.168.17.128′,MASTER_USER=’repl’, MASTER_PASSWORD=’repl’,MASTER_PORT=3306,master_use_gtid =’slave_pos’;
ERROR 1234 (42000): option ‘master_use_gtid’ is not supported
MySQL [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.17.128
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000012
Read_Master_Log_Pos: 365
Relay_Log_File: mysql-bin.000012
Relay_Log_Pos: 365
Relay_Master_Log_File: mysql-bin.000012
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: 365
Relay_Log_Space: 365
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: 17128
Master_UUID: ca8da868-a63f-11e6-a6d7-000c29379e1f
Master_Info_File: /data/binlog/master.ini
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave running
Master_Retry_Count: 1000
Master_Bind:
Last_IO_Error_TimeStamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position:
1 row in set (0.00 sec)
# 如果你配置有誤，清空同步資訊即可，執行下面命令
MySQL [(none)]> stop slave;
Query OK, 0 rows affected (0.00 sec)
MySQL [(none)]> reset slave all;
Query OK, 0 rows affected (0.00 sec)
# 這一步成功之後，你會在/data/binlog目錄下發現接收過來的binlog日誌，如下圖所示。
# 登入到MaxScale管理後臺，可以看到接收binlog的資訊，如下圖所示。
# maxadmin -uadmin -pmariadb -P6603
# 線上搭建一個從庫與MaxScale Binlog Server同步複製步驟：
- 主庫上匯出mysqldump –single-transaction -q -p123456 –master-data=2 -A > all.sql
- 從庫上匯入
- more all.sql檢視同步複製的點
- CHANGE MASTER TO MaxScale Binlog Server（埠5308）
參考文獻：
https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-as-a-binlog-server/
視訊下載：
為了幫助大家理解，已將演示視訊上傳至社群百度網盤，http://pan.baidu.com/s/1eSC5GCa
Q1：“# 注：這裡MASTER_LOG_POS必須指定4 ” 如果執行很久的庫，我搭建一個maxscale binlog server 也要指定 MASTER_LOG_POS=4 ？
A1：是的，必須指定為4，從頭開始接收，這樣是保證binlog日誌的完整性。
Q2：賀老師，我有一個執行一段時間的一主N從的架構，我能中間加一個這個binlog server 後，把其他 從庫重新指定到這個binlog server 麼，有什麼需要注意的麼？
A2：可以，這個沒問題。
Q3：另外如果主庫的MASTER_LOG_POS=4 的binlog 已經刪除了, 上面也那個指定也是需要指定4不會有問題嗎？
A3：binlog server的binlog就是主庫上rsync過來的，完全一致。指定的時候，是從4開始的，binlog檔案都是從4開始，例如mysql-bin.00001,00002,都是從4開始。
Q4：我有一個執行一段時間的一主N從的架構，架構中加入binlog server 如何解決單點？
A4：binlog server可以部署兩臺，就是同時拉取兩份主庫的binlog。
Q5：[maxscale]
threads=24
##根據CPU核數設定
這裡能不按CPU核數設定嗎？
A5：這個可以，但效能會下降。
Q6：一主多從的架構，中間部署binlog server，在伺服器壓力大時如何降低或確保slave端的延遲？
A6：我們目前生產是開啟了MariaDB的並行複製功能，32核CPU，開啟了32個執行緒。另外可以通過增加記憶體，調整INNODB_BUFFER_POOL_SIZE解決延遲的問題。另外一點是注意避免主庫的大事務，比如更新一個表，總共100萬，讓開發通過程式，迴圈更新，每1000條一個事務，直到全部更新完畢。
Q7：賀老師，能給DBA的職業發展給點建議？
A7：不敢當，一個老DBA前輩告訴我的，要多寫部落格，多做分享。
（承接上一問）
Q8：對準備轉行進入資料庫的給點建議或者注意事項？
A8：我覺得DBA這個行業，需要謹慎，就跟開車一樣，需要時間磨練。另外就是溝通，因為每天都要對接各種開發，給他們提建議。
Q9：新入行的，做運維，開發，實施，有什麼區別？
A9：運維開發側重點不同。
Q10：Oracle 和MySQL 哪個會更長久？
A10：這個我之前面試過20個DBA，有很多是從Oralce轉的。目前是MySQL要火一些。
Q11：NoSQL這類資料庫前景如何？
A11：是必須會的，Redis和MongoDB。
Q12：MySQL和MariaDB哪個好？MySQL學習中有哪些難點要特別注意的？
A12：這個各有優缺點吧，在生產上之所以選擇的mariadb，是看重他的功能更多，效能更好，穩定等因素。另外是從5.5升級到mariadb10.0，不需要進行匯出匯入了，只需解除安裝mysql，用mariadb啟動即可，很簡單。這對資料庫上T的來說，輕鬆不少。
難點就是經常會遇到坑，心理要能承受得住業務方的噴。最最重要的是，高可用得做起來。
Q13：MySQL一個表或資料庫中，大概多少記錄算是大資料呢(新手問)
A13：之前在電商那會，通常是建議開發2000萬行就開始做分表，否則大促的時候，效能非常差。
Q14：請問MariaDB和5.7以上的MySQL對比，優勢大麼？
A14：MySQL5.7對InnoDB這塊加強了不少，但最好是5.7.20以後再上。
Q15：賀老師，我想問一下關於MySQL漏洞打補丁之類的問題。
A15：這個升級的步驟是，先對從庫做版本升級，然後凌晨的時候用MHA做下切換，再對原先的主庫升級。之前在飛信的時候，經常安全部門找到我們，我就是這樣升級的小版本。
（承接上一問）
Q16：就是直接做資料庫版本升級？
A16：是的，用新版本啟動。
Q17：那資料匯入匯出一般您是採用哪種方式呢？
A17：推薦用mydumper，是多執行緒的，速度比單執行緒的mysqldump快。
Q18：mydumper是不是還不支援設定字符集？
A18：通常資料庫都是UTF8的，匯出的時候還真沒特意指定過。
Q19：MHA能支援一主一備，1+2感覺有點浪費。
A19：這必須的。目前最新版本是0.57，老版本0.56就已經支援。
文章出處：DBAplus社群（訂閱號ID：dbaplus）