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拉取binlog的賬戶，它比常規的slave 賬戶多了一個select權限。

先把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提示。這里不是重點。