一、為什麼要做Galera集群非同步複製 Galera集群解決了資料庫高可用的問題，但是存在局限性，例如耗時的事務處理可能會導致集群性能急劇下降，甚至出現阻塞現象。而不幸的是，類似報表等業務需求就需要做數據大批量的數據查詢操作，為了不影響Galera的集群效率，需要做數據非同步複製，產生一個從庫來適配耗 ...
一、為什麼要做Galera集群非同步複製
Galera集群解決了資料庫高可用的問題，但是存在局限性，例如耗時的事務處理可能會導致集群性能急劇下降，甚至出現阻塞現象。而不幸的是，類似報表等業務需求就需要做數據大批量的數據查詢操作，為了不影響Galera的集群效率，需要做數據非同步複製，產生一個從庫來適配耗時的數據操作需求。
由於Galera集群的特殊性，我們不能使用一般的主從複製來實現數據非同步複製的要求。集群中每台mariadb都會單獨的記錄binlog，使得一般的主從配置只能獲取到單台數據的變更事件，集群中的其它mariadb上如果有數據變更，無法同步到從庫中。
根據GTID進行主從複製解決了這個問題，每個事務都存在唯一的ID，根據事務ID來同步不會受到資料庫的限制，因為集群中的所有資料庫節點使用的都是唯一的GTID。
二、安裝xtrabackup
1、YUM安裝，下載percona源：
yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm
2、開始安裝
yum install percona-xtrabackup-24
三、備份數據
1、在主庫上全量備份數據：
innobackupex --user=dbuser --passwor='dbpassword' /dir_for_backup
註意password參數，如果密碼中有關鍵字元，需要使用單引號把密碼引起來，否則無法登錄mysql，無法備份數據。
2、在主庫上進行全量備份後，需要應用事務到備份文件中才能使備份文件完整可用
Innobackupex --user=dbuser --password=’dbpassword’--apply-log /dir_for_backup /2018-07-12_10-39-56/
3、在主庫上把備份好的數據文件傳輸到從庫中
scp -r /DIR_FOR_BACKUP /2018-07-12_10-39-56/ slave_user@slave_server_ip:/slave_server_data_dir
四、從庫啟動
1、 在從庫上修改數據文件名稱，擁有者
mv /slave_server_data_dir/2018-07-12_10-39-56/ /slave_server_data_dir/mysqldata
chown -R mysql:mysql /slave_server_data_dir/mysqldata/
2、 在從庫上啟動資料庫
配置好my.conf文件，指定datadir目錄到/slave_server_data_dir/mysqldata，然後啟動資料庫。
五、主從配置
1、 Galera集群中的所有節點都需要做以下配置：
[mysqld]
master-info-repository=TABLE
relay-log-info-repository=TABLE
log_slave_updates = 1
sync-master-info=1
slave-parallel-threads=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
log-bin=mysql-bin
binlog_format=row
log_slave_updates = 1
server-id=4567
配置完成後重啟伺服器。
進入主庫（Galera集群中的任一節點），授權主從複製用戶：
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slaveUser'@'10.30.254.9' IDENTIFIED BY 'slaveUser';
2、 從庫配置
[mysqld]
master-info-repository=TABLE
relay-log-info-repository=TABLE
log_slave_updates = 1
sync-master-info=1
slave-parallel-threads=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
#這是與主庫配置不同的地方
relay_log = relay-bin
server_id=7890
log_bin=binlog
log_slave_updates=1
binlog_format=ROW
配置完成後重啟從庫資料庫。
3、 設置從庫GTID複製點信息
l 查看xtrabackup備份數據中的GTID信息
cat /slave_server_data_dir/mysqldata xtrabackup_info
uuid = ffa57fe6-8676-11e8-8b3a-00163e08d213
name =
tool_name = innobackupex
tool_command = --user=root --password=... /mnt
tool_version = 2.4.11
ibbackup_version = 2.4.11
server_version = 10.2.6-MariaDB-log
start_time = 2018-07-13 16:26:09
end_time = 2018-07-13 16:30:28
lock_time = 0
binlog_pos = filename 'mysql-bin.000019', position '82930255', GTID of the last change '0-4567-3446'
innodb_from_lsn = 0
innodb_to_lsn = 42353602070
partial = N
incremental = N
format = file
compact = N
compressed = N
encrypted = N
l 配置GTID主從複製
停止主從複製：STOP SLAVE;
重置主從配置：RESET SLAVE ALL;
設置GTID點：SET GLOBAL gtid_slave_pos='0-4567-3446';
配置主從配置：
CHANGE MASTER TO MASTER_HOST='10.30.253.222', MASTER_PORT=3306, MASTER_USER='slaveUser', MASTER_PASSWORD='slaveUser', master_use_gtid=slave_pos;
查看主從配置狀態：SHOW SLAVE STATUS;
六、GTID同步出錯時，如何恢復主從複製
異常信息：
Last_SQL_Error: Error 'Duplicate entry '4' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'insert into t VALUES(NULL,'salazar')'
Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5
Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-4
因為是GTID複製，所以set global sql_slave_skip_counter=N在這裡是沒有作用的，但是可以通過插入一個空的事務來解決問題：
STOP SLAVE;
SET GTID_NEXT="7d72f9b4-8577-11e2-a3d7-080027635ef5:5";
BEGIN; COMMIT;
SET GTID_NEXT="AUTOMATIC";
START SLAVE;
[...]
Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5
Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5
