1.3　配置異步復制

在本實驗中分別針對空庫、脫機、聯機三種場景，配置“一主兩從”的MySQL標準異步復制。只進行實例級別的全復制，不考慮對個別庫表或使用過濾復制的情況。

1.3.1　空庫

初始安裝后，MySQL中還沒有任何應用數據。此時事先配置好復制再投入使用，這是最理想也是最簡單的一種情況，具體配置步驟如下：

步驟01　修改server_id系統變量。

要求在復制中所有MySQL實例的server_id都不相同，這里將三個實例的server_id分別配置為1125、1126、1127。server_id系統變量可以動態修改，這樣做的好處是不需要重啟實例，配置即可在新連接中生效。但是為了避免MySQL重啟后配置信息丟失，還需要同時在/etc/my.cnf配置文件中設置server_id參數。

步驟02　查看主庫二進制日志信息。

     -- 主庫
     show master status;

因為是一個靜態的空庫，二進制信息此時不會發生變化，可以作為復制的起始點。本例中重啟過MySQL實例，輸出的信息為：

步驟03　在主庫上建立復制專屬用戶。

     -- 主庫
     create user 'repl'@'%' identified with mysql_native_password by '123456';
     grant replication client,replication slave on *.* to 'repl'@'%';

前面介紹過MySQL 8的用戶認證機制，這里仍然使用mysql_native_password方式。

步驟04　在從庫創建主庫信息。

連接主庫時，需要使用change master to提供到主庫的連接選項，包括主機地址、端口、用戶名、密碼、二進制文件名、復制起始事件位置等信息。執行change master to語句后，在mysql.slave_master_info表中就會生成一條記錄，此行為由master_info_repository系統變量控制。MySQL 8中，該變量的默認值為TABLE，即把與復制相關的主庫信息記錄到mysql.slave_master_info表中。隨著復制的進行，表中的數據會隨之更新。change master to只是為I/O線程連接主庫時提供連接參數，這條語句本身不會連接主庫。以后啟動I/O線程時，I/O線程都會自動讀取這條記錄連接主庫，不需要再執行change master to語句。

類似地，MySQL 8默認會將中繼日志的重放信息存到mysql.slave_relay_log_info表中。該行為由系統變量relay_log_info_repository控制。中繼日志信息在首次啟動復制時生成，并隨著復制過程即時改變，這樣SQL線程再次啟動時就能從中獲取到從中繼日志的何處繼續讀取和執行。

步驟05　在從庫啟動復制并查看復制信息。

     start slave;
     show slave status\G
     select * from mysql.user where user='repl'\G

剛才我們并沒有在從庫上創建repl用戶，由于create user語句是在起始位置后執行的，因此可以正常復制到從庫，查詢mysql.user表即可確認。

start slave語句會啟動I/O線程和SQL線程，并創建一個到主庫的普通客戶端連接，此連接會伴隨復制一直存在。該命令執行后，在主庫的processlist中會看到類似如下的線程，它們是從庫上的I/O線程所建立的，Binlog Dump表示由I/O線程在主庫上啟動了Binlog Dump線程，每個連接到主庫的從庫對應一個線程，如Id 32和56是兩個從庫的連接線程：

從庫上的processlist中會看到類似如下的線程，Id 325和326分別對應I/O線程與SQL線程：

從show slave status輸出中可以查看復制的狀態信息：

在從庫上執行show slave status可以查看從庫的狀態，輸出的信息非常多，其中除了那些描述I/O線程、SQL線程狀態的行，還有幾個log_file和pos相關的行。理解這幾行的意義至關重要，所以這里完整地描述它們：

• Master_Log_File：I/O線程正在讀取的master binlog。
• Read_Master_Log_Pos：I/O線程已經讀取到master binlog的哪個位置。
• Relay_Log_File：SQL線程正在讀取和執行的relay log。
• Relay_Log_Pos：SQL線程已經讀取和執行到relay log的哪個位置。
• Relay_Master_Log_File：SQL線程最近執行的操作對應的是哪個master binlog。
• Exec_Master_Log_Pos：SQL線程最近執行的操作對應的是master binlog的哪個位置。

