slave庫的應用場景

一、slave庫的并行復制模式

slave_parallel_mode的 slave并行復制的5種模式：
官方給的5種模式

Description: Controls what transactions are applied in parallel when using parallel replication.
optimistic: tries to apply most transactional DML in parallel, and handles any conflicts with rollback and retry. See optimistic mode.
conservative: limits parallelism in an effort to avoid any conflicts. See conservative mode.
aggressive: tries to maximize the parallelism, possibly at the cost of increased conflict rate.
minimal: only parallelizes the commit steps of transactions.
none： disables parallel apply completely.

in-order 有序并行復制的optimistic樂觀模式為在slave上并行應用提供了很多機會，同時從應用程序的角度來看，仍然保留精確的事務語義。這是MariaDB 10.5.1中的默認模式

二、master_use_gtid 參數說明：

配置主從復制時， CHANGE MASTER TO master_use_gtid = { slave_pos | current_pos | no } 這3個參數介紹：

2.1、CHANGE MASTER TO master_use_gtid=slave_pos 介紹：

假如：
A slave is configured to use GTID by CHANGE MASTER TO master_use_gtid=slave_pos

當slave從站連接到master主站時，它將在復制到從站的最后一個GTID的位置開始復制，這可以在變量gtid_slave_pos中看到。由于所有復制服務器上的GTID均相同，因此可以將從屬服務器指向其他主服務器，并自動確定正確的位置。

如果不希望更改從屬服務器上的binlog會影響GTID復制位置，則應使用master_use_gtid = slave_pos。然后，從站將始終在最后復制的GTID位置連接到主站。
對于期望與傳統復制保持一致行為的用戶來說，這可以避免一些意外，因為復制位置永遠不會因服務器上進行的本地更改而改變

如果在從站上寫入任何本地事務，則在使用值current_pos時可能會遇到問題。例如，如果在slave從屬線程停止時發出INSERT語句或以其他方式寫入表，則可能在gtid_binlog_pos中生成新的本地GTID，這將影響從屬的gtid_current_pos值。重新啟動從屬線程時，這可能會導致錯誤，因為主控制器將不存在本地GTID。您可以通過將MASTER_USE_GTID復制參數設置為slave_pos而不是current_pos來糾正此問題。

重要提示：下面3種場景的演示環境： centos7.2_x86_64位    MariaDB.10.5.1 二進制安裝
mgr01  172.16.0.130  master
mgr03  172.16.0.131  slave

1.場景1：當線上的master庫運行了一段時間，而且數據庫的數據很少。針對此場景給master庫部署一個全新的slave庫

mgr03啟動后默認情況下GTID位點都是空的，尤其是gtid_slave_pos  這個是空的

(root@'mgr03':mysql.sock)[(none)]>show variables like 'Gtid%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| gtid_binlog_pos         |       |
| gtid_binlog_state       |       |
| gtid_cleanup_batch_size | 64    |
| gtid_current_pos        |       |
| gtid_domain_id          | 0     |
| gtid_ignore_duplicates  | OFF   |
| gtid_pos_auto_engines   |       |
| gtid_seq_no             | 0     |
| gtid_slave_pos          |       |
| gtid_strict_mode        | OFF   |
+-------------------------+-------+
10 rows in set (0.00 sec)

(root@'mgr03':mysql.sock)[(none)]>ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';
Query OK, 0 rows affected (0.02 sec)

(root@'mgr03':mysql.sock)[(none)]>show variables like 'Gtid%';
+-------------------------+-------------+
| Variable_name           | Value       |
+-------------------------+-------------+
| gtid_binlog_pos         | 0-1313306-1 |
| gtid_binlog_state       | 0-1313306-1 |
| gtid_cleanup_batch_size | 64          |
| gtid_current_pos        | 0-1313306-1 |
| gtid_domain_id          | 0           |
| gtid_ignore_duplicates  | OFF         |
| gtid_pos_auto_engines   |             |
| gtid_seq_no             | 0           |
| gtid_slave_pos          |             |
| gtid_strict_mode        | OFF         |
+-------------------------+-------------+
10 rows in set (0.01 sec)

