MaxScale binlog server的搭建
官方手冊：
https://mariadb.com/resources/blog/binlog-server
參考文章：
http://www.linuxidc.com/Linux/2016-12/137892.htm
http://www.sohu.com/a/120438391_487514
缺點：目前binlog server還不支持GTID的復制。
實驗拓撲圖：
步驟1：
Node1上創建復制權限的賬戶：
> grant replication client,replication slave,select on *.* to ‘rpl‘@"192.168.2.%" identified by ‘rpl‘;
# 這是給從庫復制用的賬號，同時也是maxscale
先把Node2掛到node1下，模擬沒有binlog server之前的架構：
過程無非就是導出node1的全量數據，在node2上恢復並change master 到node1，具體步驟略過。
Node3 上安裝maxscale：
rpm -ivh maxscale-2.1.4-1.rhel.6.x86_64.rpm
mkdir /data/binlog/ -p
chown maxscale.maxscale /data/binlog/ -R
vim/etc/maxscale.conf 內容如下：
[maxscale]
threads=4 # 根據CPU核心數量來設置
## 連接到Master的信息
[Replication]
type=service
router=binlogrouter
version_string=5.6.36-log
# version_string 參數用於將主庫的版本信息傳遞到從庫，MaxScale sends server handshakepacket to clients
router_options=server-id=13,heartbeat=30,transaction_safety=1,rcompatibility=1,send_slave_heartbeat=1
binlogdir=/data/binlog # 這個目錄屬主屬組必須是maxscale
user=rpl
passwd=rpl
#說明：
#server-id 設置的是maxscale的id，不能與主庫或者從庫重名。
#heartbeat=30表示當maxscale在30秒內沒有接收到主庫推送的binlog日誌，發送心跳檢查
#transaction_safety=1 用於啟用binlog日誌中的不完整事務檢測。當MariaDBMaxScale啟動時，如果當前binlog文件已損壞或找到不完整的事務，則可能會出現錯誤消息。在正常工作期間，binlog事件不會分配到從庫，直到事務已經提交。默認值為off，設置transaction_safety= on以啟用不完全事務檢測。【類似relay_log_recovery = ON的作用】
#send_slave_heartbeat=1開啟心跳檢查
## 提供給slave連接的信息
[ReplicationListener]
type=listener
service=Replication
protocol=MySQLClient
port=5308
## maxscale後端管理端口
[MaxAdmin Service]
type=service
router=cli
[MaxAdmin Listener]
type=listener
service=MaxAdmin Service
protocol=maxscaled
socket=default
vim /data/binlog/master.ini 加上如下的內容：
[binlog_configuration]
master_host=192.168.2.11 # 主庫地址
master_port=3306 #主庫端口號
master_user=rpl #master的復制賬號
master_password=rpl # master的復制密碼
filestem=mysql # 表示拉過來的binlog文件以mysql.***這種命名方式。我的主庫也是mysql.*這種命名方式
添加這個master.ini文件，以便啟動maxscale後自動去拉取主庫的目前的全部binlog文件（即便後來主庫的binlog過期後被自動purge掉了，maxscale服務器上的binlog還會保存著的）
然後，在node3上開啟maxscale服務:
/etc/init.d/maxscale start
稍等片刻，node3會把主庫的全部binlog都拉過來。
日誌記錄在/var/log/maxscale/maxscale.log 裏面。
ss -lnt|grep 5308 端口起來的話。
mysql -urpl -prpl -h 127.0.0.1 -P 5308 即可登陸到maxscale控制臺，和mysql使用起來一樣。
現在我們把node4這個新的從庫加到node3的binlog server 下面：
首先，將node1的全備份數據導入到node4，
然後head -35 all.sql 全備份裏面找到類似：
CHANGE MASTER TOMASTER_LOG_FILE=‘mysql.000004‘, MASTER_LOG_POS=2254 這樣的記錄。
在node4上執行change master操作：
> CHANGE MASTER TO MASTER_HOST=‘192.168.2.13‘ ,
MASTER_PORT=5308,
MASTER_USER=‘rpl‘,
MASTER_PASSWORD=‘rpl‘,
MASTER_LOG_FILE=‘mysql.000004‘,
MASTER_LOG_POS=2254 ;
註意上面的change master操作中，我們只改了下master的地址和端口、復制用的用戶名、密碼。
因為binlog server實際上和master的數據是一樣的，它只直接把master的binlog拖過來的。
同樣的操作，我們可以把node2也掛到binlog server下面。
在node2上：
show slave status\G 記錄下Exec_Master_Log_Pos和Master_Log_File。
stop slave;
reset slave all;
然後使用change master將上級指向binlog server即可。
其他maxscale的命令：
在node3上，執行show slave hosts; 可以看到
還可以登陸maxscale控制臺：
maxadmin -S /tmp/maxadmin.sock
MaxScale> show services 等其他很多查看狀態的命令，可使用help提示。這裏不是重點。
本文出自 “菜雞” 博客，請務必保留此出處http://lee90.blog.51cto.com/10414478/1945438
MaxScale binlog server的搭建