(Relay_Master_Log_File, Exec_Master_log_Pos)構成一個坐標，這個坐標表示從庫上已經將主庫上的哪些數據重放到自己的實例中，它可以用于下一次執行change master to語句時指定的二進制日志坐標。與這個坐標相對應的是從庫上SQL線程的中繼日志坐標(Relay_Log_File,Relay_Log_Pos)。這兩個坐標位置不同，但它們對應的數據是一致的。

還有一個延遲參數Seconds_Behind_Master需要說明一下，它的含義是SQL線程比I/O線程慢多少。如果主從之間的網絡狀況優良，那么從庫的I/O線程讀速度二進制日志和主庫寫二進制日志的速度基本一致，所以這個參數也用來描述“SQL線程比主庫慢多少”，也就是說從庫比主庫少多少數據，只不過衡量的單位是秒。需要注意的是，該參數的描述并不標準，只是在網速很好的時候做個大概的估計，很多情況下它的值都是0，即使SQL線程比I/O線程慢了很多也是如此。

1.3.2　脫機

如果數據庫已經存在應用數據，允許在一個可接受的脫機時間窗口進行復制，那么這種場景下常用的做法是先直接將主庫的數據目錄整體復制到從庫，再啟動從庫復制操作，具體步驟如下：

步驟01　在主庫上建立復制專屬用戶：

     -- 主庫
     create user 'repl'@'%' identified with mysql_native_password by '123456';
     grant replication client,replication slave on *.* to 'repl'@'%';

步驟02　停掉復制涉及的實例（“一主兩從”三個實例都停止）：

     mysqladmin -uroot -p123456 shutdown

步驟03　將主庫的數據目錄整體復制到從庫：

     scp -r /usr/local/mysql/data/ 172.16.1.126:/usr/local/mysql

步驟04　保證所有參與復制實例的server-uuid和server_id都不同。

這是非常重要的一步，相同的server-uuid或server_id會造成復制錯誤。從MySQL 5.6開始，用128位的server_uuid代替了原本的32位server_id的大部分功能。原因很簡單，server_id依賴于my.cnf的手工配置，有可能發生沖突。而自動產生128位uuid的算法可以保證所有的MySQL uuid都不會發生沖突。首次啟動時MySQL會調用generate_server_uuid()自動生成一個server_uuid，并且保存到數據目錄下的auto.cnf文件中。這個文件目前存在的唯一目的就是保存server_uuid。在MySQL再次啟動時會讀取auto.cnf文件，繼續使用上次生成的server_uuid。使用show global variables like 'server_uuid'命令可以查看MySQL實例當前使用的server_uuid，它是一個全局只讀變量。全局唯一server_uuid的一個好處是，可以解決由server_id配置沖突導致的MySQL主從復制異常終止。從庫向主庫申請二進制日志時，會首先發送自己的server_uuid，主庫用從庫發送的server_uuid代替server_id作為kill_zombie_dump_threads的參數，以終止沖突或者僵死的BINLOG_DUMP線程。

刪除data_dir/auto.cnf文件，實例啟動時會自動生成server_uuid的值。本例中刪除了從庫的/usr/local/mysql/data/auto.cnf文件，并編輯/etc/my.cnf文件以修改server_id，保證三個實例的配置互不相同。

步驟01　重啟實例（“一主兩從”三個實例都啟動）：

     mysqld_safe --user=mysql &

步驟02　查看主庫二進制日志信息：

     -- 主庫
     show master status;

步驟03　使用上一步的輸出在從庫創建主庫信息：

步驟04　在從庫啟動復制并查看復制信息：

     start slave;
     show slave status\G

此時在從庫的err日志文件中可以看到復制正常啟動的信息：

1.3.3　聯機

脫機建立復制的需求太過理想化，大多數情況下，復制被要求在不影響線上業務的情況下聯機創建，而且還要求對線上庫的影響越小越好。例如，在復制過程中主庫加鎖會影響對主庫的訪問，因此通常不允許對主庫加鎖。這種場景下有兩種備選的復制方案：使用mysqldump程序或使用如XtraBackup的第三方工具。這兩種方案都有各自的適用場合。使用mysqldump聯機建立復制的過程如下：

步驟01　在主庫上建立復制專屬用戶：

     -- 主庫
     create user 'repl'@'%' identified with mysql_native_password by '123456';
     grant replication client,replication slave on *.* to 'repl'@'%';

步驟02　在從庫上創建主庫信息：