master操作：

提示：reset master 這一步操作不是必須的，除非在這個庫之前，此數據庫做過別的集群的slave庫。尤其是在master庫上，嚴禁此操作，除非你清楚的知道自己在干什么

mysql -e "grant replication slave on *.* to repuser@'172.16.0.%' identified by 'JuwoSdk21TbUser'; flush privileges;"
mysqldump -uroot -p'123456' -B -A -F  --master-data=2 --single-transaction  --events|gzip >test.sql.gz
scp -rp -P52110 /opt/tes.sql.gz root@172.16.0.131:/root

slave操作：

(root@'mgr03':mysql.sock)[test]>source /root/test.sql
CHANGE MASTER TO MASTER_HOST='mgr01',MASTER_PORT=3306,MASTER_USER='repuser',MASTER_PASSWORD='JuwoSdk21TbUser',master_use_gtid=slave_pos;start slave;show slave status\G

2.場景2： 當線上的master庫運行了一段時間，而且數據庫的數據很少。針對此場景給master庫部署一個slave庫。但是這個新slave庫之前有做過其他的項目的主庫

那么初始位置需要手動設置為空：SET GLOBAL gtid_slave_pos = "";

mgr01-master :
當前gtid情況：

root@localhost [test]>show variables like 'Gtid%';
+-------------------------+--------------+
| Variable_name           | Value        |
+-------------------------+--------------+
| gtid_binlog_pos         | 0-1283306-50 |
| gtid_binlog_state       | 0-1283306-50 |
| gtid_cleanup_batch_size | 64           |
| gtid_current_pos        | 0-1283306-50 |
| gtid_domain_id          | 0            |
| gtid_ignore_duplicates  | OFF          |
| gtid_pos_auto_engines   |              |
| gtid_seq_no             | 0            |
| gtid_slave_pos          | 0-1313306-41 |
| gtid_strict_mode        | OFF          |
+-------------------------+--------------+
10 rows in set (0.001 sec)

mgr03-slave:
當前gtid情況：

(root@'mgr03':mysql.sock)[test]>show variables like 'Gtid%';
+-------------------------+---------------------------+
| Variable_name           | Value                     |
+-------------------------+---------------------------+
| gtid_binlog_pos         | 0-1313306-45              |
| gtid_binlog_state       | 0-1283306-42,0-1313306-45 |
| gtid_cleanup_batch_size | 64                        |
| gtid_current_pos        | 0-1313306-45              |
| gtid_domain_id          | 0                         |
| gtid_ignore_duplicates  | OFF                       |
| gtid_pos_auto_engines   |                           |
| gtid_seq_no             | 0                         |
| gtid_slave_pos          | 0-1283306-42              |
| gtid_strict_mode        | OFF                       |
+-------------------------+---------------------------+
10 rows in set (0.00 sec)

具體操作：

master操作：

mysql -e "grant replication slave on *.* to repuser@'172.16.0.%' identified by 'JuwoSdk21TbUser'; flush privileges;"

mysqldump -uroot -p'123456' -B -A -F  --master-data=2 --single-transaction  --events|gzip >test.sql.gz

scp -rp -P52110 /opt/test.sql.gz root@172.16.0.131:/root

slave操作：

(root@'mgr03':mysql.sock)[test]>source /root/test.sql

(root@'mgr03':mysql.sock)[test]>reset master ;
(root@'mgr03':mysql.sock)[test]>stop slave;
Query OK, 0 rows affected (0.12 sec)
(root@'mgr03':mysql.sock)[test]>reset slave all;
(root@'mgr03':mysql.sock)[test]>SET GLOBAL gtid_slave_pos = "";
Query OK, 0 rows affected (0.03 sec)

(root@'mgr03':mysql.sock)[test]>show variables like 'Gtid%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| gtid_binlog_pos         |       |
| gtid_binlog_state       |       |
| gtid_cleanup_batch_size | 64    |
| gtid_current_pos        |       |
| gtid_domain_id          | 0     |
| gtid_ignore_duplicates  | OFF   |
| gtid_pos_auto_engines   |       |
| gtid_seq_no             | 0     |
| gtid_slave_pos          |       |
| gtid_strict_mode        | OFF   |
+-------------------------+-------+
10 rows in set (0.00 sec)

(root@'mgr03':mysql.sock)[test]>CHANGE MASTER TO MASTER_HOST='mgr01',MASTER_PORT=3306,MASTER_USER='repuser',MASTER_PASSWORD='JuwoSdk21TbUser',master_use_gtid=slave_pos;start slave;show slave status\G

3.場景三：從mysqldump或者XtraBackup或者Mariabackup備份集設置

這兩種方式都可以在非阻塞的情況下獲得備份時正確的Binlog位點（所有表都要是事務引擎），當然，如果備份時不會有寫入，那么 SHOW MASTER STATUS 也能提供正確的位點。
一旦獲取了備份時正確的Binlog位點（文件名和偏移量），那么就可以用BINLOG_GTID_POS()函數來計算GTID:SELECT BINLOG_GTID_POS("mysql-bin.000011",342);

使用mysqldump +gtid 方式新建slave：

從MariaDB 10.0.13版本開始，mysqldump會自動完成這個工作，并且把GTID的寫在導出文件中，只要設置 –master-data 或 -dump-slave 的同時設置 --gtid 即可。

mgr01-master：

[root@mgr01 ~]# mysqldump -uroot -p'123456' -B -A -F  --master-data=1 --gtid  --single-transaction  --events >2.sql
[root@mgr01 ~]# 
[root@mgr01 ~]# grep  'CHANGE MASTER TO' 2.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000011', MASTER_LOG_POS=342;
CHANGE MASTER TO MASTER_USE_GTID=slave_pos;

(root@'mgr01':mysql.sock)[(none)]>SELECT BINLOG_GTID_POS("mysql-bin.000011",342);
+-----------------------------------------+
| BINLOG_GTID_POS("mysql-bin.000011",342) |
+-----------------------------------------+
| 0-1283306-68                            |
+-----------------------------------------+
1 row in set (0.009 sec)

[root@mgr01 ~]# scp -rp -P52110 2.sql root@'172.16.0.131':/root

slave庫操作：

(root@'mgr03':mysql.sock)[test]>source /root/2.sql
(root@'mgr03':mysql.sock)[test]>show variables like 'gtid_slave_pos';
+----------------+--------------+
| Variable_name  | Value        |
+----------------+--------------+
| gtid_slave_pos | 0-1283306-68 |
+----------------+--------------+
1 row in set (0.00 sec)

(root@'mgr03':mysql.sock)[test]>SET GLOBAL gtid_slave_pos = "0-1283306-68";   這一步可有可無
(root@'mgr03':mysql.sock)[test]>CHANGE MASTER TO MASTER_HOST='mgr01',MASTER_PORT=3306,MASTER_USER='repuser',MASTER_PASSWORD='JuwoSdk21TbUser',master_use_gtid=slave_pos;start slave;show slave status\G

使用當日Mariabackup的全備份來新建一個slave庫：

mgr01 master 庫上操作：

master主庫上創建備份用戶
root@localhost [(none)]>grant  reload,replication client,lock tables,process,super on *.* to mariabackup@'127.0.0.1' identified by 'mypassword';flush privileges;

 mariabackup --backup --target-dir=/data/backup/  --user=mariabackup --password=mypassword  --host=127.0.0.1
 mariabackup --prepare --target-dir=/data/backup/