注意在上面這條命令中并沒有指定主庫二進制日志的文件名和位置。

步驟03　在從庫用mysqldump建立復制：

     mysqldump --single-transaction --all-databases --master-data=1 --host=
     172.16.1.125 --default-character-set=utf8mb4 --user=wxy --password=123456
     --apply-slave-statements | mysql -uroot -p123456 -h127.0.0.1

說明：

• --single-transaction參數可以對InnoDB表執行非鎖定導出。此選項將事務隔離模式設置為REPEATABLE READ，并在轉儲數據之前向服務器發送START TRANSACTION SQL語句。它僅適用于InnoDB等事務表，因為它會在發出START TRANSACTION時轉儲數據庫的一致狀態，而不會阻塞任何應用程序。因此這里假定：①所有的應用數據表都使用InnoDB引擎；②所有非InnoDB表數據在備份過程中不會發生變化。
• --master-data參數會導致轉儲輸出包含類似CHANGE MASTER TO MASTER_LOG_FILE='binlog.000004', MASTER_LOG_POS=1480;的SQL語句，該語句指示主庫的二進制日志坐標（文件名和偏移量）。如果選項值為2，則CHANGE MASTER TO語句將寫為SQL注釋，因此僅提供信息，不會執行。如果參數值為1，則該語句不會寫為注釋，并在重新加載轉儲文件時執行。如果未指定選項值，則默認值為1。
• --apply-slave-statements參數會在CHANGE MASTER TO語句之前添加STOP SLAVE語句，并在輸出結尾處添加START SLAVE語句，用來自動開啟復制。
• --default-character-set參數指定默認字符集，MySQL 8默認的字符集為utf8mb4。
• 通過管道操作符，導出和導入一步進行，不需要中間落盤生成文件。

步驟04　確認復制狀態：

     -- 從庫
     show slave status\G

mysqldump方式的優點是可以進行部分復制，如在配置文件中定義replicate-do-table=db1.*，則用這種方法可以只復制db1庫而忽略其他復制事件。缺點是由于mysqldump會生成主庫轉儲數據的SQL語句，實際是一種邏輯備份方式，所以速度較慢，不適用于大庫。

聯機建立復制的另一種可選方案是使用XtraBackup。XtraBackup是Percona公司的開源項目，用以實現InnoDB官方的熱備份工具InnoDB Hot Backup類似的功能，它支持在線熱備份，備份時不影響數據讀寫。到目前為止，最新的版本為Percona XtraBackup 8.0.6，可以從https://www.percona.com/downloads/下載安裝包。XtraBackup有很多功能和優點，例如支持全備份、增量備份；支持備份壓縮；備份不影響數據讀寫、事務等。但是它也存在不足之處，例如不支持部分備份；不支持直接備份到磁帶設備；不支持Cloud Back；MyISAM的備份也會阻塞等。不過瑕不掩瑜，這些小缺陷不影響XtraBackup成為一款流行的MySQL備份工具。另外，XtraBackup只支持Linux平臺。下面演示用XtraBackup聯機搭建主從復制的過程，主庫已經建立了用于執行復制的用戶repl。具體步驟如下：

步驟01　在主庫和從庫安裝XtraBackup：

步驟02　配置主庫到從庫的SSH免密連接：

     # 主庫執行
     ssh-keygen
     ... 一路按回車鍵 ...
     ssh-copy-id 172.16.1.126

步驟03　停止從庫，并清空從庫的數據目錄：

步驟04　備份并傳輸：

這條命令用于連接主庫，并行壓縮流式備份，同時將備份通過管道操作符傳輸到從庫，并直接解壓縮到從庫的數據目錄。所有操作由一條命令來完成，不需要中間落盤生成文件。具體步驟如下：

步驟01　在從庫恢復備份：

     # 應用日志
     xtrabackup --prepare --target-dir=/usr/local/mysql/data/

步驟02　查看二進制日志坐標：

     cat /usr/local/mysql/data/xtrabackup_binlog_info

步驟03　啟動從庫：

     mysqld_safe --user=mysql &

步驟04　登錄從庫啟動復制：

XtraBackup是物理備份，性能比mysqldump高得多，而且對主庫的影響極小，非常適用于從頭聯機創建高負載、大數據量、全實例從庫的場景。