cd /data/; tar zcf bak.tar.gz ./backup
scp -rp -P22 bak.tar.gz root@172.16.0.131:/root

[root@mgr01 data]# cat /data/backup/xtrabackup_binlog_info 
mysql-bin.000013    746 0-1283306-74

mgr03 slave庫上操作：

[root@mgr03 ~]# mariabackup  --defaults-file=/etc/my.cnf  --copy-back  --target-dir=/data/backup/
 chown -R mysql.mysql  /data/mysql/mysql3306/data
 /etc/init.d/mysql start

 基于Gtid復制配置：
SET GLOBAL gtid_slave_pos = "0-1283306-74";
CHANGE MASTER TO MASTER_HOST='mgr01',MASTER_PORT=3306,MASTER_USER='repuser',MASTER_PASSWORD='JuwoSdk21TbUser',master_use_gtid=slave_pos;start slave;show slave status\G

基于File and Position復制配置:

CHANGE MASTER TO 
   MASTER_HOST='mgr01', 
   MASTER_PORT=3306, 
   MASTER_USER="repuser",  
   MASTER_PASSWORD="JuwoSdk21TbUser", 
   MASTER_LOG_FILE='mysql-bin.000013',
   MASTER_LOG_POS=746;
START SLAVE;

從一個線上的slave庫進行 mariabackup備份數據庫，然后利用這個備份做當前master庫的slave庫：
基于Gtid復制配置：
master庫操作：

mariabackup --backup --slave-info --safe-slave-backup --target-dir=/data/backup/  --user=mariabackup --password=mypassword
 mariabackup --prepare --target-dir=/data/backup/
 cd /data/; tar zcf bak.tar.gz ./backup
scp -rp -P22 bak.tar.gz root@172.16.0.131:/root
[root@mgr01 data]# cat /data/backup/xtrabackup_binlog_info 
mysql-bin.000013    746 0-1283306-74

slave庫操作：

SET GLOBAL gtid_slave_pos = "0-1283306-74";
CHANGE MASTER TO MASTER_HOST='mgr01',MASTER_PORT=3306,MASTER_USER='repuser',MASTER_PASSWORD='JuwoSdk21TbUser',master_use_gtid=slave_pos;start slave;show slave status\G

2.2、CHANGE MASTER TO master_use_gtid=curren_pos 介紹：

假設我們設置了兩個服務器A和B，讓A作為master主服務器，而B作為slave從服務器。它運行了一段時間。然后在某個時候，masterA掛掉了，而slaveB成為了新的master。
然后，稍后我們想添加源masterA作為備庫，也就是作為新的master 的slave庫。
因為A之前從來不是slave庫，它沒有任何先前復制的GTID，并且gtid_slave_pos是空的，
為了允許A自動添加為slave庫，可以使用master_use_gtid = current_pos，這將使用變量gtid_current_pos的值而不是gtid_slave_pos進行連接，gtid_current_pos該變量還考慮了當服務器作為主服務器時寫入二進制日志中的GTID。
使用master_use_gtid = current_pos時，在使用CHANGE MASTER之前無需考慮服務器是master還是slave.
但是必須注意不要將多余的事務注入到slave 上的binlog中，這些事務不打算復制到其他服務器。
如果這樣的額外事務是slave服務器啟動時最新的事務，它將用作復制的起點。這可能會失敗，因為該事務不在master主服務器上。為了避免slave從屬服務器上的本地事務更改進入binlog，請將slave上的sql_log_bin設置為0。

啟用GTID嚴格模式（通過將@@ GLOBAL.gtid_strict_mode設置為1）時，通常最好使用current_pos。在嚴格模式下，不允許在主服務器上進行額外的事務
提示：
不應以任何其他方式修改mysql.gtid_slave_pos表。特別是，請勿嘗試更新表中的行以更改從站對當前GTID位置的想法